[css-values] Parsing "<integer> | <length>" or "<number> | <length>" #489
From #460 I noticed that
I do not find the answer whether for whether
The text was updated successfully, but these errors were encountered:
It doesn't matter which it parses as; both end up with an identical effect and serialize the same way.
Tho, hm, I guess the Typed OM would want to make a distinction. I'm inclined to have it parse as integer/number, and would be happy to clarify that as a general rule in V&U.
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: CSS Values and Units: ambiguous zero
<fantasai> github topic: https://github.com//issues/489
<Rossen_> Github issue: https://github.com//issues/489
<myles> fantasai: we have a situation where you can have <interger> or <length> (or <nubmer> & <length> & it's not clear what happens with unitless zero.
<myles> fantasai: tab-size & line-height. which of these values does the 0 parse to?
<myles> fantasai: currently there is no behavior difference for these properties, but in the fiture it might matter
<myles> Rossen: so where would it matter?
<fantasai> cases are like <integer> | <length>
<myles> Rossen: in calc(), parsing would fail if you do it wrong
<fantasai> properties affected include tab-size and line-height
<myles> Rossen: in another expression, in grid gaps, or something else, it will always be interpreted as a <length>
<myles> fantasai: xidorn says that 0 lengths get serialized as "0px"
<myles> Rossen: the computed style?
<myles> fantasai: i dunno
<myles> fantasai: TabAtkins says that the OM might want to make a distinction
<fantasai> s/OM/Typed OM/
<myles> fantasai: we could make a rule "if you're in an imbiguous situation, it parses as a number"
<myles> Rossen: yes, and later in the cascade, you could typecast the number to an internal unit type, imlementation-specific, and the implementation could handle it
<myles> Rossen: the question is: what happens when you serialize it back out? Do you return the number or a real reallyrealies length
<myles> Rossen: for us, if we have to tag along an additional information about what i just described, it's going to be difficult
<myles> Rossen: not impossible though.
<myles> Rossen: doesn't buy authors much.
<myles> Rossen: (unless we have a specific example)
<myles> fantasai: we might not fix it, or we can say it parses as an integer
<myles> fantasai: those are the two options
<myles> fantasai: dbaron?
<myles> fantasai: <restates the question>
<myles> dbaron: i thought it would be anumber
<myles> fantasai: spec doesn't say that
<myles> fantasai: can we resolve?
<myles> Rossen: i have no problem keeping it as a number
<myles> Rossen: objections?
<myles> Rossen: to specify it as a number if it isn't already
<myles> RESOLVED: Unitless zeros are parsed as numbers if it is ambiguous whether they are a <length> or a <number>
Specify that 0 parses as a <number> if it's ambiguous whether it's a <number> or <length>. Fixes w3c/csswg-drafts#489 . w3c/csswg-drafts@b6b1b24b6cf0440adafd78ff5b9f1 b65ecd26d7c Remove ability for percentages to resolve against numbers. Fixes w3c/csswg-drafts#1463 . w3c/csswg-drafts@f2b85b3b1d655b03c137ca2ce31a4 cbcf1c1fdf2
I noticed the ambiguity with
I think the discussion the working group had related to the
Or, to put it another way, when parsing
However, the cases that are ambiguous, and thus affected by the resolution above, are parsing
Oh, you are right, backtracking should handle it. Thanks for the reply.
CSS Value is not 100% precise on this custom priority.