With complex layouts, I think this could let you reduce the size of your files a fair bit, as well as helping to group CSS together in a more logical way.
It’s also something that could be fairly easy to implement, and if it was, the CSS interpreter would still be backwards compatible with standard CSS styles as well.
but this opens the door to other possibilities and increases the risk of confusion which leads to mistakes.
i mean, how will the selector combination, or “+” for sibling, or “>” for child and so on will be added to the equation when applied to two or more such complex css selector declarations?
The beauty of a solution like this is that you actually don’t have to change it, you just add to it.
If it was changed to work with that, it would still be valid to have them all single as well (how they are now), so you wouldn’t have to use the new style if you didn’t want.
The best place is the W3C www-style mailing list, and it just so happens someone’s brought up something similar linky
I think the big problem would be that they would have to change the core grammar in order to do that. I agree that would be a massive space and time saver to be able to do that though!
I certainly don’t want to use some framework which adds extra file size and load just to do this, but it’d be nice if it was built in.
As for file size, it really depends. However, for example, I’m working on a project now where each selector has like 4+ parts (ex: .hasJS.home #anID li), so I could cut out about a dozen .hasJS.home, and that’s just for one page. Also, if you compress it before releasing it to the web, the tabs make no different at release.
I’m not saying it would cut it in half, but it’d be some savings, it’d just be something nice to have.
I also wonder if it couldn’t make the interpreting of CSS by browsers a bit faster, since it could also skip a bunch of interpretations as well.
The reality of getting it implemented to where you could use it though would be a LOOONNNNGGGG way off (I’m looking at your IE).
I can see where you’re coming from with your idea, but I’m not sure the file size would be reduced by much.
For easy readability, you would still have to indent the #blah#huh and #foo selectors otherwise it would not be so obvious that they are nested and belong to .a.b.c
Personally, I am happy with the current format from the point of readability and it is easier for me to see what is going on - maybe I’m just getting old
As long as they also retain the current format, which they would have to for backwards compatability, then I would be happy
'Twould be nice, but it’s probably wishful thinking… at least for the time being! I wonder if there’s a place where something like this could be proposed officially?