-
Notifications
You must be signed in to change notification settings - Fork 679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-text-3] #10066 Describe ink overflow from hanging glyphs #9842
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Aha. Just figured this was related to #8649 will look into that. |
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. |
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.
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:
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.
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. |
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.
This is based on conversations with @kojiishi and @drott.
This is perhaps an argument in favor of web fonts.
I'm not sure that's true, based on my conversations with @kojiishi and @drott.
This PR gives an example of glyph overhang from an italicized 'f':
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.
I opened #10066 to discuss. |
No description provided.