[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>

[cdoublev]

I think <length> && <number> cannot match 0 1 if you do not give priority to <length> for matching 0.

I noticed the ambiguity with border-image-outset, defined with [ <length [0,∞]> | <number [0,∞]> ]{1,4}. Its initial value is 0 but imo it should be 0px, because if you set border to 1px then border-image-outset to 0px, border cannot serialize to 1px because its reset-only sub-property border-image-outset is not declared with its initial value.

[dbaron]

I think the discussion the working group had related to the | combinator, which accepts exactly one of the alternatives. I don't think it's relevant to the && combinator or to the all-values-present case of the || combinator (since these combinators are not dependent on order of the grammar, from which you can infer that the parse-time handling of them is not greedy).

Or, to put it another way, when parsing <length> && <number> or <length> || <number> none of the values 0 1, 1px 0, 0 1px, or 1 0 is ambiguous. The first two have the <length> before the <number>, and the latter two have the <number> before the <length>.

However, the cases that are ambiguous, and thus affected by the resolution above, are parsing 0 as <length> | <number> or as <length> || <number>; the resolution above says it is parsed as a <number>.

[cdoublev]

Oh, you are right, backtracking should handle it. Thanks for the reply.

CSS Value is not 100% precise on this custom priority.

However, if a 0 could be parsed as either a <number> or a <length> in a property (such as line-height), it must parse as a <number>.

| combinator is not specified, and it can apply to <integer> | <length>, <number> | <length-percentage>, etc. Do you think it is worth opening a new issue?