Re: [csswg-drafts] [css-text-3] #8649 Describe ink overflow from hanging glyphs (#9842)

> The immediate motivation for describing the extent of ink overflow is to enable IntersectionObserver V2

I don't think this PR does anything about that though. This PR is authoring advice, not defining the extent of ink overflow from an implementation point of view, so it should be a separate issue.

> The text in this PR provides a way for authors to account for ink overflow and avoid surprises.

I don't think the advice provided by this PR is entirely accurate though, and some of the claims it makes lack evidence (might be true, but not obviously so). For instance:

> Because [=hanging glyphs=] are considered [=ink overflow=], and hence are not included in [=inline box=] geometry, there is no straightforward way to measure their extent

This doesn't follow from that. Being defined as ink overflow does not make it easier or harder for the UA to measure there extent. There are things that are included within the definition of ink overflow for which determining the extent is hard (as the extend may theoretically be infinite), but this doesn't seem to be one of them, and anyway, which type of overflow it gets included in makes no difference to that problem.

Or maybe you meant not easy for an author to measure the extent? Not sure that's true either. modulo the subtleties of sub-pixel rendering, glyphs have sharp edges. They're not like blurs or gradients, where there can considerable uncertainty as to where they end. As you point out in a subsequent paragraph, authors can visually measure the extent of the overflow. Sure, they cannot simply auto-size a box to contain the ink-overflow, and ask an API for the size of that box, but doesn't mean the answer to the question is elusive. 

> However, any two conforming browser implementations, when rendering a given piece of text content using a given font in a supported format […] will produce identically-sized [=ink overflow rectangles=], within a 2-pixel margin of error.

* [citation needed] :)
* even if it is true, authors cannot generally rely on the same font being used, so there can be more than 2px of difference
* user styles or zoom can affect the font size, so there can be more than 2px of difference
* at the moment, hanging glyphs are limited to
    * spaces, which do not need extra space to be displayed
    * punctuation, with hanging rules that are suited to CJK typography. These do need extra space. The latin punctuation marks are the smaller of the bunch, so we don't need to worry about them if we handle the rest well. For the relevant CJK punctuation marks, the ink is effectively never larger than 0.5em, placed within a 1em square. For Japanese, Korean, and mainland Chinese, these are left aligned within the square†, so 0.5em of extra padding will comfortably accommodate hanging punctuation, and in practice you could get away with a little less, like 0.4em, for a tight fit. For traditional Chinese, they are centered, so 0.75em will comfortably fit them, and in practice you could get away with a little less, like 0.65em, for a tight fit.

    † U+FE50, U+FE51, and U+FE52 are centered regardless of the language, but these characters are for compatibility with the Chinese National Standard CNS 11643, so not relevant for Japanese or Korean, and I don't believe they're in common use for Chinese either.

So, I think advice that  would be more robust would be to give 0.5em of padding for Japanese, Korean, and mainland Chinese, or 0.75em for traditional Chinese, or 0.1em less for a tight fit. As these are in em and not px, this will be robust to font size or zoom changes, and it'll work for pretty much any font out there. Yes, you might be able to shave a few more pixels with specific knowledge of the font, but that's a matter of fine tuning, not of general advice.

But that's just my take.

Whether we should add advice at all to the spec, and what that advice should be, is something that should be discussed as a separate issue from #8649, and get WG consensus before we dive into a specific pull request.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9842#issuecomment-1963246696 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 26 February 2024 03:17:23 UTC