search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.44k stars 657 forks source link

[css-inline] baseline-shift inconsistent regarding numbers #3975

Open ewilligers opened 5 years ago

ewilligers commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 https://github.com/w3c/csswg-drafts/issues/4874#issuecomment-614138114.

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

fantasai commented 4 years ago

@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.