homepage Welcome to WebmasterWorld Guest from 54.198.224.121
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: DrDoc

CSS Forum

    
IE8 CSS Parse Bug with combined selectors
or not?
SuzyUK




msg:3947964
 10:03 pm on Jul 7, 2009 (gmt 0)

after trying to write a jQuery solution to simulate the function of the :checked, :disabled, :enabled [webmasterworld.com] UI states for IE8. I ran into a couple of issues, the first I found about - but I think the final one is an IE8 CSS parse error/bug, does anyone know if it's known, or if I've done something wrong.

in the test code below, in which I've provided both the JS test and a cleanly classed element, IE8 is not processing the combined selector in either case. (it does in IE8 as IE7, as well as in IE6/7 themselves)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>test</title>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>
<script type="text/javascript">
$(document).ready(function(){
$(':not(:disabled)').addClass('isenabled');
});
</script>

<style type="text/css">
button:disabled {background-color: red; color: white;}

/* you should be able to combine your selectors like this, but IE8(as IE8) doesn't like it */
button:enabled, button.isenabled {background-color: green; color: yellow;}

/* comment out the rule below to see IE8 (as IE8) Fail on the both the green enabled buttons whereas it should be using the combined selector above*/
button.isenabled {background-color: green;color: yellow;}
</style>
</head>
<body>
<form action="#">
<button disabled="disabled">disabled</button>
<button>enabled by default</button>
<button class="isenabled">enabled by classname</button>
</form>
<div></div>
</body>
</html>

thoughts?

edited to move comment out of the way to clarify example, per reply below

[edited by: SuzyUK at 10:16 pm (utc) on July 7, 2009]

 

DrDoc




msg:3947967
 10:08 pm on Jul 7, 2009 (gmt 0)

Does it make a difference if you swap the two?

button.isenabled, button:enabled

SuzyUK




msg:3947972
 10:11 pm on Jul 7, 2009 (gmt 0)

No Doc it didn't, I had them the opposite way in my first test. I'll try again to be sure

after retest by swapping order and removing the comment out of the way, still the same

[edited by: SuzyUK at 10:13 pm (utc) on July 7, 2009]

DrDoc




msg:3947974
 10:16 pm on Jul 7, 2009 (gmt 0)

Must be a parse error then.

Try adding a .isdisabled class as well, to see if that messes up the button:disabled styles too.

SuzyUK




msg:3947977
 10:20 pm on Jul 7, 2009 (gmt 0)

yea.. I tried all three states it happens with disabled & checked too - will try some more pseudo classes now too

not good for this jQuery newbie, I spent hours thinking I'd done something wrong with JQ, only to land back in CSS :o

jameshopkins




msg:3949070
 9:22 am on Jul 9, 2009 (gmt 0)

The :enabled and :disabled UI pseudo classes aren't part of CSS 2.1 - they were introduced in CSS 3.

Does it make a difference if you swap the two?

IE8 is handling the parsing of this selector correctly; as SuzyUK has verified, your suggestion won't many any difference.

CSS error parsing rules for declaration blocks states, "When a user agent can't 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". Subsequently an unknown or invalid simple selector in a grouping selector (which is what SuzyUK posted) will cause the entire declaration to be dropped. I understand particularly in the instance of a grouping selector, this parsing behaviour may not always be intuitive to authors.

swa66




msg:3949100
 10:15 am on Jul 9, 2009 (gmt 0)

It's indeed a syntax error according to the validator as well if you stick it in CSS2.1 mode.

Now this is bad!

Not only will this mean we'll hate IE8 in a few years just like we hate IE6 today, but it gets much worse as we'll run into this all over the board due to the CSS3 modules and each of them having the potential to introduce new pseudo classes that are then impossible to combine with other selectors as it risks the entire rule to be ignored.
This will in turn lead to worse code being written.

Since we'll never know which modules a browser will have implemented, this looks to me like a rather fundamental flaw and the CSS parsers should be modified to ignore the parts they don't understand if there's a too new pseudo class selector instead of trashing the entire rule. Or the entire set of CSS3 selectors should be moved to the selectors module (but that would make the module concept of CSS3 unworkable).

SuzyUK




msg:3949118
 11:20 am on Jul 9, 2009 (gmt 0)

@jameshopkins.. thank you I hadn't run into that little beauty (not!) yet..

