[css-inline] baseline-shift inconsistent regarding numbers

[ewilligers]

baseline-shift syntax is defined as <length-percentage> | sub | super, with initial value 0. The initial value should round trip, so with this syntax it should be 0px, and the optionally supported value baseline should also be described as computing to 0px.

SVG 1.1 (and Blink and WebKit) also accepts numbers (interpreted as lengths). WebKit serializes these in specified and computed values with px units. Blink serializes these in specified values as numbers, and in computed values with px units. (Firefox does not support baseline-shift and EdgeHTML does not accept numbers.)

[fantasai]

I think this should just be handled the same way as other SVG unitless number quirks?

@AmeliaBR Anything specific we need to do in the CSS specs here?

[AmeliaBR]

This is more than just the quirky behavior for presentation attributes. The unitless values are also accepted in CSS declarations, so they should be part of the allowed value grammar (probably with a warning that this is obsolete / for legacy compatibility reasons, and maybe with some extra grammar fanciness to keep that legacy behavior from propagating to vertical-align).

Computed value should definitely be converted to px, but simple serialization should probably keep <number> and <length-percentage> types distinct. I think that's consistent with the resolution in #4874 (comment).

That would mean that a 0 would get parsed as a <number>, so the initial value should be explicitly 0px.

[fantasai]

@AmeliaBR Does SVG define some terms for this kind of quirky number parsing? Seems like if it's a behavior across multiple properties, the definition should be centralized.