[css-values] Parsing "<integer> | <length>" or "<number> | <length>"

[upsuper]

From #460 I noticed that tab-size's syntax is <integer> | <length>, and I was confused on how 0 should be handled in this case, since 0 is valid as both <integer> and <length>. It seems the same issue applies to <number>, which line-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

[tabatkins]

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.

[upsuper]

It seems to me zero <length> is serialized as 0px, no?

[wargrey]

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.

[fantasai]

Agenda+ to ask if we should add a general rule to V&U that these ambiguous cases parse as <number>/<integer>

[css-meeting-bot]

The CSS Working Group just discussed CSS Values and Units: ambiguous zero, and agreed to the following resolutions:

• RESOLVED: Unitless zeros are parsed as numbers if it is ambiguous whether they are a <length> or a <number>

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>