Fishy value parsing

[oliverklee]

At least font-weights schon be integers, but we're parsing them as floats. We'll need to entangle this.

[JakeQZ]

font-weight, if a number, can only be a multiple of 100 between 100 and 900. Most browsers will round to nearest 100. This is an oddball case where the numbers might be pedantically considered as keywords.

Most numeric values take a CSS number. That can be floating-point or integer.

I don't think it's the job of the parser to be concerned about such specifics, which may change in future anyway.

Also, we want to replicate browser behaviour, which is to be as lenient as possible. Allow anything, even if wrong.

Sorry, I vote to close this as not a bug. CSS validility checking based on whatever the current W3C rules are is beyond the scope of a parser.

We are removing the feature of expanding shorthands, as beyond remit. I think the same applies here.

The parser doesn't need to understand the minutiae of what it parses; it just needs to be able to parse it based on syntactic comstructs. Special-casing certain properties should be avoided if at all possible, and should be possible to avoid in all cases. If not, there is a bug in the spec, and we should be contacting W3C about it.

[JakeQZ]

Also, integers stored as floats don't cause a problem. They can be represented exactly up to about 10³⁰⁸ in 64-bit, and 10³⁸ in 32-bit.

The rounding errors come in when arithmetic is performetd. 1/3 cannot be accurately represented in floating point, so if you do 1 + 1/3 + 1/3 + 1/3 you may get 2.000000001 or 1.999999999.

The parser does not perform arithmetic, although it parses arithmetic functions.

[oliverklee]

Okay, closing then.