official source: 4.1.7 Rule sets, declaration blocks, and selectors [w3.org]

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 versions 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.

Illegal example(s):
For example, since the "&" is not a valid token in a CSS 2.1 selector, a CSS 2.1 user agent must ignore the whole second line, and not set the color of H3 to red:

h1, h2 {color: green }
h3, h4 & h5 {color: red }
h6 {color: black }

Well that's just a big fat YUK!, just because IE thinks the selector is invalid, because it still is (and is always likely to be) playing catchup, we have to write 2 sets of CSS.. I know.. I know.. it is invalid in CSS2.1 but for goodness sake how much longer do we have to deal with this rubbish, remembering different things for IE :(

I suggest that even if MS doesn't implement any/much of CSS3 yet, they at least amend their handling, (or roll it back seeing as it's new to IE8) of that particular part of the spec. to allow for pseudo classes even if they don't recognise them yet..

Yes Swa, I agree with everything you said, it's bad!
[end rant], sorry I'm a little annoyed, can you tell?

[edited by: SuzyUK at 11:26 am (utc) on July 9, 2009]

jameshopkins




msg:3949211
 2:03 pm on Jul 9, 2009 (gmt 0)

... we'll run into this all over the board due to the CSS3 modules and each of them having the potential to introduce new pseudo classes that are then impossible to combine with other selectors as it risks the entire rule to be ignored.

Correct. The issue will arise during a browsers transitive support period between Level 2.1 and Level 3 Selectors, and this is what we're noticing in IE8 especially.

Since we'll never know which modules a browser will have implemented...

And it's not strictly modular when it comes to implementation anyway. To an extent, vendors do sometimes second guess the stability of a feature, namely when the module which that particular feature belongs in, is in one of the earlier levels of development (WD, etc), when it comes to implementation. This means you'll often see some properties implemented before others which both belong in the same module. For example in Selectors L3, :not() was implemented in Firefox way before :only-chid.

... the CSS parsers should be modified to ignore the parts they don't understand...

I think you would encounter some stern opposition to that proposal on the mailing list. Better still, when a vendor commences work on a new version of Selectors, they should allow the parsing of all simple selectors defined in the new spec, whether or not they are all supported. Although this could be seen as counter-intuitive and a back-route around the current parsing rules, it would allow simple selectors from multiple CSS levels to be combined into a grouping selector, where simple selectors that are supported would be applied - and more importantly, the whole declaration wouldn't be dropped as is happening at the moment. So, for a Selectors L2.1 implementation, you would end up with something like...


#hello, <---- CSS 1 (supported)
#great:after, <---- CSS 2 (supported)
#test:only-of-type <---- CSS 3 (not supported)
{
color:green
}

... which would mean that the declaration block would be applied to #hello and the :after pseudo element attached to #great.

AFAIK, Opera, Firefox and Safari support for the full L3 module, which just leaves IE8. I suggest by the time I put this proposal past them, that they would have implemented the entire spec anyway :)

However, since it is not known if the comma may acquire other meanings in future versions of CSS, the whole statement should be ignored if there is an error anywhere in the selector

IMO, I don't think this statement has any real meaning to it anymore. Although commas are used in other areas of CSS, I can't see the meaning of a comma change in a selector, at least.

[edited by: swa66 at 2:26 pm (utc) on July 9, 2009]
[edit reason] turning smileys off [/edit]

swa66




msg:3949235
 2:24 pm on Jul 9, 2009 (gmt 0)

I was indeed assuming a browser crafter to implement CSS3 modules as a whole, but there is indeed lots of evidence to the contrary. So I guess I gave them too much credibility.

However, since it is not known if the comma may acquire other meanings in future versions of CSS, the whole statement should be ignored if there is an error anywhere in the selector

IMO, I don't think this statement has any real meaning to it anymore. Although commas are used in other areas of CSS, I can't see the meaning of a comma change in a selector, at least.


Agree, the too far looking ahead attitude is going to cause loads of trouble in expanding selectors instead of removing trouble. But it's a done deal I'm afraid we cant roll back the implemented standard out there in the field ...

Anyway it should get fixed that CSS3 selectors that are beyond what is in the CSS selectors module are goign to be accepted syntax-wise by all CSS3 parsers, even if they don't implement the pseudo class or the pseudo element yet, even for unknown future classes and elements. At least they could allow all letters, dashes, digits in a name and allow those as room to expand without letting them have special chracters (so you could add ::acrobatic-jump, but not ::acro[flight]

