Re: [csswg-drafts] [css-conditional-6] Behavior of style(0 = 0px) (#12236)

The CSS Working Group just discussed `[css-conditional-6] Behavior of style(0 = 0px)`, and agreed to the following:

* `RESOLVED: 0 and 0px are quivalent for conditions`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> andruud: Parser has behavior for &lt;length> that you can supply 0 without unit<br>
&lt;fantasai> andruud: question came up during range queries, whether we should keep that behavior for comparison<br>
&lt;fantasai> andruud: e.g. is 0 = 0px for style queries?<br>
&lt;fantasai> andruud: zero is a number, 0px is a length, so not equal<br>
&lt;miriam> q+<br>
&lt;fantasai> andruud: in terms of consensus, it seems to be everyone against tab ;)<br>
&lt;emilio> q+<br>
&lt;kizu> q+<br>
&lt;astearns> ack miriam<br>
&lt;noamr> q+<br>
&lt;astearns> ack emilio<br>
&lt;oriol> q+<br>
&lt;fantasai> miriam: I don't have a strong opinion either, just unhappy that neither option is consistent across the board<br>
&lt;fantasai> emilio: I will side with Tab on this one<br>
&lt;fantasai> emilio: style queries are generally untyped<br>
&lt;lea> q?<br>
&lt;lea> q<br>
&lt;fantasai> emilio: and you have the same issue with calc(), don't know if zero is degrees length etc.<br>
&lt;lea> q+<br>
&lt;fantasai> TabAtkins: unitless zeros in calc() screw up figuring out the type of the calc()<br>
&lt;fantasai> TabAtkins: that doesn't apply here, just comparing two things<br>
&lt;fantasai> TabAtkins: We could go either way<br>
&lt;fantasai> emilio: for something like width > 0, you know width is a length<br>
&lt;fantasai> andruud: yeah, we'd need to do different special casing<br>
&lt;TabAtkins> like, is `calc(0 / 10px)`, is that unit 1/length, or just &lt;number>?<br>
&lt;fantasai> TabAtkins: but you can use width > 0 in MQ<br>
&lt;fantasai> emilio: you know you're parsing a length at that point<br>
&lt;fantasai> TabAtkins: yes but because they're zeros...<br>
&lt;fantasai> emilio: implementable, not a big issue<br>
&lt;astearns> ack kizu<br>
&lt;fantasai> kizu: I think I want them  ...<br>
&lt;fantasai> kizu: if you define custom registered property [missed]<br>
&lt;fantasai> kizu: for type, getting type of a custom property and you want to understand later on, you explicitly say "I'm checking the type on this"<br>
&lt;fantasai> kizu: but authors will expect 0 to 0px, so consistent for if() etc. to work this way<br>
&lt;astearns> ack noamr<br>
&lt;fantasai> noamr: aren't style queries also typed?<br>
&lt;kizu> https://codepen.io/kizu/pen/azvYVJw<br>
&lt;fantasai> noamr: can't we do something where if both values when parsed ...<br>
&lt;fantasai> TabAtkins: no, we don't necessarily know<br>
&lt;fantasai> noamr: they're all matching a property<br>
&lt;fantasai> TabAtkins: not necessarily, e.g. inside an 'if'<br>
&lt;astearns> ack oriol<br>
&lt;fantasai> oriol: I'm slightly more with Tab here<br>
&lt;fantasai> oriol: I could go either way for lenghts, but other dimensions that can accept unitless zeros so weird to accept<br>
&lt;astearns> ack lea<br>
&lt;fantasai> oriol: even for lenghts, lean more towards Tab, but it's a weak opinion<br>
&lt;fantasai> lea: My expectation is to compare the unitless zero to the other side<br>
&lt;fantasai> lea: if they're valid, then they should match<br>
&lt;fantasai> lea: e.g. zero for angles is not generally valid<br>
&lt;fantasai> lea: so would expect not to match in that case<br>
&lt;fantasai> lea: Where did we resolve to use style() for these comparisons<br>
&lt;astearns> ack fantasai<br>
&lt;astearns> fantasai: what lea said<br>
&lt;lea> q+<br>
&lt;fantasai> noamr: I think it would be sensible to start by shipping something more rigid, and then add type-based equivalence later, maybe more than just unitless zero<br>
&lt;lea> q-<br>
&lt;fantasai> astearns: that would be type coercion<br>
&lt;lea> q+<br>
&lt;lea> q- (sorry)<br>
&lt;fantasai> noamr: start with that and then do === later<br>
&lt;fantasai> noamr: more use cases than just unitless zero<br>
&lt;astearns> s/be type/be explicit type/<br>
&lt;astearns> ack lea<br>
&lt;fantasai> lea: My concern is case where you have a custom property (token stream) and then you register as a length, and now it stops matching<br>
&lt;fantasai> lea: would be better if consistent with how lengths generally work<br>
&lt;astearns> ack fantasai<br>
&lt;astearns> fantasai: from a user perspective we’re used to 0 = 0px<br>
&lt;lea> +1<br>
&lt;TabAtkins> I would be okay with a literal 0 allowing matching against a 0 &lt;number> *or* a 0 &lt;length><br>
&lt;TabAtkins> but a calculated 0 shouldn't be, maybe?<br>
&lt;ydaniv> +1 to fantasai<br>
&lt;miriam> +1 (but that inconsistency is already confusing people in calc)<br>
&lt;TabAtkins> 1. calc()-consistency, 0 != 0px<br>
&lt;TabAtkins> 2. property-consistency, 0 == 0px (but no other unit)<br>
&lt;fantasai> TabAtkins: it is the case that calc(0) is invalid in [missed], so it would have to be a literal zero<br>
&lt;TabAtkins> s/missed/width prop/<br>
&lt;fantasai> astearns: Proposed resolution that literal zero does equal a 0 length for conditions<br>
&lt;fantasai> astearns: Anyone want to argue against?<br>
&lt;fantasai> astearns: Anyone want to object?<br>
&lt;fantasai> RESOLVED: 0 and 0px are quivalent for conditions<br>
&lt;TabAtkins> (making clear, i mistyped above; "no other type", not "no other unit". 0 == 0rem, too)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12236#issuecomment-3204826253 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 20 August 2025 08:32:02 UTC