[css-values] Parsing " | " or " | "

[upsuper]

From #460 I noticed that tab-size's syntax is | , and I was confused on how 0 should be handled in this case, since 0 is valid as both and . It seems the same issue applies to , which line-height uses.

I do not find the answer whether for whether 0 should be parsed as or 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 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 /

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

The full IRC log of that discussion

Topic: CSS Values and Units: ambiguous zero
github topic: https://github.com//issues/489
Github issue: https://github.com//issues/489
fantasai: we have a situation where you can have or (or & & it's not clear what happens with unitless zero.
fantasai: tab-size & line-height. which of these values does the 0 parse to?
fantasai: currently there is no behavior difference for these properties, but in the fiture it might matter
Rossen: so where would it matter?
cases are like |
Rossen: in calc(), parsing would fail if you do it wrong
properties affected include tab-size and line-height
Rossen: in another expression, in grid gaps, or something else, it will always be interpreted as a
fantasai: xidorn says that 0 lengths get serialized as "0px"
Rossen: the computed style?
fantasai: i dunno
fantasai: TabAtkins says that the OM might want to make a distinction
s/OM/Typed OM/
fantasai: we could make a rule "if you're in an imbiguous situation, it parses as a number"
s/imbig/ambig/
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
Rossen: the question is: what happens when you serialize it back out? Do you return the number or a real reallyrealies length
Rossen: for us, if we have to tag along an additional information about what i just described, it's going to be difficult
Rossen: not impossible though.
Rossen: doesn't buy authors much.
Rossen: (unless we have a specific example)
fantasai: we might not fix it, or we can say it parses as an integer
fantasai: those are the two options
fantasai: dbaron?
fantasai:
dbaron: i thought it would be anumber
fantasai: spec doesn't say that
fantasai: can we resolve?
Rossen: i have no problem keeping it as a number
Rossen: objections?
Rossen: to specify it as a number if it isn't already
RESOLVED: Unitless zeros are parsed as numbers if it is ambiguous whether they are a or a

[cdoublev]

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

I noticed the ambiguity with border-image-outset, defined with [ | ]{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 && or || none of the values 0 1, 1px 0, 0 1px, or 1 0 is ambiguous. The first two have the before the , and the latter two have the before the .

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

[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 or a in a property (such as line-height), it must parse as a .

| combinator is not specified, and it can apply to | , | , etc. Do you think it is worth opening a new issue?