[css-inline] CSS properties appply to SVG elements

[dirkschulze]

Some of the properties in CSS inline apply to certain SVG elements as well. According to SVG2:

• alignment-baseline to tspan and textPath elements
• baseline-shift to tspan and textPath elements
• dominent-baseline to text content elements
• inline-sizing to text elements (at-risk for SVG 2)
• line-height to text content elements (SVG2 actually misses to specify it) CC @AmeliaBR

Those are the properties currently covered by SVG's text algorithms. Some of the other properties in CSS inline layout should apply to certain SVG elements as well in the future.

[AmeliaBR]

I'm working on these edits, per @fantasai's request (trying to clean up issues on CSS Inline for publication).

I'm trying to use the categories currently defined in SVG 2: text content elements (for any of text, tspan, and textPath), text content block element (text), and text content child element (tspan and textPath). I'm using the SVG 1.1 spec as reference for how properties were originally spec'd to apply to the SVG elements.

But, it seems we have some inconsistencies between what the spec said and what browsers did. Also, dominant-baseline and alignment-baseline have been changed so much compared to the SVG 1 spec already that it isn't entirely relevant.

• baseline-shift: SVG 1 says child elements only, but Chromium (and probably WebKit???) supports it on text and Firefox doesn't support at all.

• alignment-baseline is defined to align the current element relative to it's parent so it should logically only apply to child elements, and that's how it was defined in SVG 1. But again, Chromium supports it on text to change the alignment relative to the SVG text anchor point, and Firefox doesn't support it at all.

• dominant-baseline everyone (SVG 1, Chromium, Firefox) agrees applies to all text content elements.

CodePen tests

So, I'm spec'ing all three to apply to all text content elements unless there is a strong objection and/or my guess is wrong about WebKit and Chromium matching here. There's no reason not to let baseline-shift and alignment-baseline apply to SVG <text> since there is still a clear reference point to measure alignment against.

[AmeliaBR]

inline-sizing to text elements (at-risk for SVG 2)

The inline-sizing property in CSS inline is different from the inline-size property in SVG 2, which was defined as an extension of the inline-size property in CSS Logical Sizing.

Now that CSS Logical Sizing is stable, should probably edit the SVG spec to reference it, but as for CSS Inline and the inline-sizing property, that's just an unfortunate name (any chance to still change it?)

[AmeliaBR]

line-height to text content elements (SVG2 actually misses to specify it)

The SVG 2 prose is:

SVG uses the line-height property to determine the amount of leading space which is added between lines in multi-line text (both for horizontal and vertical text). It is not applicable to text on a path.

Firefox is the only browser that has implemented line-height in SVG text content (for pre-formatted line breaks), and they support it on <textPath>, which seems logical enough for me. Probably should be an issue on the SVG spec.

[AmeliaBR]

See #5149 for edits

[fantasai]

@AmeliaBR Yeah, file an issue on the naming if you have a better alternative. :) I don't like it much either. As long as the TTML folks don't have an objection, we can rename.

Wrt applying baseline-shift and alignment-baseline to text elements, sounds good to me. Merged your changes.

[AmeliaBR]

as for CSS Inline and the inline-sizing property, that's just an unfortunate name (any chance to still change it?)

file an issue on the naming if you have a better alternative

Done in #5189