$p span.fast { color: red; }
In this case the parent is styled because it contains span.fast and the $ is the identifier .
http://davidwalsh.name/css4-preview
I've never understood what amounts to an incredibly useful feature was never considered before.
I read in that blog article you mentioned :local-link. Hitch also supports this but with even more ability: http://hitchjs.com/describe/bkardell.links/1
We'd love all the feedback we can get. Thanks for taking a look.
There are legit reasons for this, don't get me wrong - putting this natively in the browser opens a different can of worms. With Hitch, you "opt-in" and have the option to choose the features that you need. This means that the vast majority of sites can benefit from things that are problematic for the paradoxically hard cases (like the HTML living draft, single page edition with 135k+ and counting elements) -- and we think that is a good thing :)
But I just realized I've never once felt like I needed it in CSS. Can anyone give me a real-world example where this would actually be useful for styling? I almost worry this might make CSS more difficult to understand, rather than easier to write.
Say, an unordered list and the list items it contains can be styled based on the content that the list items may happen to contain; again without having to add classes to the parents.
Or maybe a form, you can add an error class to one of the inputs and then style the entire form based on the fact that one of the inputs has the error class.
Another use if you have one person entering text, such as with a CMS, then you can have another person code the CSS to handle differently possibilities of what different parents might contain. That way the person entering the text through a WYSIWYG editor wouldn't have to worry over adding classes to the parents while editing. It'll just happen.
It's not one of those features that will change CSS as we know it but it would be a useful feature. Over the years there were times I really wished I had this feature, mostly because it involved server-side generated HTML that would be a pain to get altered for one reason or another.
As noted elsewhere in the comments, this has been long (a decade plus) planned for "some future CSS" by editors and contributors. It didn't make the cut for selectors level 3 for reasons discussed in other comments here. It is currently part of 4 in potentially modified (and less powerful) form.
Personally, I find myself wanting it all the time. I frequently find myself littering HTML with (otherwise nonsensical) classes to achieve the sorts of things that this makes easy.
p < span.fast { color: red; }
Although that made perfect sense to me at the time, using some sort of subject signifier ("-hitch-has" or "$") makes much more sense.
There are plenty of free chars that wouldn't expect to cause conflicts with things like sass, or appear at a glance to be a variable reference.
Also: the "fork me on github" and repository links are all not working / broken. FYI
Hitch is quite a bit different than Sass/LESS. I wrote about this here: http://clint-hill.com/2012/05/06/changing-how-css-works-hitc...
Essentially Hitch looks to add behavior to CSS where Sass/LESS looks to make writing CSS easier. We love Sass/LESS and don't believe it's a competition with the libraries.
Obviously the spec might change and there's no way round that but seems better to hope for the best than to have a custom / branded pseudo-selector. - just a thought.
http://hitchjs.wordpress.com/2012/05/11/content-based-css-ma...
One of the reason we do not have the subject selector or :has() yet is that it is very hard to implement efficiently for dynamic updates. In the general case with :has(), you have to check the whole document for every DOM change.
In certain cases you have to check the whole DOM, in others not. We make our best effort to not if we don't have to, or at least to only do it once from up high in the tree if DOM changes are hot and heavy.
Is it efficient enough? So far it seems to be - but on a paradoxically hard page (like the HTML5 living standard, single page edition) with the wrong query, maybe not. But that's ok because a whole lot (far the majority I think) of Web pages should perform reasonably.
Yeah, I use that page as a crash-test too :)
Anyway, I haven’t dived in the source yet but I’m very interested in how this is implemented. How much can you hook into the browser’s selector engine / how much functionality do you have to duplicate? (I took over the cssselect project for WeasyPrint, but it is in Python without dynamic updates so the context is very different.)
<p><span class="fast">Red text</span></p>
with
p span.fast { color: red; }
will work just fine.
Edit: oh, I get it. You want the entire <p> tag to be red when the span starts part way through. Why not put a class on the <p>? It seems crazy counterintuitive to select elements backwards like that.
The ability to style based on content of the selector is powerful in this case.
