Content Based CSS(hitchjs.wordpress.com)
hitchjs.wordpress.com
Content Based CSS
http://hitchjs.wordpress.com/2012/05/09/content-based-css-hitch-has/
25 comments
Yes in trivial cases you might put a class on the P element. But what about when you have dynamic updates to the DOM? If I have 15 P elements in a collection and not all have content (think of a discussion thread and comments) - how would I specify which P elements to style vs. those I don't want styled?
The ability to style based on content of the selector is powerful in this case.
The ability to style based on content of the selector is powerful in this case.
This is a sorely missed feature but there's already discussion to support this within CSS. The idea seems to be around having an identifier within the selectors to mark which one is actually getting its properties changed. Something like this:
$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.
$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.
(one of the authors) We agree with you. Yes it is being discussed. But you can do it now with Hitch. Our goal with Hitch isn't necessarily to create a new standard, as much as it is to influence the standards to move more quickly. Likewise with browser vendors.
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.
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.
(the other author) It is definitely worth noting too that this was first proposed and seriously discussed well over a decade ago now. The subject selector is inherently less powerful than the original (has) proposal, but even that got pushed out to selectors level 4 and (if you keep an eye on the lists) there is a very real possibility that it may get shoved to selectors 5.
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 :)
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 :)
I wasn't actually saying anything one way or the other about your project, I was just making the comment that there were discussions of doing this directly in CSS.
Interesting... there have been lots of times I've wanted this kind of functionality in jQuery selectors or XPath...
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.
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.
It would be helpful in cases of dynamically inserting markup into the page. If the CSS was coded to account for the possibilities then you only have to insert your new HTML into the page without having to add a class to its parent.
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.
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.
:has has been a part of jquery for forever. XPath has axis which allows similar expressive powers.
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.
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.
I once saw someone try to describe a hypothetical selector that did this using this syntax:
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.
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.
While I like the idea, I feel the dollar sign is a poor choice of character.
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.
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.
The bang (!) sign would make more sense to me. It's already used in css to express priority (!important), so it's not much of a logical jump.
Yes there has been lots of bike shedding. A lot of people, myself included, have lobbied that ! in CSS is already an abomination (because in normal programming it generally means 'not').
Currently the discussions/draft/etc don't match or agree on what the syntax or capabilities will be.
Our :-hitch-has is based on the original :has proposal and the existing implementation in jQuery as we feel that this is the best (and clearly the most powerful since it allows you to express more).
Currently the discussions/draft/etc don't match or agree on what the syntax or capabilities will be.
Our :-hitch-has is based on the original :has proposal and the existing implementation in jQuery as we feel that this is the best (and clearly the most powerful since it allows you to express more).
I'm struggling to figure out how this works. All of the functionality reminds me of SASS/LESS pre-processors - is it essentially doing what the LESS framework does and (post) processing the CSS on the client side, or is it doing something more magical than that?
Also: the "fork me on github" and repository links are all not working / broken. FYI
Also: the "fork me on github" and repository links are all not working / broken. FYI
Thanks for taking a look. We'll get on those links (thanks for that! ).
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.
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.
So I'm curious if you say it 'hitches/intercepts' the css of the browser, why not implement the proposed spec as is, instead of a custom function ie: '-hitch-has' that way at least if the spec does get approved then sites using hitch benefit from already following the spec.
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.
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.
That's a very good thought. We struggled with that during the development of -hitch-has() and a few others. Ultimately we landed on the position of getting an implementation out there that was functionally equivalent.
CSS Selectors 4 (http://www.w3.org/TR/2011/WD-selectors4-20110929/#subject) points out a syntax that is currently using "$". But that has also been suggested as "!" in the past. It's a tough thing to get nailed down, but we decided we'd rather not wait to have the functionality.
CSS Selectors 4 (http://www.w3.org/TR/2011/WD-selectors4-20110929/#subject) points out a syntax that is currently using "$". But that has also been suggested as "!" in the past. It's a tough thing to get nailed down, but we decided we'd rather not wait to have the functionality.
Since it has changed so many times and there still isn't agreement it wouldn't be prudent to even pretend that this is shimming something that is planned for CSS.
Indeed, this is merely one new selector that Hitch provides - there are lots more, and a plugin model which allows an unlimited number in the future. They all follow CSS' forward compatible parsing rules and so, by their nature, they sort of have to follow prefixed pseudo form as a rule.
Indeed, this is merely one new selector that Hitch provides - there are lots more, and a plugin model which allows an unlimited number in the future. They all follow CSS' forward compatible parsing rules and so, by their nature, they sort of have to follow prefixed pseudo form as a rule.
For posterity, viewing a few more examples may be the best way to help differentiate and understand their different purposes:
http://hitchjs.wordpress.com/2012/05/11/content-based-css-ma...
http://hitchjs.wordpress.com/2012/05/11/content-based-css-ma...
Very nice. But does it react dynamically when I update the DOM?
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.
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.
Yes, Simon, yes it does :)
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.
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.
> but on a paradoxically hard page (like the HTML5 living standard, single page edition) with the wrong query, maybe not.
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.)
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.)
We'll have to write up an article about how it works. I'm sure we'll be iterating on the source quite a lot now that we have a nice working set of things...
Essentially though, we look at the modification to narrow down the potentially matching rules, then we use querySelectorAll/matchingfns at the appropriate spot in the tree. Each selector (like :-hitch-has) then has a filter function which merely returns true/false (just like jquery) and based on that we toggle an associated class on the element and the rest is just the browser's native CSS doing what it does.
Essentially though, we look at the modification to narrow down the potentially matching rules, then we use querySelectorAll/matchingfns at the appropriate spot in the tree. Each selector (like :-hitch-has) then has a filter function which merely returns true/false (just like jquery) and based on that we toggle an associated class on the element and the rest is just the browser's native CSS doing what it does.
Fix: content based Javascripted css
<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.