

Content Based CSS - clintjhill
http://hitchjs.wordpress.com/2012/05/09/content-based-css-hitch-has/

======
Domenic_S
Wait, what am I missing?

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

~~~
clintjhill
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.

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

~~~
clintjhill
(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.

~~~
bkardell
(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 :)

------
iambot
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

~~~
clintjhill
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...](http://clint-hill.com/2012/05/06/changing-how-css-works-hitch/)

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.

~~~
iambot
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.

~~~
clintjhill
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.

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

~~~
bkardell
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.

~~~
SimonSapin
> 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.)

~~~
hitchjs
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.

------
gcb
Fix: content based Javascripted css

