[css-values] Parsing "<integer> | <length>" or "<number> | <length>" #489
Comments
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. |
It seems to me zero |
I define a CSS:Zero for 0 as a subtype of CSS:Integer in my engine which implemented in a typed language(There also is a CSS:Flzero for 0.0). Then I can easily handle these two special number types when a dimension type is required. |
Agenda+ to ask if we should add a general rule to V&U that these ambiguous cases parse as |
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" <fantasai> s/imbig/ambig/ <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@b6b1b24 b65ecd26d7c Remove ability for percentages to resolve against numbers. Fixes w3c/csswg-drafts#1463 . w3c/csswg-drafts@f2b85b3 cbcf1c1fdf2
From #460 I noticed that
tab-size
's syntax is<integer> | <length>
, and I was confused on how0
should be handled in this case, since0
is valid as both<integer>
and<length>
. It seems the same issue applies to<number>
, whichline-height
uses.I do not find the answer whether for whether
0
should be parsed as<integer>
or<length>
in this case from css-values spec. Am I missing something, or probably the spec should say something about this case?cc @fantasai @tabatkins
The text was updated successfully, but these errors were encountered: