Chained pseudo-selectors do not seem to work in IE8 on Windows XP. Is there any documentation about this?
I'm developing a website using Selectivizr in order to use CSS3 selectors, but a style such as this doesn't work in IE8, whereas it works everywhere else (unsurprisingly):
span:last-child:after {content: "foobar";}
This is not a bug, it's due to the fact the the selector doesn't match natively.
A simple selector is either a type selector or universal selector followed immediately by zero or more attribute selectors, ID selectors, or pseudo-classes, in any order. The simple selector matches if all of its components match.
The simple selector in this case is either span:first-child, which matches natively in IE8, or span:last-child, which does not.
One pseudo-element may be appended to the last simple selector in a chain, in which case the style information applies to a subpart of each subject.
Appending :after to span:first-child is a match, while appending it to span:last-child is not, and since Selectivizr is a post-processor, it comes too late to save the day. Perhaps a pre-processor would have better luck.
Related
I had a situation where I had to apply a specific CSS style in Edge and IE browsers only. I found online that you can prepend your CSS selector with _:-ms-lang(x) and the style will only be applied in IE and Edge.
But I wonder, how exactly is this fix working? As far as I know, the comma will just separate different selectors, meaning that other browsers should also interpret and use this style.
Here is an example:
Let's say we want to apply a width of 94px to .selector element only in Edge and IE.
_:-ms-lang(x), .selector {
width: 94px;
}
The Edge browser will apply this style, and others won't. But why not?
The comma in the selector should apply the style to _:-ms-lang(x) element AND to .selector element.
Here is a source for this IE hack.
And one more.
In CSS, when a browser does not recognize part of a selector (or thinks there is an error in a selector), it completely ignores the entire rule.
Here's the section in the CSS3 spec outlining this behavior
The prelude of the qualified rule is parsed as a selector list. If this results in an invalid selector list, the entire style rule is invalid.
Here CSS2.1 talks about the special case of comma
CSS 2.1 gives a special meaning to the comma (,) in selectors. However, since it is not known if the comma may acquire other meanings in future updates of CSS, the whole statement should be ignored if there is an error anywhere in the selector, even though the rest of the selector may look reasonable in CSS 2.1.
Therefore when the other browsers try to parse the selectors, they find the _:-ms-lang(x) selector to be invalid and so ignore the entire rule (including .selector)
Also here is an excellent answer on why this behavior is desirable
I'm new to CSS, and I was wondering, is there another way to write an equivalent to pseudo class :link , in case :link is not supported?
Theoretically, in selectors-4 you can write :any-link:not(:visited), but you are going to be hard-pressed to find any browsers that support :visited but not :link, let alone :any-link, browser regressions notwithstanding.
A slightly more widely-supported selector requires knowledge of the document language since the link pseudo-classes themselves match different elements based on document semantics. In HTML, :link can be expressed as the following level 3 selector-list:
a[href]:not(:visited), area[href]:not(:visited), link[href]:not(:visited)
The same caveat applies.
If you're asking about browsers that support neither of the link pseudo-classes, remove the :not(:visited) from the above selector-list. If you're asking how to match links based on their visitedness in browsers that support neither pseudo-class, then it becomes impossible. But there are no known browsers that lack support for the link pseudo-classes, so this will never be a problem if you're making websites.
Note that CSS1 and CSS2.1 define :link and :visited to apply only to a elements — the standalone Selectors standard (level 3 and up) instead defers to the document language, and in the case of HTML, the current definition above is provided by HTML5. What this means in theory is that browsers up to and including IE6 (not sure about IE7) don't support the link pseudo-classes on elements other than a[href], and that's because IE6 was designed to be CSS1-compliant, not CSS2-compliant.
What this means in practice depends on whether or not you use the link pseudo-classes to match area or link elements, and whether or not you support browsers dating back to IE7, in the first place. If you're like 99.9% of authors who don't use them with area or link elements, then this means absolutely nothing to you in practice.
The a {} selector ({} added since it's so short) will apply to all pseudo classes though a:link will override specific styling for URLs the user has not yet visited.
Someone mentioned an exceptionally old version of Internet Explorer. If you're new to CSS you should first concentrate on current browsers. If you're learning at this point the oldest version of IE that you'll be supporting is IE11 if working with CSS will become a part of your future career.
Why we can't grouping CSS like..
p::selection , p::-moz-selection
{background:transparent;}
Demo : http://jsfiddle.net/l2aelba/MRyVC/1/
Why we have to select one by one like
p::selection {background:transparent;}
p::-moz-selection {background:transparent;}
Demo : http://jsfiddle.net/l2aelba/MRyVC/
Someone can expand this issue ?
Browsers are expected to drop the entire rule if any part of the selector is invalid:
The selector (see also the section on selectors) consists of everything up to (but not including) the first left curly brace ({). A selector always goes together with a declaration block. When a user agent cannot parse the selector (i.e., it is not valid CSS 2.1), it must ignore the selector and the following declaration block (if any) as well.
CSS 2.1 gives a special meaning to the comma (,) in selectors. However, since it is not known if the comma may acquire other meanings in future updates of CSS, the whole statement should be ignored if there is an error anywhere in the selector, even though the rest of the selector may look reasonable in CSS 2.1.
(Note that as far as a browser is concerned, "valid CSS 2.1" really means "a selector that is understood and supported by the browser".)
Since non-Mozilla browsers don't understand ::-moz-selection, they have to drop the rule. Since Mozilla browsers don't understand ::selection, they have to drop the rule as well. It's a lose-lose situation (and another reason why prefixes are unwieldy, especially in selectors).
For the record, I'm surprised this no longer works in Chrome (at least in version 25 on Windows as I just tested anyway). It used to stubbornly parse the selector p::selection, p::-moz-selection as simply p::selection and apply the rule instead of following the spec, and the developers had reasons for making it so. I wonder what changed...
How would I go about looking up or comprehensively testing the browser compatibility of a particular CSS selector?
The selector in question has this form:
#idValue.classValue
Which will find an element with id idValue with a class of classValue - so, like this thing:
<div id="idValue" class="classValue">
How compatible is this with the major browsers? How would I research the compatibility of this selector without running all the browsers? Is there a name for this kind of compound selector?
Every browser supports this selector fully. There is no special name for it, although it's interesting to note that it is called a "compound selector", as it's a combination of two simple selectors.
If you flip the selector around, it should work just as well:
.classValue#idValue
See also:
Browser support for the combined type, ID and class selectors?
Combining a Class selector with an ID
As for researching browser support, QuirksMode.org's CSS compatibility table is a good resource, although it doesn't mention every available selector. l–c–n.com has a much more comprehensive table.
I check this selector:
h3:nth-child(1):contains('a')
selector doesn't work?
I check this in firefinder and does return nothing (not info that there is zero elements)
Then check this:
h3:nth-child(1)
and it returns h3, so selector is almost good, but something with this(h3 has text 'a') text goes wrong.
:contains() is not was going to be a CSS3 selector (thanks T.J. Crowder for the link), but it didn't make it, most likely because the way it works tends to lead to severe performance and over-selection issues. For example, if an element E matches :contains() for a given string argument, then all of its ancestors would also match; using it with a universal selector would lead to unexpected results with certain style properties, on top of being slow for the browser.
There is no other CSS selector that serves a purpose like :contains(). So you'll have to find some other way, either by modifying your HTML or even by using jQuery's :contains(), to achieve the effect you want:
Select an h3 element
if it is the first child of its parent
and its text contains the letter 'a'.
For jQuery and Selenium RC users: :contains() is implemented in the Sizzle selector engine used by jQuery, which is also used in Selenium RC (but not Selenium WebDriver). It works as described in this decade-old revision of the CSS3 spec, but again, due to how the spec describes it, you need to use it with care or it may lead to unexpected selections.
On a final note, h3:nth-child(1) can be replaced with h3:first-child, which as a CSS2 selector has better browser support.
If you're trying to use :contains(a) to find an anchor tag (rather than the letter A), you could use:
h3:nth-child(1) a
or
h3:first-child a
The :contains() pseudo-class isn't in the CSS Spec and is not supported by either Firefox or Chrome.
You can find a couple of detailed discussion in:
selenium.common.exceptions.InvalidSelectorException with "span:contains('string')"
Finding link using text in CSS Selector is not working
Solution
As a solution you have to drop the contains() part and your effective locator will be:
h3:nth-child(1)
Further as #BoltClock mentioned within his answer, you can also use:
h3:first-child
As an alternative, you can also use:
h3:first-of-type
tl; dr
selenium.common.exceptions.InvalidSelectorException with "span:contains('string')"
Finding link using text in CSS Selector is not working