[css-syntax-3] Inconsistency in defining <number-token>

[tshinnic]

I believe the correct parsing of real numbers as specified by the railroad diagram is not implemented by the prose sections describing number parsing.

Specifically, it appears sections 4.3.12. Consume a number and 4.3.13. Convert a string to a number will allow "-E7" as a number.

This would conflict with the railroad diagram which requires something between sign and 'E'. It also seemingly conflicts with the spec's hyper-rigidity where "1.E1" is disallowed. (#3599)

(BTW: am I correct that that railroad diagram was copied from an older SVG spec?)

. Once again I was trying to find the definition for SVG real numbers and the chain of refs led me to CSS Syntax. Specifically I was trying to find the 'rightness' of an emitted "9e-5" or "-1e-4".

I find section <number-token> under 4.1. Token Railroad Diagrams and say "yay, I'm right!"

Then I find section 4.3.12. Consume a number and am dismayed. Then I realized that spec was merely confusing and did allow for "9e-5". Then it seemed it was so loose as to allow for gibberish - no number at all!

I checked section 4.3.13. Convert a string to a number figuring it would restrict further. But like 4.3.12 so many of the parts are optional, there is little in the way of a minimal content required.

Was it intended to allow "E99" as a <number-token>?

[Loirooriol]

Note: This algorithm does not do the verification of the first few code points that are necessary to ensure a number can be obtained from the stream. Ensure that the stream starts with a number before calling this algorithm.

-E7 and E99 don't seem to fulfill "starts with a number".

[tabatkins]

Yup, the parsing algo specifically calls out that it doesn't verify the number-ness, and assumes the caller will invoke "starts with a number" first. If you do, you'll correctly reject E99.

(BTW: am I correct that that railroad diagram was copied from an older SVG spec?)

No, I wrote those (and the library that creates them!) specifically for the Syntax spec. ^_^

[tshinnic]

I am glad I mentioned my motivation - needing a definition of valid real numbers in SVG.

SVG points to CSS-Values, CSS-Values points to CSS-Syntax, and now you are saying that none of those sources are 'normative', none actually definitive?

What is one to make of the absence of definition of something as simple as floating point number syntax? Can you point to where valid syntax for real numbers is defined?

. Digression: Years ago when flex-box came out a simple permutation of holy grail layout worked on 3 of the major browsers, but not on the 4th. After much discussion about the ~bug~ difference, one person on that 4th team pulled a Humpty-Dumpty and declared that one particular word in the spec meant what they said it meant, and no one else's opinion mattered. One word insufficiently specified, and thus a valid usage unavailable, because that browser was king, and so were they. Years later they left, a couple months after that the bug was quietly fixed. One word, one person, painful imprecision.

I know that specs are hard, agreement difficult, collegiality required and so compromises needed, but hey, practice on the easy stuff?

[tabatkins]

SVG points to CSS-Values, CSS-Values points to CSS-Syntax, and now you are saying that none of those sources are 'normative', none actually definitive?

No, I said (in the other issue about number tokens; you didn't ask about it in this one!) the chain terminates in Syntax's parsing algorithms, which are definitely normative and constitute the definition of every base-level syntax construct in CSS. We only want one normative definition of things; it can be helpful to present information in multiple ways (like a railroad diagram, or a short English description), but only one should be the actual definition.