Selecting matching attribute values in CSS


The trouble is, I see a lot of variants people might want (and do want), such as selecting elements with a data-subtotal less than data-minvalue (i.e. less than rather than equal to).

I’d rather see an xpath() function – xpath(section[@data-active-view = …/@data-view]) – (OK, I’m biased) – but the same problem exists for both, that they’re powerful enough you probably can’t get them in the “fast” CSS subset that’s allowed in stylesheets.


I think the fact that you can have far more complicated comparisons is not inherently a mark against the proposal, in the same way that a parent selector being difficult isn’t an argument against including the child selector.

I think data comparisons in CSS are interesting I think it massively overcomplicates this far more simple usecase, especially when you consider that you’d have to introduce variable parsing, questions about whether strings should also be compared with less than and null/undefined handling in CSS. While the latter definitely looks like it would be the CSS slow profile I’m not so sure a simple matching selector would have to be. It would be interesting to hear from someone that works on browser CSS engines on this issue.

I can see that xpath() in JS would be a benefit to some but adding it to CSS should be a no go as it’s not just a new selector it’s a whole query selection language in itself.


Thanks for replying. XPath is already in the Web Platform (albeit XPath 1 from 1999) so it’s not really new. I can see more support likely for exposing native (e.g. JavaScript) functions in CSS, as long as there’s a good fallback story. This use case is, however, a data comparison use case - wanting to find an element having an attribute value equal to that of some other element’s attribute. It’s a very common use case, and can’t in general be streamed. But people usually go from wanting this to wanting more complex variants, and you can quickly get into a mess, so my own opinion is it’s a case to be considered but not in isolation.


I think arbitrary JS in CSS even in the slow path would get messy. Ultimately the slow path is only used for returning a set of nodes in JS via querySelector so if an XPath JS function returned nodes anyway I’m not sure what would be improved by adding it at the CSS level (ditto for arbitrary JS, its only use is while in JS anyway so why obfuscate by writing JS in CSS in JS?).

Would be interesting to get @tabatkins view on some of the things mentioned here.


exposing the computed value of a css variable at a specified scope in a selector string.

I’m not entirely sure I understand what is going on in that example but it’s conceivable that given we might be able to cover these use cases already…