Re: [csswg-drafts] [css-text] letter-spacing should not apply to the end edge of a line/span? (#1518)

Personally, I've never been convinced that the current design/spec of letter-spacing as inserting space *between* typographic units is the right one, mostly because of the complications this introduces at boundaries. I think a much simpler model would be that letter-spacing increases (or decreases) the advance width of all typographic units equally on both sides, so that the glyph remains centered (typically) within its advance. Or in other words, half of the letter-spacing is applied to each of the left and right sidebearings of the glyph.

In particular, this works well for use-cases such as German-style  e m p h a s i s  where it's desirable for the letter-spacing to not only add some space *between* each letter of `<em>emphasis</em>` but also to adjust the inter-word spaces before and after it. With letter-space as currently spec'd, this could be done by adding margin-inline-start and -end (or with current implementations only adding it to the start), but with the alternative model we'd automatically get half the specified letter-spacing as an addition to the word spaces. This (IMO) would be much more convenient for authors.

For cases where (half) spacing at the inline-start and/or -end edge is *not* desired, it'd still be possible to suppress this by using a negative margin.

This also automatically works well at element boundaries within the line. And the symmetry means it's blind to bidi issues, unlike current behavior.

I think this would make for a simpler and more understandable model for both authors and implementers. But if -- as is quite likely -- changing the behavior of letter-spacing carries too much webcompat risk, perhaps we could introduce it as a separate property `tracking`, specified in terms of a simple, consistent effect on glyph sidebearings.

-- 
GitHub Notification of comment by jfkthame
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1518#issuecomment-665152564 using your GitHub account

Received on Tuesday, 28 July 2020 16:49:40 UTC