W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2019

[csswg-drafts] [css-syntax] Do not require digits after decimal point for number tokens (#3599)

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Sat, 02 Feb 2019 00:33:07 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-405924714-1549067586-sysbot+gh@w3.org>
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-syntax] Do not require digits after decimal point for number tokens ==
(migrated from mailing list)

**Lea Verou said:**

> I’m not sure if this is even feasible at this point, but in case it is, here goes:
> 
> My proposal is to allow decimal points without digits after them so that CSS like the following is valid:
> 
> font-size: 1.em;
> line-height: 1.;
> 
> It would still change the type to "number", just step 4 of [1] would be reworded to "If the next input code point is U+002E FULL STOP (.), then:"
> 
> The reasoning is that currently there are many tools around that let authors edit CSS code and see the result in real time, including (but not limited to) browser debuggers. When the author is editing non integer lengths (e.g. from 2.5px to 2.9px), it usually goes like this (| denotes the caret):
> 
> 2.5px|
> 2.5|px
> 2.|px
> 2.9|px
> 
> Instead of being able to observe the result of their changes, all they see is a flash, since the 3rd step makes the value invalid, then it jumps back to 2.9px. It sounds trivial, but it’s encountered so frequently that it’s incredibly annoying.
> Not allowing such numbers is also inconsistent with Ecmascript, where numbers like 5. are perfectly valid.
> 
> ~ Lea
> 
> [1]: http://www.w3.org/TR/css3-syntax/#consume-a-number0

------------------

**Lea Verou said:**

> Actually, I just realized my example doesn't demonstrate what I meant. The numbers should have been 2px to 2.1px:
> 
> 2px|
> 2|px
> 2.|px
> 2.1|px

------------------

**Alan Stearns said:**

> It seems to me that this should be a fix in the tools that allow
> live-editing of values. I think it would be bad to allow 2.px as a value
> in a stylesheet. Just 2. by itself might be OK, but that’s not going far
> enough to solve your use case.
> 
> As a tools fix, there could be additional affordances that might be
> impossible to do in the grammar. If you have a value like 2px and you
> place the cursor at the end and start deleting, a tool could take what it
> knows of the previous state and allow 2p and 2 to be interpreted as 2px to
> avoid flashes before you’ve unambiguously changed the value. The tools
> display could show its assumptions in gray and commit the assumption when
> you leave the control.

--------------

**Tab Atkins said:**

> > It seems to me that this should be a fix in the tools that allow
> > live-editing of values. I think it would be bad to allow 2.px as a value
> > in a stylesheet. Just 2. by itself might be OK, but that’s not going far
> > enough to solve your use case.
> 
> Why would 2.px be bad?

------------------

**Alan Stearns said:**

> Looks like an error to me, but if that’s just me I’m fine with this. I
> suppose we’d be making work for libraries that parse CSS strings.
> 
> It just seems to me like an affordance that should be implemented at the
> tool level rather than extending the grammar.

------------------

**fantasai said:**

> Fwiw, I agree with Alan. Also, we shouldn't be changing CSS
> parsing rules lightly. This isn't a strong enough reason to
> make a change, imho.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3599 using your GitHub account
Received on Saturday, 2 February 2019 00:33:09 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:43 UTC