In the end for the person writing CSS3, it's going to become irrelevant in what level of CSS that selector became available, and if there are implementations out there that lack this one, with the potential to trigger it all into what a retarded implementation thinks is a syntax error and unexpectedly drop the parts it would normally.

Anyway as is this is a nightmare.

SuzyUK




msg:3949424
 5:50 pm on Jul 9, 2009 (gmt 0)

Yep Nightmare.. I agree James technically they shouldn't miss out a bit of the CSS2.1 specs that doesn't suit them. (the bit quoted above). However, with this particular bit, they did until now, which is why we (well I) never noticed this before.

So why should they be so flipping pendantic now when they're obviously trying their best to ease the transition, (even giving them the benefit of the doubt this is going to strip the fundamentals of being able to combine selectors.. something everyone learns early on.. and what with Page Speed and YSlow and every other major browser giving advice on how to get us to write/cut sheets, this is only going to make it worse.

IMO, I don't think this statement has any real meaning to it anymore. Although commas are used in other areas of CSS, I can't see the meaning of a comma change in a selector, at least.

I too am thinking like that, but there is the potential already to use commas in other places in selectors.. not that they couldn't parse their way out of it if they wanted.. eg: theoretical example only, adopted already by some JS libraries
:not(.one, .two) {}

whatever, please MS just put it back, we're prepared to use script so we can wait for you to catch up with CSS3 enhancements, but don't ruin it again please!

jameshopkins




msg:3951078
 6:35 pm on Jul 12, 2009 (gmt 0)

Agree, the too far looking ahead attitude is going to cause loads of trouble in expanding selectors instead of removing trouble. But it's a done deal I'm afraid we cant roll back the implemented standard out there in the field ...

With regards to feature adoption, there's a difference between rolling back, and extending the scope of that feature.

I think it's entirely feasible that a browser could parse but not apply simple selectors that it doesn't understand. Whether or not vendors would actually be happy about adopting this logic - since doing so, would imply successful application of those simple selectors as well as parsing - is another story altogether, as it would go against the current spec. If I have time I might have a go at coming up with a short proposal and seeing what www-style have to say about it.

Anyway it should get fixed that CSS3 selectors that are beyond what is in the CSS selectors module are goign to be accepted syntax-wise by all CSS3 parsers, even if they don't implement the pseudo class or the pseudo element yet, even for unknown future classes and elements. At least they could allow all letters, dashes, digits in a name and allow those as room to expand without letting them have special chracters (so you could add ::acrobatic-jump, but not ::acro[flight]

I don't agree that a completely free reign should be given to vendors in terms of selector parsing; instead they should restrict parsing to selectors defined in the spec. Vendors are free to implement their own features anyway, whether that be selectors, properties, media query descriptors, etc. If Webkit wanted to implement the 'acrobatic-jump' pseudo element like you suggested, they could prepend it with the '-webkit-' prefix and create their own proprietary implementation. Of course, grouping one of these vendor-specific selectors with a currently parsable selector would mean the whole declaration is dropped - I don't think this behaviour should be changed.

too am thinking like that, but there is the potential already to use commas in other places in selectors...

I suggest that in any area where a grouping selector is used, the same proposed rules apply.

whatever, please MS just put it back, we're prepared to use script so we can wait for you to catch up with CSS3 enhancements, but don't ruin it again please!

This isn't just an IE problem. Breaking out of recognised coventions isn't the answer here. This proposal needs to be discussed at a level where all vendors can participate in the dialogue so that we can reach a resolution. In the mean time, I'll try and discuss this directly with Microsoft when I get a chance to, as I personally think it's unlikely they'll implement the full Level 3 Selector module.

I don't know how the JS workaround works as I've never liked the idea, but I'd suggest it incorporates the same selector parsing rules as specified by the W3C, so I don't see how this can be a solution.

SuzyUK




msg:3951110
 7:59 pm on Jul 12, 2009 (gmt 0)

This isn't just an IE problem. Breaking out of recognised coventions isn't the answer here

It is an IE only problem, no other browser is "not recognising" advanced selectors whether they support them or not, and it not breaking out, it's breaking back into, regressing to their previous support which will just happen to aid the transition should they ever get around to any CSS3 support. I don't care about the specs to letter, they have always always been open to browser interpretation.. this is just a plea from a real world user to help them :)

