[css-text-3] #10066 Describe ink overflow from hanging glyphs

[szager-chromium]

No description provided.

[frivoal]

I don't know what problem you are trying to address. As discussed in https://github.com/w3c/csswg-drafts/blob/main/CONTRIBUTING.md, can you open an issue first to discuss what the problem is:

Please note that most issues are subject to quite a bit of discussion before they are ready for a pull request with specific wording changes. Please ensure the full problem space of the issue is explored in the discussion, and that consensus has been reached by the participants, before drafting a pull request.

[frivoal]

Aha. Just figured this was related to #8649 will look into that.

[frivoal]

Having looked at #8649, I'm still not sure how this relates to that. The issue is about defining the extent of ink overflow, while this PR seems to be about giving guidance to authors about how to deal with ink overflow caused by hanging glyphs. These seem to be two different things.

[szager-chromium]

Having looked at #8649, I'm still not sure how this relates to that. The issue is about defining the extent of ink overflow, while this PR seems to be about giving guidance to authors about how to deal with ink overflow caused by hanging glyphs. These seem to be two different things.

The immediate motivation for describing the extent of ink overflow is to enable IntersectionObserver V2 (occlusion detection) and View Transitions. The concern in both cases is that the API's may have surprising behaviors because authors cannot reason about the extent of ink overflow. The text in this PR provides a way for authors to account for ink overflow and avoid surprises.

[frivoal]

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

[szager-chromium]

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.

Would you be OK with rephrasing it as "no straightforward way for authors to programmatically measure their extent"? That is what I meant to convey.

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] :)

This is based on conversations with @kojiishi and @drott.

• even if it is true, authors cannot generally rely on the same font being used, so there can be more than 2px of difference

This is perhaps an argument in favor of web fonts.

• user styles or zoom can affect the font size, so there can be more than 2px of difference

I'm not sure that's true, based on my conversations with @kojiishi and @drott.

• at the moment, hanging glyphs are limited to...

This PR gives an example of glyph overhang from an italicized 'f':

  <div class="figure" style="margin:0; font-size:10rem; font-family:garamond; font-style:italic">
    <span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span><span style="vertical-align: top;">f</span><span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span>
  </div>

Regarding CJK typography: I would like to avoid including these kinds of specifics because it's impossible to create an authoritative list. I mean for the takeaway to be: text can result in ink overflow, the extent of which is not directly measurable via web platform API's; but there is a practical way to achieve de facto interoperability of ink overflow extents from text.

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.

I opened #10066 to discuss.