Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

upsuper opened this issue Sep 15, 2016 · 8 comments


Copy link

upsuper commented Sep 15, 2016

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

Copy link

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.

Copy link
Member Author

upsuper commented Sep 16, 2016

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

Copy link

wargrey commented Sep 16, 2016

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.

Copy link

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

Copy link

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:
<Rossen_> Github issue:
<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>

triple-underscore added a commit to triple-underscore/ that referenced this issue Jun 10, 2017
Specify that 0 parses as a <number> if it's ambiguous whether it's a
<number> or <length>.
Fixes w3c/csswg-drafts#489 .

Remove ability for percentages to resolve against numbers. Fixes
w3c/csswg-drafts#1463 .
Copy link

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.

Copy link

dbaron commented Aug 16, 2022

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

Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

7 participants