I don't know how the JS workaround works as I've never liked the idea, but I'd suggest it incorporates the same selector parsing rules as specified by the W3C, so I don't see how this can be a solution.

You might never have liked them, but without them CSS wouldn't have been free to get this far, it's thanks in no small part to those Dean Edward scripts that we were able to force IE's turnaround. (as well as many others, zeldman, meyer, WASP, Molly.. way too many to mention) It's noble to think we do not need scripts anymore, I too wish that were true.. but just because IE have caught up with CSS2.1 doesn't mean we have to stop helping progression now! and without using them you run the risk of way falling behind given how a lot of people are being introduced to CSS (with advanced CSS capabilities "built in") via javascript or "easy" to use JS Libraries

The scripts don't always use W3C standards, at least not in the CSS1, 2, 3 sense, when it comes to selector parsing "rules" but like forward thinking browsers they pave the way and give us the opportunity to try and use more advanced CSS. That's exactly why they are the solution.

It's been known for an absolute age that early adoption and usage of future CSS is the key to proving a selector, or property's worth and aids in the writing or even rewriting of a specification. How could we use them consistently x-browser without these scripts? - It should not ever be the other way around, else we will get stuck in the 'sheep' mentality or the can't think, won't think, of all possibilities,(i.e. non-real world) scenario we might have been in before if it weren't for forward thinking browsers like Opera and then FF. Opera first and then FF, took the lead in CSS (with or without their browser specific extensions, before they got specified too ;)).

jameshopkins




msg:3951497
 12:56 pm on Jul 13, 2009 (gmt 0)

This isn't just an IE problem. Breaking out of recognised coventions isn't the answer here

It is an IE only problem, no other browser is "not recognising" advanced selectors whether they support them or not...

I'm unsure as to what you mean. As we concluded earlier on in the discussion when we discussed grouping selectors, if a browser comes across a selector that it can't parse (whether it be invalid or unknown), the subsequent declaration block is dropped. If the opposite were true - like it sounds as though you might be stating - it would be a clear violation of established parsing rules. If instead you're referring to the substitutional parsing of an older generation selector of the same type, there is no difference; the selector that hasn't been implemented still won't be parsed. Selector parsing rules and providing an older version of that selector as a fallback, are two completely different things.

... and it not breaking out, it's breaking back into, regressing to their previous support which will just happen to aid the transition should they ever get around to any CSS3 support

Which selector are you suggesting falls back "to their previous support"?

I don't know how the JS workaround works as I've never liked the idea, but I'd suggest it incorporates the same selector parsing rules as specified by the W3C, so I don't see how this can be a solution.

You might never have liked them, but without them CSS wouldn't have been free to get this far, it's thanks in no small part to those Dean Edward scripts that we were able to force IE's turnaround

In my previous post, I specifically mention "JS workarounds", in the context of discussing workarounds that bring inferior browsers up to a superior level of support (be it, in an emulated sense). However, a distinction needs to be made between a JS framework that patches up broken CSS implementations (Dean Edwards' scripts), and scripts that provide both authors and implementors a chance to preview forthcoming CSS features, by emulating those specs. The latter is a superb idea; not only does it give authors a chance to test out forthcoming features, but it can also highlight spec ambiguities [lists.w3.org] which can then be fed back to implementors, as Alex Deveria's recent emulation of the Template Layout module [a.deveria.com] showed. I can give several reasons why I don't like those implementation-patching scripts, but this thread isn't the right place to do that in, I don't feel.

The scripts don't always use W3C standards, at least not in the CSS1, 2, 3 sense, when it comes to selector parsing "rules" but like forward thinking browsers they pave the way and give us the opportunity to try and use more advanced CSS. That's exactly why they are the solution.

IMHO, I don't believe they are the solution. As I mentioned before I think they're great at giving authors a preview of forthcoming yet-to-be-implemented features, but I feel every day adoption of those emulation methods are the wrong way to go about things. I guess we have to agree to disagree.

It's been known for an absolute age that early adoption and usage of future CSS is the key to proving a selector, or property's worth and aids in the writing or even rewriting of a specification. How could we use them consistently x-browser without these scripts?

The simple answer is we can't use them cross browser without the scripts. But why would we want to test the actual browser implementations of a yet-to-be-implemented feature cross browser, if we're only concerned with testing out the fundamental functionality of that feature?

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved