-
200806 May
Posted in Declarations
Shaun Inman did a very interesting post yesterday on what he describes as “CSS Qualified Selectors”. The idea is nice, he wants to be able to do:
a { text-decoration: none; color: #A10; border-bottom: 1px dashed #A10; }And then for images:
a < img { border: none; }So if
<img>has a parent<a>, the border isn’t there.What’s most interesting about the post though is the comments. It seems, as Eric Meyer states there, that this kind of selector has been discussed quite a few times on the CSS mailing list, and isn’t doable. Dave Hyatt, one of the core WebKit developers, comments with a good explanation of why it can’t be done. It’s a nice read, and a good insight into the difficulties of developing a new standard.
You can skip to the end and leave a response.
-
Comments
-
01.
I’ve seen the “parent selector” requested on just about every open forum for CSS3 features. It may not be possible to do right now, but I foresee it happening sooner or later.
-
02.
I understand the reason given by browser makers for not wanting to implement this, but it does seem strange that we can perform similar functions in XPath & JavaScript without locking the browsers up. I still think it ought to be considered as a standard, however, even if current browser engines aren’t capable of supporting it.
-
03.
@Peter, the JavaScript examples are just not functioning in dynamic contexts (where you have to re-evaluate when anything changes in the document) or on particularly large sample sets. Browser makers could certainly implement a non-dynamic parent selector that would probably not be too terrible, but then people would just start filing bugs that it did not work dynamically (as they did with the sibling selector).
-
04.
Dave Woods - HTML, CSS, Web Design » Useful Web Development Links (7th May 2008) says:Comment » May 7th, 2008 at 10:03 am
[…] Shaun Inman proposes CSS Qualified Selectors […]
-
05.
I’d like to see two things in CSS.
1. CSS attribute selectors to apply to the full DOM, and updated in real time.
For example:
#article {max-height: 490px;}
#article+a {display: none;}
#article[height=490px]+a {display: block;}where you have a div containing some content, followed by a “read more” link. The article is clipped to 490px high, and if it reaches its max height, then the css then makes the “read more” link appear.
There are infinite useful applications to this, including form styling. Being able to style a checkbox (or more importantly, proceeding elements) – based on the real time checked state of the checkbox would be great!
input[type=checkbox][checked]+fieldset {display: block;}
2. CSS groups. I have to repeat the same selector over and over too many times. I’d like to be able to use braces much like @media selectors, but for regular selectors.
#article {
a {color: red;}
p {margin: 20px 20px 0 20px}
/* and so on… */
} -
06.
[…] Read a bit about “CSS Qualified Selectors” and why they’re a pain in the butt (via CSS3 . Info). […]
-
07.
paziek says:Comment » May 12th, 2008 at 2:21 pm
I’m not sure if its qualified or not, but I would like to be able to do sth like that:
#baka > a > img:hover {
#aho > p { display: none; }
#baka > span { color: red; }
}Basically sth like
if(statement) then statementI guess that this might look like suggestion in the post + comment from Kroc Camen, but I would prefer to do a bit more complex stuff with this idea.
-
08.
CSS “Cascading Style Sheets” Lessons
css list style Properties and examples — http://css-lessons.ucoz.com/list-css-examples.htm -
09.
Hi Guys,
I am very much interested to learn about css3 but at first, I would like to know, how should I incorporate CSS3 in my html document.
-
10.
The grouping suggestion made by Kroc Camen sounds like a pretty nice idea. I’m beginning to see the future of CSS like Prototype, Mootools, or jQuery was to Javascript.
jQuery: The Write-Less Do-More Javascript Library
CSS3+: The Write-Less Do-More CSS LibraryI’m thinking that every browser vender should have an addons site for the sheer purpose of allowing developers to add in their own implementations for CSS so that browsers can support certain features on an end-user basis, where CSS becomes something that is more-modularized. Firefox, for example, has many addons such as Web Developer and NoScript. Perhaps addons in the future for animations, transforms, parent selectors, and even reverse adjacent selectors would be nice.
The grouping idea sounds really good, and so far it’s something I haven’t heard recommended until reading the comments on this page. But I mentioned something above – reverse adjacent selectors. If it did become practical in the near future to take advantage of parent selectors through the (gt) sign, then it would be possible to have reverse adjacent selectors such as the following:
.article – .title{border:5px solid #77f;margin-bottom:1em}
In the above example, any element classed as “article” that came before any element classed as “title” would be given a bottom margin of 1em and a large bluish border.
If the > (gt) sign is used for child selectors, there should be a < (lt) for the opposite, and if the + sign is used for adjacent selectors, it should eventually follow that a – sign could be used for the reverse function. But I can understand how currently, something like this would not be easy to implement and the layout would not be dynamically-changed. Just as going back in time is a lot more difficult than going forward in time, reverse-examining the DOM is much more difficult than forward-examining the remainder of the DOM ahead of the current position. Doing it with Javascript is possible, but the easy way involves setting a special second class if a first already exists, or setting an unique id for the element that comes before the point that you want to select. The more difficult way (although not that difficult) would involve taking use of element arrays and then looping until the stop element is found, then taking the last element in the array that comes before the stop and applying the style dynamically that way. But so far, this involves a bit of script. Making script unobtrusive would be of paramount importance in this case or layout can break. It’s one of the underlying reasons why setting inline Javascript event/action attributes don’t serve much of a purpose anymore, especially with Javascript libraries such as jQuery, Mootools and Prototype.
To make reverse selectors practical, ever browser supporting this new standard would have to have script built-in to support it in the first place – script that is based on a new and ever-growing understanding of the DOM. The DOM would have to become less linear than it is in modern implementations.
One thing I would like about the future standard of CSS has a lot to do with Kroc Camen’s code here:
input[type=checkbox][checked]+fieldset {display: block;}
It’s much like an attribute selector; however, it’s a bit like an array too. Consider multiple background images as a potential problem:
.article{background-image:url(this.jpg),url(this-that.jpg),url(that.jpg)}
Let’s say you want to change just ONE of those background images…well you’d have to throw in the whole statement again later on down the code just to change one background…
.article2 + .article{background-image:url(this.jpg),url(your-mom.jpg),url(that.jpg)}
So an array key selector with which to mutate just one part of the multi-bg image array could look something like this (remember, arrays typically start with 0, not 1):
.article{background-image[1]:url(your-mom.jpg)}
In this case, the [ and ] would not really be a selector for an element, class, id, or attribute. It would be…a property selector. In markup there are elements, attributes and attribute values and in CSS there are selectors, properties and property values. We can select elements, ids, classes, attributes, and even attributes by value. We can’t really do much about selecting a sub-property of the property itself (unless you consider going from general properties such as margin to specific properties such as margin-bottom). I don’t believe that right now such a thing would be a valid recommendation, but it wouldn’t hurt in the future.
With so many styles out there now, and with animations, transitions, and transformations coming around, a lot of people are going to complain when designers begin abusing things like animations. Some may wish to opt out of being able to see CSS animations, for example, just as many people like me have their own style sheets customized to shut moving text up (this applies to sites that use the marquee tag and put things like links and images inside it – big no no in my book, especially when there are plenty of other ways to emphasize important text).
So on the point of opting-in or opting-out. The perfect way of being able to opt-out of something is to not even have it built into the browser in the first place, or at least have it turned off by default. As CSS advances, these separate modules could be implemented as add-ons, because there are MAJOR disagreements between designs, developers, and website visitors alike concerning CSS features such as animations, transitions, and transformations amongst other things. Much of what is being implemented will appear to be in lock with the standards to some, while the same features will appear annoying and non-standard to others, giving speed to the argument that more of these features will lead to more abuse of them. The end user must also be able to have some discretion when it comes to the functioning of the sites they visit, although a great part of the discretion lies with the designers. If an end-user (client) wishes to opt-out of using CSS animations, then that setting could either be off by default or offered as a browser addon on the vendor’s addon page. What’s standard and non-standard has conflicted more than ever in recent times when it comes to new ideas such as HTML 5, XHTML 2, and CSS3. For example, what’s the need for a section element in XHTML 2 when you can already use the div element with your own custom class to deliver to the browser how generic headings (the h element) should be set up as it is nested within these “sections”? If anything, the section element would be more of a semantic necessity. The l (line) tag is very much the same way, but I’m glad to see a line element coming (when or more likely, if, XHTML 2.0 is ever used in real world online applications. So much the same, being able to opt-in or opt-out (considering DOM changes all the while) would be nice and would create a better web. Animations and transitions in CSS3 would quite literally take much of the meaning away from Javascript. This is why people have script blockers – to block those kinds of things on unfamiliar websites. Firefox has a NoScript addon for that purpose. I can see down the road that Firefox may even deliver a “NoScriptRelatedCSS” addon or something similar.
Despite my objections to some proposed CSS3 features (and my praise for the possibilities of reverse adjacent selectors, grouping selectors, property array value selectors, parent selectors and so on), I still do think that CSS3 animations, transitions, and transformations is a remarkable and revolutionary idea. I’m just not sure if it’s needed right now, while there are still more critical items to iron out (in other words, animations have quite a low priority as compared with many other items such as selectors in CSS3).
IE8 is finally able to support all of CSS2.1 under standards IE8 mode, but defining an element with “overflow:scroll” when that element is inside another element with “float:left” or “float:right” will cause IE8 to jump into compatibility mode. When all problems regarding CSS2.1 have been ironed out for Internet Explorer, then and only then will IE have jumped into the CSS3 realm. IE8 does support attribute selectors, but besides that there isn’t much in terms of CSS3 support. Most CSS3 is supported only by proprietary property names with prefixes such as -khtml-, -o-, -moz-, and -webkit-. This may be the case for a few more years for most browsers, but this will definitely be the case for IE for at least another decade, unless things are starting to move along. The hasLayout bug is finally dead in IE8, and I’m glad they finally squashed that bug, but IE6 and 7 still represent the largest market share for IE at the moment, and will for the next couple of years. Nearly every site out there is still going to depend on their IE CSS hacks to get through yet another IE7-filled day of doom (doom meant literally, not in sarcasm, IE7 really is doom incarnate).
I like the idea of if-then selection in CSS, but it is starting to border on more of a programming language and no longer a tokenized style sheet language. However, it is an intriguing idea, since I for one even suggested array selectors within properties. And the entire idea behind some of CSS3 is to reduce your markup and reduce your CSS without using dirty performance-degrading tricks to do it! I’d even like the idea of ternary statements in CSS, but I know that’s pushing it. CSS variables are another one of those things people could opt-in or opt-out of, but that idea is fascinating as well.
Either way, whatever is decided upon for the future of CSS3, there will be mistakes along the way and if there weren’t, there’d be little challenge to fixing them. And at least the web is continuing to improve, one year at a time. W3C’s progress seems to be eternally-slow, but a little progress is better than none I’d say, since stagnation or a step back would be much worse.
-
11.
[…] CSS Qualified Selectors […]
-
01.
