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

Closed
upsuper opened this Issue Sep 15, 2016 · 5 comments

Comments

Projects
None yet
5 participants
@upsuper
Member

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

@tabatkins

This comment has been minimized.

Member

tabatkins commented Sep 15, 2016

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

This comment has been minimized.

Member

upsuper commented Sep 16, 2016

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

@wargrey

This comment has been minimized.

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.

@fantasai

This comment has been minimized.

Contributor

fantasai commented May 17, 2017

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

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented May 24, 2017

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>

@tabatkins tabatkins closed this in b6b1b24 Jun 9, 2017

triple-underscore added a commit to triple-underscore/triple-underscore.github.io that referenced this issue Jun 10, 2017

[css-values] Specify that 0 parses as a <number> if …他
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment