- From: szager-chromium via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Nov 2023 23:33:29 +0000
- To: public-css-archive@w3.org
> If it's possible, it would be better to find a way to solve these problems without needing to define the extent of ink overflow. The ink overflow extent isn't something that can be made necessarily interoperable (it depends on where you cut infinite blur etc, but also on what fonts are used, and possibly other effects). So pages that depend on it being a certain value could then break... I'd rather not expose it to the Web if we can avoid it. I'd like to press on this issue a bit if I may. There are now a couple of in-development specs that would like to rely on ink overflow extent, and it seems like a legitimately useful thing for any visually rich application environment. It isn't necessary, I think, to specify ink overflow down to the pixel; it would be enough to specify the maximum possible extent of any ink overflow, and by that measure many types of ink overflow are already de facto interoperable and specifiable. Glyph overhang is a notable exception, but perhaps there is a way to specify the *maximum* possible glyph overhang for a piece of text? If necessary, we could limit the spec language to the lowest-hanging fruit, i.e., types of ink overflow that are trivial to describe. But I'd like to see if we can do *something*. -- GitHub Notification of comment by szager-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8649#issuecomment-1793240633 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 November 2023 23:33:30 UTC