- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 18 Mar 2026 16:48:20 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-selectors] add numeric comparisons on attribute values`, and agreed to the following: * `RESOLVED: accept proposal but limited to just numbers, not lengths or percentages` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/5890#issuecomment-3560632480<br> <JoshT> TabAtkins: numeric comparisons on attribute selectors<br> <JoshT> ... now you have to do right-hand side of string in quotes<br> <JoshT> ... we will parse the attribute as a number, length, percentage as appropriate<br> <JoshT> ... if it doesn't parse, auto fails<br> <Rossen> q?<br> <JoshT> ... if it is a length, canonicalisses the same way as media queries<br> <JoshT> ... use cases, back in the say, HTML attribute didn't have numbers anyway<br> <JoshT> ... more common to ost a data attribute that meant something<br> <JoshT> ... right now you have to work around it with an adder function or container query, but that's silly for simple cases<br> <florian> q+<br> <emilio> 1+<br> <JoshT> ... so this sounds reasonable to me. thoughts?<br> <emilio> q+<br> <JoshT> Rossen: sounds great! understand compat risk?<br> <JoshT> TabAtkins: any such selectors that match this are invalid, so minimal compat risk<br> <davidjmarland> sounds responsible to me. I can see many use cases<br> <Rossen> ack florian<br> <JoshT> florian: like the idea, wondering about conversions<br> <lea> q+<br> <JoshT> ... pixels and inches convert. but what about units without fixed ratios. you say do it like media queries?<br> <JoshT> ... could you also not convert?<br> <JoshT> ... unlike media queries, you don't have that context. maybe they'd rather have a local conversion?<br> <JoshT> ... px to ems never matches, for example<br> <JoshT> TabAtkins: if you said you write your comparison value as an em as well, you can't tell the difference<br> <JoshT> ... because there's an established way they're interpretted, there's some value in having it work the same way<br> <JoshT> florian: ok. also, if you add a length value in your selector, do we treat the number as a px value?<br> <JoshT> TabAtkins: i think we make it fail.<br> <JoshT> florian: when you have lengths in attributes, they don't have a px unit but it's implied<br> <JoshT> ... also if you have a % on one side and ??? on another, what do you do?<br> <JoshT> TabAtkins: we should not try to predict for them<br> <Rossen> ack emilio<br> <JoshT> emilio: have a strong preference for only starting with numbers<br> <JoshT> ... for styling use cases, if you compute styles with container queries, you can do useful stuff<br> <JoshT> ... numbers get 90% of the way there, especially if we're not resolving percentages<br> <fantasai> +1 to emilio and florian<br> <JoshT> ... numbers proposal seems uncontroversial<br> <lea> Also +1 to emilio and florian<br> <JoshT> ... if we see demand for units, we can analyse those<br> <JoshT> ... I don't see a lot of value in a value with 3em not stashed with an adder<br> <JoshT> ... should this use HTML rules for parsing numbers?<br> <JoshT> TabAtkins: probably OK.<br> <JoshT> ... I think it's OK if we just want to do pure numbers and leave other units for future<br> <JoshT> ... and parsing... I don't know if I care too much<br> <JoshT> ... differences between the two are only if you write something bizzare<br> <JoshT> ... I lean to using the machinery of attr() parsing<br> <romain> q+<br> <JoshT> emilio: no strong preference for me other than something well defined. consistant with attr() sounds good<br> <JoshT> TabAtkins: if we do expand to units, that's well defined rather than having to do something new<br> <JoshT> fantasai: agree with florian's concerns about interpretting element relative units in generic way<br> <JoshT> ... I think users would expect more local<br> <JoshT> ... they'd be surprised<br> <romain> q-<br> <Rossen> ack fantasai<br> <JoshT> ... regarding comparing things like num treated as something else, we could introduce a multiplier as a param so the author can say 500 means 500px<br> <JoshT> ... but to simplify to num for now makes sense to me<br> <JoshT> ... regarding numbers, can see that HTML parsing algorithm might be more flexible<br> <JoshT> ... like it ignores units, right`?<br> <JoshT> TabAtkins: that would be a reason why I would not want to use it. then we can't expand to include units in the future<br> <JoshT> fantasai: you could, because you could say 'does the value end in em? then check whatever syntax the author is using, do a string check'<br> <JoshT> ... that could be useful<br> <JoshT> TabAtkins: possibly<br> <Rossen> ack lea<br> <fantasai> s/string check/number check after extracting the number/<br> <JoshT> lea: +1 to overall feature<br> <JoshT> ... like others, have reservations about units and agree numbers alone address 99% of use cases<br> <JoshT> ... can we ship units later or would that not be web compat?<br> <JoshT> ... i also think that interpretting units in a general context would be weird<br> <kurt> q+<br> <JoshT> ... but in an element context, wouldn't that make selector matching depend on computed style?<br> <JoshT> ... that would be a good reason to defer<br> <TabAtkins> Looking at HTML, the "parse a floating point number" does not allow units https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#floating-point-numbers<br> <Rossen> ack kurt<br> <JoshT> kurt: for SVG width and height, they get converted to px. would that not work here?<br> <JoshT> TabAtkins: I think that functionality is handled by styling stuff, so not relevant here<br> <JoshT> ... if you write a number, you parse as a number<br> <JoshT> kurt: so it still matches as a number and doesn't matter if it ends up as a pixel?<br> <JoshT> ... fine but just a weird case<br> <davidjmarland> I can see use cases for numbers and percentages as it's linking data to styles. Trying to think of a use case where a sizing unit would be in a data attribute and then used in a comparison to do styles other than using it exactly.<br> <JoshT> PROPOSED: limit this to just numbers, not length or percentages. and use attr() function's parsing algorithm, not HTML's<br> <Rossen> ack fantasai<br> <lea> davidjmarland: Here is one use case: https://webawesome.com/docs/components/page#responsive-navigation<br> <JoshT> fantasai: i'd like to take a closer look at the parsing for HTML. we might like to go with it<br> <JoshT> TabAtkins: apart from whether it supports trailing whitespace, it looks the same<br> <JoshT> fantasai: [quotes spec]<br> <JoshT> TabAtkins: I don't know what you're looking at<br> <JoshT> fantasai: trying to see if it returns an error if it sees not a digit<br> <JoshT> castastrophe: can we resolve on first half?<br> <JoshT> Rossen: or both and change it later?<br> <JoshT> TabAtkins: I don't think it's important right now<br> <JoshT> PROPOSED: limit this to just numbers, not length or percentages.<br> <JoshT> RESOLVED: accept proposal but limited to just numbers, not lengths or percentages<br> <TabAtkins> I see that "valid floating point number" is distinct from "parse as a floating point" <https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values>; the latter is more permissive<br> <JoshT> florian: typically people will assume HTML parsing will apply, so we might not want to exclude things that people think are valid there<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5890#issuecomment-4084028233 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 March 2026 16:48:20 UTC