Forum Moderators: not2easy
3.12. pseudo elements
The pseudo elements [w3.org] introduced by the CSS3 selectors are familiar as there were pseudo classes in CSS2.1 ::first-line, ::first-letter, ::before and ::after are supposed to do exactly the same as their single columns cousins. We'll even -backwards compatibility- be allowed to continue to use them with a single column for a while to come.
But for new pseudo elements introduced by other CSS3 modules the double column vs the single column syntax shall make a difference. A single column is a pseudo class (like a class that's not really there on an existing element); a double column is a pseudo element (like an html element that's not there in reality).
Syntax: E::first-letter
Syntax: E::first-line
Syntax: E::before
Syntax: E::after
Example:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>test</title>
<style type="text/css">
p {
width: 20em;
text-align: justify;
background-color: yellow;
}
.letter p::first-letter {
float: left;
color: red;
font-size: 7em;
line-height: 1em;
margin-right: 0.1em;
}
.line p::first-line {
font-size: 1.5em;
}
.beforeafter p::before {
content: "BEFORE";
background-color: green;
display: block;
}
.beforeafter p::after {
content: "AFTER";
background-color: red;
display: block;
}
</style>
</head>
<body>
<div class="letter">
<p>"Lorem ipsum dolor sit amet, consectetur adipisicing
elit, sed do eiusmod tempor incididunt ut labore et
dolore magna aliqua. Ut enim ad minim veniam, quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in
voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt mollit anim id est
laborum."</p>
</div>
<div class="line">
<p>"Lorem ipsum dolor sit amet, consectetur adipisicing
elit, sed do eiusmod tempor incididunt ut labore et
dolore magna aliqua. Ut enim ad minim veniam, quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in
voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt mollit anim id est
laborum."</p>
</div>
<div class="beforeafter">
<p>ME</p>
</div>
</body>
</html>
Additional example - added later to help clarify the "fallback" ways to get the best use of these Selectors
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>test</title>
<style type="text/css">
p {
width: 20em;
text-align: justify;
background-color: yellow;
}
.letter p::first-letter {
float: left;
color: red;
font-size: 7em;
line-height: 1em;
margin-right: 0.1em;
}
.line p::first-line {
font-size: 1.5em;
}
.beforeafter p::before {
content: "BEFORE";
background-color: green;
display: block;
}
.beforeafter p::after {
content: "AFTER";
background-color: red;
display: block;
}
/*
to allow for IE8 not recognizing :: selectors and so dumping the whole
rule blocks, they need to be re-input separately for continued use with
the backwards compatible usage of the single colon selector
*/
.letter p:first-letter {
float: left;
color: red;
font-size: 7em;
line-height: 1em;
margin-right: 0.1em;
}
.letter p:first-line {
font-size: 1.5em;
}
.beforeafter p:before {
content: "BEFORE";
background-color: green;
display: block;
}
.beforeafter p:after {
content: "AFTER";
background-color: red;
display: block;
}
</style>
</head>
<body>
<div class="letter">
<p>"Lorem ipsum dolor sit amet, consectetur adipisicing
elit, sed do eiusmod tempor incididunt ut labore et
dolore magna aliqua. Ut enim ad minim veniam, quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in
voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt mollit anim id est
laborum."</p>
</div>
<div class="line">
<p>"Lorem ipsum dolor sit amet, consectetur adipisicing
elit, sed do eiusmod tempor incididunt ut labore et
dolore magna aliqua. Ut enim ad minim veniam, quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in
voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt mollit anim id est
laborum."</p>
</div>
<div class="beforeafter"><p>ME</p></div>
<!--[if lt IE 8]>
<script src="http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE8.js"
type="text/javascript"></script>
<![endif]-->
</body>
</html>
Support:
::first-letter ::first-line
::before ::after
IE8.js adds support for ::before and ::after in IE6 and IE7.
IE8 implements :before, :after, :first-letter and :first-line.
Practical use:
Not much new compared to CSS2.1 except for a new syntax.
Generated content can be used for all sorts of thing, ranging from adding graphics to certain elements to "clearfix" style solutions.
[edited by: swa66 at 9:02 pm (utc) on July 12, 2009]
[Jul 11 2009] Updated the above to correct the unprovable statement that IE8 had limited support for :first-line and :first-letter. Thanks for pointing out the error.
Feel free to discuss, expand and explore below!
[edited by: swa66 at 11:24 am (utc) on July 11, 2009]
[edited by: SuzyUK at 5:33 pm (utc) on July 12, 2009]
It may also be worth pointing out certain property restrictions that apply to some pseudo elements
[edited by: swa66 at 10:14 pm (utc) on July 8, 2009]
[edit reason] unintended smiley removal [/edit]
You're missing out ::outside, ::alternate, ::line-marker, and ::marker, which are used in conjunction with generated content.
As you most probably know -based on past posts- CSS3 is divided in modules and we were actually trying to cover the CSS3 selectors module. I guess that's more than enough to digest for one sitting ;)
Quite a few of the other CSS3 modules add selectors that aren't mentioned in the current CSS3 selectors module. E.g. Those you mention seem to come from the CSS3 Generated and Replaced Content Module. And that module doesn't seem like it's going anywhere soon (not updated since 2003, still WD, ...). Have you seen implementations that would make it usable already?
It may also be worth pointing out certain property restrictions that apply to some pseudo elements
You're missing out ::outside, ::alternate, ::line-marker, and ::marker, which are used in conjunction with generated content.As you most probably know -based on past posts- CSS3 is divided in modules and we were actually trying to cover the CSS3 selectors module.
My bad. I assumed -based on the title of this thread- that you would be listing all pseudo-elements, regardless on which module they belong in.
Those you mention seem to come from the CSS3 Generated and Replaced Content Module. And that module doesn't seem like it's going anywhere soon (not updated since 2003, still WD, ...). Have you seen implementations that would make it usable already?
No - no vendor has implemented these additional pseudo elements that I mentioned.
Property restrictions of pseudo-elements
There are certain, logical restrictions relating to which properties can be applied to certain pseudo elements; the properties that can be used for each pseudo element, are listed below:-
For the ::first-line pseudo element, the spec also states that a UA reserves the right to include additional properties too.
Effect of 'position' values on ::before and ::after
The CSS 2.1 Generated Content spec was amended within the last year to remove a restriction that was applied to :before and :after pseudo element as defined in CSS 2. This restricion related to the ineffectiveness of 'position' property values (other than 'static' of course) when used in conjunction with these pseudo elements.
Apparently the reasoning behind the removal of the restriction was that pseudo elements should as elements inserted in the DOM would do.
I assumed this restriction based on the CSS 2 spec would be carried through to CSS 2.1 and subsequently Level 3, since there was no mention in those specs of the amendment, however, I was informed otherwise.
Although the :before/:after restriction was defined in CSS 2, it was completely omitted from CSS 2.1 - the CSS 2.1 spec was not amended after initial publication, as I understand it.
IE8, Firefox (from 3.5) and Safari have all updated their implementations to reflect this change - I can't remember if Opera has too.
IE8 implements :before and :after, but has limited implementations for :first-letter and :first-line.
Can you point me to some test cases that demonstrate this behaviour? As far as I was aware, they fully supported these pseudo elements, as they've been defined since Level 2.
Can you point me to some test cases that demonstrate this behaviour? As far as I was aware, they fully supported these pseudo elements, as they've been defined since Level 2.(Referring to ie "non"-support for :first-letter and :first-line)
I was so surprised by this I even ran a test document through ie 5-8, Op/winSafari/FF various current+plus older versions, to see if the behaviour differed from expected. It didn't - namely, consistent with the research of quirksmode and others, ie8 continues ie support for :first-letter and first-line (although ie8 renders closer to the "almost" rendering of non-ie browsers, which appears to me to be a step away from the current recs). But that's quite different from the implication ie has only provided limited support for these since ie8.
As an aside, non-ie older versions that do support :: show much the same display variations between versions as found with the single colon syntax. Ironically, ie7&8 have troubles, but 5.5&6 will display ::first-letter and ::first-line as designed.
So "me too" for examples of limited implementations of :first-letter and :first-line in ie please.
But I guess I was wrong regardless.
I did have one source that listed a number of problems and while I was more than ready to dismiss a number of them -I wasn't able to reproduce them-, I thought I had confirmed two of them. Luckily I still had the test files: one had a syntax error in it :( (my mistake there, after fixing that, it did work as intended) ; the second -upon closer inspection of the CSS2.1 standard- should not work, so that's obviously not a problem either.
So for now I don't have any proper examples and I'll go back and remove that statement as it either is in extreme cases or simply not true.
Thanks for helping clear that up!
:first-line and :first-letter: This is actually CSS2.1 not the new parts of CSS3
Css1
Not sure who this was meant for, but James's posts don't appear to be asking for egs because he thinks :first-letter and :first-line are part of the css3 draft any more than mine.
However, until now I'd presumed non-css3 has been referred to when it could be used to deal with browsers/versions that don't support the css3 draft.* That attempted logic has foundered before, and plainly did here because they were then treated as ineffective. Pleased to know it could be just confusing versions.
*Total guess: The ua's being considered haven't been specified, nor reasons given when other css versions are referred to, and the purpose of "graceful degradation" seems to vary.
I did have one source that listed a number of problemsI was highly surprised sources weren't acknowledged up-front ... technical rigour, academic integrity, professional courtesy and all that.
This unnamed source has been treated as so credible it can be relied on despite contradicting other robustly researched resources that have existed (and therefore been scrutinised) for some years - and even though the code proofs fail to reproduce the claimed issues and/or conform to the recs. It must be very, very good in other areas. Surely that counts as "authorative" enough to be named?
So for now I don't have any proper examples and I'll go back and remove that statement as it either is in extreme cases or simply not true.Nothing has been cleared up: This reference to possible ie failures is even more explicit, plus adds the new issue of distinguishing "extreme" from non-"extreme". (Whatever they are.) That's less certainty, more confusion, and a further step asway from provding ilustrative examples than before.
Thanks for helping clear that up!
Two of us have asked for egs because we want to improve our knowledge. That's to be expected when asserting the reverse of the generally accepted position. It's also expected when maintaining such a position. I can't understand the reluctance to post illustrations - or even just the list of claimed issues, or even just the original source so we can access it and investigate this for ourselves. (I suggest that when doing so slice this into another thread so this one maintains its css3 focus.)
[edited by: alt131 at 12:38 am (utc) on July 12, 2009]
:first-line and :first-letter: This is actually CSS2.1 not the new parts of CSS3Css1
I think all swa66 was trying to do here was to reiterate that :first-letter/:first-line doesn't belong CSS3, as this post specifically discusses CSS3 pseudo elements, including the new double colon syntax for these pseudo elements. However, this thread has become slightly forked since we're now appear to mainly be discussing the <CSS3 syntax, and support for it in IE8.
James posts don't appear to be asking for egs because he thinks :first-letter and :first-line are part of the css3 draft any more than mine.
I'm not sure what you mean, alt131?
I specifically mention the older single-colon pseudo element syntax, as IE8 claims full support for it, hence why I asked swa66 for test cases which exhibit a lack of support. This was because I haven't heard of any bug in IE8 relating to :first-line/:first-child.
I agree the thread appears to have forked - hence my suggestion the issue of single colon implementation be split off to retain the integrity of the css3 series. (Perhaps a conclusion posted back.)
However, now all three of us have addressed the issue that single colon syntax isn't new in css3, hopefully that fork can be closed.
The reference to single colon syntax in the opening post makes the issue of "limited implementation" relevant here. However, your interest in emerging information about ie8, and mine about older versions should be addressed once the much-requested illustrations are posted. With luck that will close fork two, and the thread can return to pure css3.
There were buggy implementations of :first-line and :first-letter but they where in previous beta versions of IE8, that knowledge was obviously still lurking in our heads somewhere. So, sorry the finality of that previous "limitation" statement reached the final draft of our post.
We are not perfect, we can make mistakes too. We are not putting this series out as a "final word" type gospel thing. We want everyone's input to help keep this series as up to date, and as clear, as possible. A true WebmasterWorld community resource is the aim :)
The goal posts are still moving when it comes to CSS3 which is what we want to mostly cover. In doing so what we're sometimes finding is that we are having to (re)cover bits of CSS2.1 mainly because of IE8's better support. (IE8's better CSS2.1 support is what prompted the rejuventation of interest in CSS3 and this whole series of posts anyway ;)) In trying to help provide graceful fallback measures/scripts and information we hope to help bridge any gaps as effortlessly as possible in order to help everyone enjoy some CSS3 usage.
As for the single colon, double colon syntax, yes the double colon syntax is new to CSS3, but the browsers must maintain support for the single colon syntax where the pseudo element itself is not new to CSS3. W3C source [w3.org].
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.
my bold
It would be very remiss of us not to highlight things like that during this transition and as part of trying to bridge the gap with our IE "fallback" help sections.
To me this conversation isn't a fork, it's exactly the kind of discussion that helps us all clear up any confusion during this transition period, helping everyone to see why we might have to use the single over the double. (or probably closer to reality is to keep using both for a long time!)
To clarify the graceful fallback measures for this section:
For IE 6 & 7, double colon support is provided by scripts, because the people who wrote the compatibility scripts and the JS libraries used have known about the double colon notation for a while. IE's implementation of these selectors is as per their CSS2.1 commitment, therefore it has the single colon os per CSS2.1 requirements. So for backwards compat you need to use the single colon (no scripts required) but that is as per CSS3 specs anyway, so we feel it does fit, or at least have a place in this particular CSS3 discussion or we wouldn't be able to highlight that particular part of the CSS3 spec.
Hope that clears it up, and obviously if anybody has better examples than ours, for any of the posts in this series do feel free to add them or add any other tips here to help the WebmasterWorld knowledge base :)
Thanks for the questions and feedback on this issue
Suzy
To me this conversation isn't a fork, it's exactly the kind of discussion that helps us all clear up any confusion during this transition period, helping everyone to see why we might have to use the single over the double.
I disagree. In the dialogue between myself and swa66, we aren't discussing support around the transition period from CSS1 and CSS3 syntax (which would be an appropriate topic of discussion for this thread); instead we are discussing a possible partial implementation of the CSS1 syntax in a specific browser - namely IE8, as I requested documentation which demonstrates a lack of support for :first-line/:first-child in IE8, specifically.
If on the other hand, IE8 had claimed full support for the double colon syntax and it became evident that this wasn't true, then this would be the correct thread to discuss this.
Since swa66 has admitted that they were mistaken about the claim relating to IE8s implementation of :first-line/:first-child, I personally think we should cease conversation relating to support for the CSS1 syntax (in this thread, at least)
alt131, there won't be any examples as we were obviously wrong in the tests or had some older information lurking around that we couldn't find a final reputable source for or we couldn't prove.Thanks SuzyUK. Delighted this wasn't a ground-breaking discovery of non-conformance.
I parallel James's statement this never got to the stage of discussing how the single colon syntax might be used during the transition period. It never got beyond requests for proofs of limited implementation. I certainly wouldn't discuss how to use something if it was unusable because it hadn't been well enough implemented. Perhaps useful to reflect that if two posters unambiguously ask for the same information to clarify the same statement about the same issue of extent of implementation, it might not be a confused request for information on how to use.
Substantive issue
I think worth identifying that in the eg of "how to use", inheritance means the single colon syntax over-rides the earlier double colon declarations. In purist terms, this does not allow understanding browsers to access css3, while providing an alternative for non-understanding browsers. It means two sets of rules are being sent and processed before the first set is discounted.
Although that approach raises the possibility of using specificity to deal with rendering differences, that requires care because ie5.5 and 6 apply double colon syntax for first-letter and first-line. I believe the "support" tables should reflect:
(PC/win, for completeness, 5 fails all)
::first-letter / ::first-letter
Applied: ie 5.5, ie6
Not implemented: ie7, ie8
::before / ::after
Not applied/implemented: ie 5.5 - 8
:first-letter / :first-letter
Implemented: ie 5.5 - ie8
:before / :after
Implemented: ie7, ie8
Not applied/implemented: ie 5.5, ie6.
Exploiting this provides some other options for early use in ie:
first-letter/first-line
1. Use single colon syntax
2. Group single and double colon syntax and send single colon syntax via CC to ie8 only
3. Use double colon syntax and send single colon syntax via CC to ie7&8
before/after
1. Use single colon syntax, and .js for ie<7
2. Use double colon syntax, and .js for all versions of ie
These options aim to:
1. Respect bandwidth, minimise calls, avoid repositioning content after page load
2. Write once, use many: If single colon syntax is permitted it is not "wrong" to use it. (At this stage)
3. Eliminate/Reduce version-specific administration,
4. Eliminate/Minimise reliance on javascript.
first-letter/line #3 hasn't been fully checked in really legacy non-ie. I suspect "fault tolerance" will ignore the double colon, or convert it to a single and apply for understanding versions.
That said, I don't support javascript to achieve presentational effects, and believe introducing content via css then implementing that css via javascript is an unacceptable accessibility risk. Nor do I fully support deliberate exploitation of/reliance on browser error handling, but IMO, consciously doing so to provide backwards compatibility for a reasonably predictable range of legacy ua's is better than javascript.
OP updated to provide a clearer example of how to CSS for these selectors in IE8. The 'limitation' new to IE8 is that the single colon backwards compatible CSS has to be in a separate ruleset much to my disdain!Doubly apt cross-reference given my suggestions ;). However, this results from implementing recommended error handling (as identified in the linked thread), so I don't agree it can be classified as a limitation. I think the "undesirable" consequence highlights just how much generous "fault tolerance" has been taken for granted.
(Swa, I thought you said the fallback for this section was easier.. ;))
The OP in this whole series attempts to provide some (but not all) options for graceful fallback solutions. They are in no way meant to be a single de-facto recommendation. Anyone is welcome to contribute solutions too, if another suitable option is proved viable we can add it to the second post as an update.
Please don't get too picky over terminology, or expressions - not all of us in this conversation, or indeed in most WebmasterWorld threads, are native english speakers or can type perfectly clearly as it might be read by absolutely everyone. BUT as far as I know we do all care about CSS3 :)
As for thread forking, that will be up to the moderators to decide. I (with mod hat on) will reiterate again - the NEW IE CSS2.1 support is bound to affect fallback solutions and therefore overlap with some of these CSS3 discussions as this thread so clearly shows - to fork out half this conversation would make it unfollowable.
---mod hat off, back to this thread as contributor --
re: the Update example
It was one of many examples I could have chosen, as is the CSS way, many ways to achieve the same thing, so thanks for pointing out the decisions that might make you want to choose other ways to do this.
options:
I could've stuck the single colon syntax CSS in an [IE8] only conditional, but then I would've had to point out the lack of backwards compat for all the selectors in IE6/7 if the ie8.js is not used or JS is turned off.
-or-
I could've stuck the single colon CSS in an [lte IE8] only conditional but then would've had to explain that wouldn't enable use of before/after in IE6/7.
According to your observation these particular IE CC's should go first in the CSS to allow the CSS3 syntax to kick in for those that support it (via js or not), which is unlike any other recommendation for conditional CSS which usually must come last, this is a well made point which I understand for this case use, but in theory this might lead to people having two sets of conditional code/ or 2 sets of IE stylesheets :o (solely because of IE8!)
-or-
I could've simply put the IE single colon syntax CSS first in the main sheet, allowing the second lot to overrule it (with or without the JS) or be ignored, but some don't like to do that, they like to keep IE only CSS separate, and/or they don't like increasing their regular CSS file size because of IE
-or-
I would have preferred to group the selectors and not have any separate CSS in the first place as that would be the logical way to do it. That would work, always has worked, in IE6/7 for graceful fallback, without any scripting (for first-line/letter only) i.e. for natural progression/enhancement (much like we do with vendor specific properties already) - The linked thread discusses why we can't do this now (for selectors) for IE8 either, and includes my opinion about that - please do feel free to 'discuss' the pros and cons of that IE8 implementation of CSS2.1 over on the other thread if you like.
-or-
and possibly the closest to "correct" given the above options..
I could've put all that single colon CSS in an IE8 only conditional and then triplicated the IE CSS in yet another conditional for IE5/6/7 adding the advanced selectors, using grouped selectors. Both of these conditionals could now go after the main CSS as is the usual recommendation. Then it could be advised that now the IE8.js is only required if you want to maintain before/after support for IE6/7. - this is possibly the correct way but also that's now 3 sets of CSS just for an IE fallback solution! Although though it does save on multiple sheets as it could now go in existing IE sheets that are already being called after the main CSS
None of the above are strictly correct, e.g. even the last one we shouldn't have to put CSS2.1 in an IE conditional
We could of course use revealed conditionals and do it in reverse, which is probably the even more correct way to do it.. but I'm now fed up :)
---------
Currently I am trying to find/work on an easier solution which covers a graceful fallback for all these eventualities, and suits everyone. If anyone wants to join in with that quest, do feel free. If we find one (for enhancement CSS only), or if anyone knows of one - I will update the second post again.. however up until then it's up to everyone to use their preferred method, depending on the preferred level of graceful fallback they wish to offer. (my personal hope is that in follow up to Eric Meyers recent post [meyerweb.com] this will be available sooner rather than later)
I too don't support JS for necessary CSS, and have never actually used IE7/8.js because of their all encompassing solutions which may well mask other issues. I prefer to investigate/find/write my own solutions for specific use cases which I want for visual enhancements, which is all these particular pseudo elements should be used for anyway ;)
This is why I, personally, am more and more preferring jQuery solutions as you can get very picky over not only which CSS3 enhancements you would like to offer (thanks to the lovely new sizzle engine) but can choose to show/hide things as a visual enhancement but make sure things like dropdowns/conditional form elements stay visible when JS is off for accessibility reasons (i.e. the JS not the CSS does the hiding for only those elements you deem necessary). JQ does a lot more than enhance CSS usage, all from the one library, you can choose which plugins/functions you want to use or write, It also uses CSS selector notation which makes it easier for CSS'ers to adopt/read. Compared to viewing the source of IE7/8.js to pick out the bits I might want (which I readily admit I can't do) there's no competition.
Unfortunately though I would guess that there are a lot of CSS/non-js people (CMS template authors for ease?) using the plug'n'play IE7/8.js as it's been highly useful to CSS2.1 adoption in the past, it is still likely to be used (in a lt8 conditional) until a better "plug'n'play" option is released and proved - and because it is already widely adopted. We CSS'ers are the ones which will have to continue to educate and answer the "why does my CSS that worked before now not work in IE8" questions the same way as we do for CSS back-hacks - instead of asking which Doctype, we will likely be asking have you been using the IE7/8.js? It's a different time, We, like CSS2.1, have never had to deal with this kind of issue before so it can't get all the blame. CSS3 is the next target (in more ways than one?) - and I for one hope IE see the error of their ways and at least allow pseudos to prevail.
So in conclusion it's not our place in this series to pretend any of these solution don't exist or promote one over the other, we do however want to show them as the authority/well supported options that users are likely to come across.
And for the sake of discussion - it is still my opinion that this "new to IE8" error handling adherence is indeed a limitation to CSS3 uptake/usage. I consider it an IE limitation when we are having to look for a new CSS workaround to provide a graceful fallback for IE only, yet again (and as alt131's great post shows quite clearly), in order to try and encourage/help CSS3 uptake - especially at this crucial time for both CSS3 and IE8.
The thing with the CSS specifications is that they have always been open to interpretation by browsers/UA's, and sometimes good old common sense has prevailed and specs have subsequently been altered, CSS2.1 was a case in point, it is/was almost always in a state of flux. (and just for the really interested CSS2.1 has finally become a CR W3C Candidate Recommendation 23 April 2009 [w3.org] which means it can't even become a Proposed Recommendation before 23rd July 2009. so we're still talking about standards,that will come after the the standards that are not yet finalised to this day!
