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.
Related
Is there a difference in behaviour or browser support for using the CSS3 selectors :enabled or not(:disabled)?
I expect them to be functionally identical, and as they are both CSS3 selectors, browser support should be identical too.
Yes, there is a difference — :not(:disabled) can match elements that are neither :enabled nor :disabled. These are elements where enabled/disabled semantics simply don't apply, such as div, p, ul, etc.
The spec confirms this:
What constitutes an enabled state, a disabled state, and a user interface element is language-dependent. In a typical document most elements will be neither :enabled nor :disabled.
Interestingly, the same can't be said for :checked — there is no corresponding :unchecked pseudo-class, despite the fact that not all elements have checked/unchecked semantics either. See my answer to this question.
If you're qualifying these pseudo-classes with a type selector (such as input, select or textarea) or a class selector, you probably don't have to worry about this. Still, it makes more sense to use :enabled than :not(:disabled).
Browser support for the majority of level 3 pseudo-classes is indeed identical — there are no known browsers that support either :enabled or :disabled only. However, according to MDN it looks like Opera 9.0 and Safari 3.1 don't support :not(), although they do support :enabled and :disabled, and some other features like substring-matching attribute selectors and the general sibling combinator ~ are supported in IE7 with some issues and a little bit better in IE8.
The > character can be used with CSS to select an element that has a certain parent.
The benefit I see here is that I can apply styles only to a certain level of a list for example. Like menus - first level is orizontal and has different rules than 2nd level+. so i don't need to worry about resetting properties for lvl 2+
Anyway, can I depend on >? Is it supported by all browsers and without buggy behaviors?
The child selector > is fully supported by IE7 and later, and not at all in IE6 and earlier. Of course, all versions of all other major browsers in use today support it fully as well.
All CSS2.1 selectors are well-supported by IE8 and later so you can use them today, unless you're writing legacy code that needs to cater to IE6, in which case avoid them where possible.
The SitePoint Reference does mention an obscure parsing bug related to comments that affects IE7, but it only breaks the selector if a comment is there. You don't usually put comments in the middle of selectors unless you're doing so as a hack, so you don't need to worry about this bug.
Related: Are CSS child selectors a W3C standard? (Of course they are!)
It's part of the CSS2 standard: http://www.w3.org/TR/CSS2/selector.html#child-selectors so modern browsers should support it.
According to this quirksmode.org, only IE6 and earlier do not amongst major browsers. I only see IE6 used in very situational cases (like dedicated machines that don't receive software patches).
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.
Since IE7 and IE8 don't support the double-colon notation for pseudo-elements (e.g. ::after or ::first-letter), and since modern browsers support the single-colon notation (e.g. :after) for backwards compatibility, should I use solely the single-colon notation and when IE8's market share drops to a negligible level go back and find/replace in my code base? Or should I include both:
.foo:after,
.foo::after { /*styles*/ }
Using double alone seems silly if I care about IE8 users (the poor dears).
Do not use both combined with a comma. A CSS 2.1 compliant (not CSS3 capable) user agent will ignore the whole rule:
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.
http://www.w3.org/TR/CSS2/syndata.html#rule-sets
You could however use
.foo:after { /*styles*/ }
.foo::after { /*styles*/ }
On the other hand this is more verbose than necessary; for now, you can stick with the one-colon notation.
From CSS3 Selectors REC:
This :: notation is introduced by the current document in order to establish a discrimination between pseudo-classes and pseudo-elements.
For compatibility with existing style sheets, user agents must also accept the previous one-colon notation for pseudo-elements introduced in CSS levels 1 and 2 (namely, :first-line, :first-letter, :before and :after).
This compatibility is not allowed for the new pseudo-elements introduced in this specification.
It seems you're safe using (only) one-colon notation for pseudo-elements that already existed in CSS2.1 as UAs must be backward compatible.
I absolutely disagree with #mddw and #FelipeAls, in regards to considering the use of one colon "safe".
This "I'll use it even though it's deprecated" mentality is exactly why browser-based technologies are so slow at advancing and progressing forward.
YES, we want to maintain compatibility with old standards. Let's face it, it's the hand we've been dealt. BUT, this does not mean you have an excuse to be lazy in your development, by ignoring current standards in favor of deprecated ones.
Out goal should be to maintain compliance with current standards, while supporting as much of the legacy standard as possible.
If pseudo-elements use : in CSS2 and :: in CSS3, we should not be using one or the other; we should be using both.
To fully answer the original question asked, the following is the most appropriate method of supporting the most current implementation of CSS (version 3), while retaining legacy support for version 2.
.foo:after {
/* styles */
}
.foo::after {
/* same styles as above. */
}
However, it's become increasingly popular to use polyfills for both new javascript and CSS, so you might just want to stick with using the newer double-colon (::) syntax, and maintain a polyfill for older browsers, so long as that is necessary.
For what it's worth according to Browser Stats IE 8.0 has dropped to less than 1% in the USA over the past year.
http://gs.statcounter.com/browser-version-partially-combined-market-share/desktop/united-states-of-america/#monthly-201512-201612
In December 2015 IE 8.0 had 2.92% of the market.
In December 2016 IE 8.0 had .77% of the market.
At that rate of decline it wouldn't be the worst idea to stop supporting old versions of IE and start using :: for Pseudo Elements.
Including both notations is certainly safer, but I can't see any browser dropping the single notation for a long time, so only a single one'll be fine (it's valid CSS2.)
Personnaly I only use the single colon notation, mostly by habit.
I am wondering if there are any other selectors which select only part of an HTML element. I know of these two:
:first-letter
:first-line
But AFAIK there are no other selectors which do this. I am interested in any (even browser-specific) selectors or other methods of manipulating only part of a block of text.
The Use Case
I have (more) control over the .css and .js than over the DOM. I've been using js workarounds but want to include any CSS solutions as well, because I don't like to depend of javascript for my styles.
Even if the solution is only supported in konquerer it is still better than nothing IMO.
Nope, those are the only two content pseudo-elements available that select real text nodes. Nothing new has made it into the CSS3 recommendation.
One of the proposals that didn't make it was ::selection (roughly implemented by Opera, Safari and Chrome, and by Firefox as ::moz-selection), but your use case doesn't really say anything about what you want to do so I have no idea if that selector is relevant to your needs.
I'm not aware of any browser-specific pseudo-elements, but there are also the ::before and ::after pseudo-elements. See the CSS 2.1 specification from the W3C.