[css-syntax] Should numbers have type integer whenever the actual value is an integer?

[romainmenke]

See : https://drafts.csswg.org/css-syntax/#consume-number

Also mentioned in passing by @tabatkins here : #6471 (comment)

As a result of the current tokenizing rules these values have type number :

• 10e3
• 1000.0

While both arguably represent integer values.
Should the algorithm be updated to reflect this?

You can see the difference between numbers with type number and integer in action here : https://codepen.io/romainmenke/pen/GRLwLQy

Wrapping values of type number in a math expression already "normalizes" these into integers when possible. (e.g. z-index: calc(10e3) works)

[romainmenke]

@cdoublev said :

I think <integer> only exists for some corner cases of the CSS grammar. There should be a default rounding behavior in properties like order, z-index, etc.

Another argument is that Number.isInteger(1.0) is truthy, probably like in most if not all progaming languages.

[fantasai]

Anything with a decimal point should not be parsed as <integer>, imho.

[tabatkins]

Agreed on that point. The only real point of contention, I think, is whether sci-not can produce integers - both 1e3 (very reasonable) and also 1.2e3 (equivalent to 1200, so maybe?)

[cdoublev]

How does producing an integer from scientific notation differ from producing it from decimal notation? It seems that both depend on evaluating the mathematical value of the input number. I have no math/cs degree so please forgive me if the answer is obvious.

Could it be useful to produce <integer-token> from signed/unsigned digits? Only <number-token> would serialize with sci-not and :nth-child(1e1) would remain invalid.

[Loirooriol]

IMO if 5.0 isn't an integer, it would be weird for 5.0e0 to be an integer.

[romainmenke]

https://drafts.csswg.org/cssom/#serializing-css-values

Could say that anything that serializes into an integer is actually an integer.
That can't be the spec text, but conceptually that has few surprises.

[Loirooriol]

Note that spec needs edits: #8538 (comment)

[tabatkins]

Ah right, we are still missing that edit, partially because of this issue (and partially because I forgot about it).

Okay, proposal:

A number is an integer if it either:

• has no decimal component or scinot component (5.0 counts as "having a decimal component", so not an integer)
• has no decimal component, but has a non-negative scinot component (5e0 is an integer, 5e3 is an integer, 5e-1 is not)
• has a decimal component with N digits after the decimal point, a positive scinot component with value M, and N <= M (5.0e0 is not an integer, 5.0e1 is an integer, 5.00e1 is not an integer.)

The serialization edit from #8538 will satisfy this; since we serialize to no more than 6 digits after the decimal point, and scinot doesn't kick in for large number until it's substantially larger than a million, any large-number scinot will necessarily be parsed as an integer.