- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 May 2024 16:29:18 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow-3] Specify extent of ink overflow`, and agreed to the following: * `RESOLVED: Close the issue, adding a note to the ink overflow definition about platform and rendering differences` <details><summary>The full IRC log of that discussion</summary> <emilio> szager: trying to summarize the discussion<br> <emilio> ... IntersectionObserver v2 uses ink overflow rects to determine visibility<br> <emilio> ... view transitions use it too<br> <emilio> ... it was brought up to me that ink overflow is a bit under-specified<br> <emilio> ... which can cause interop issues<br> <emilio> ... my personal agenda was to enable IOv2<br> <emilio> ... for everything except text, the extent of ink overflow is pretty straight-forward<br> <emilio> ... a couple places didn't call out it in the spec<br> <emilio> ... so I wrote a few PR<br> <florian> q+ to speak (once szager is done)<br> <emilio> ... but text is the really different one<br> <emilio> ... when laying out text we're subject to font selection / glyph shaping, web devs understand that different platforms give different results<br> <emilio> ... you can access the layout geometry via APIs and getBoundingClientRect()<br> <emilio> ... on inlines etc<br> <emilio> ... ink overflow is different, it's magic and not observable<br> <emilio> ... I wonder if we can help developers get a hand on this<br> <emilio> ... given we now have APIs which kind of expose ink overflow extents directly, it seems weird not to expose them<br> <astearns> ack florian<br> <Zakim> florian, you wanted to speak (once szager is done)<br> <chrishtr> q+<br> <emilio> ... I know that some of my PRs are not up to the standard in the spec. I'm not super-engaged on getting them landed but I think we should do the best possible for developers<br> <emilio> florian: you submitted 3 prs, for text, text-decoration, and for backgrounds<br> <emilio> ... it seems you want (1) define ink overflow better<br> <emilio> ... which seems useful<br> <khush> q+<br> <emilio> ... I haven't reviewed all the PRs, but the text PR isn't about defining it<br> <emilio> ... it's author guidance about how to reason about it<br> <emilio> ... so that's less obvious to me that it belongs in the spec<br> <emilio> ... you made some arguments which I didn't understand before<br> <emilio> ... but this looks more like devrel etc<br> <emilio> ... if there's agreement that this should be in the spec then we should work more of it<br> <astearns> ack chrishtr<br> <emilio> ... but as is the PR is not definition of ink overflow, more like author guidance<br> <emilio> chrishtr: just to bring it back to what I think should be the main resolution<br> <emilio> ... is ink overflow well-specified enough for those use cases?<br> <emilio> florian: not sure that's relevant because the PRs doesn't define anything<br> <emilio> chrishtr: I agree with it being more dev guidance<br> <emilio> chrishtr: if it's well defined let's close the issue and we can put developer guidance elsewhere<br> <fantasai> scribe+<br> <fantasai> emilio: I think the differences in text ink overflow are unlikely to cause substantial web compat problems for the APIs we're exposing right now<br> <fantasai> emilio: I don't think defining ink overflow for text is a blocker for the occlusion stuff<br> <fantasai> emilio: nor for View Transitions<br> <fantasai> emilio: The differences are relatively minor, and also happen even within the same browser across different platforms.<br> <fantasai> emilio: If you only test Chrome on Windows, Chrome on Mac is different<br> <fantasai> emilio: I don't think the ink overflow extents for text are likely to break use cases for intersectionObserver v2<br> <fantasai> emilio: same for View Transitions<br> <fantasai> emilio: I don't think it can cause realistic compat issues<br> <fantasai> emilio: Not necessarily well defined<br> <fantasai> emilio: but it doesn't matter much<br> <fantasai> emilio: One thing Stephen was asking was about exposing the ink overflow rects more<br> <fantasai> emilio: I think authors should generally not care about ink overflow<br> <fantasai> emilio: devtools could point out if needed<br> <fantasai> chrishtr: Sounds like you think we could close the issue as "good enough"<br> <florian> q+<br> <fantasai> emilio: Depends on the goal of the issue<br> <fantasai> chrishtr: for existing use cases that need it<br> <fantasai> emilio: text ink overflow maybe needs better definition<br> <fantasai> chrishtr: open a new issue, add some examples<br> <emilio> scribe+<br> <astearns> ack khush<br> <fantasai> khush: We're using this definition in one spot for VT<br> <fantasai> khush: but not Web-observable<br> <emilio> khush: want to clarify that v-t we are using it at one spot but it hasn't been a compat issue because it's not observable at all<br> <emilio> khush: because the area is managed by the browser<br> <emilio> ... but we want to use it for a feature where visibility with the viewport is handled with ink overflow instead of border box<br> <emilio> ... that technically would expose it<br> <emilio> ... and you could measure it moving a div 1px at a time<br> <astearns> ack florian<br> <emilio> ... but for the use cases we want I think it's ok<br> <emilio> florian: no strong view on whether what we have is good enough<br> <emilio> ... for v-t or intersection-observer<br> <emilio> ... predictable for authors is one thing, easy to compute for browsers is another<br> <chrishtr> q?<br> <emilio> ... glyphs are not the kind of infinite thing you need to approximate<br> <emilio> ... it could be very expensive to compute where a glyph ends<br> <fantasai> Definition of ink overflow https://www.w3.org/TR/css-overflow-3/#ink<br> <emilio> ... it's where the text ends, which you can compute, even though it might not be easy<br> <emilio> ... so I don't think it's badly defined<br> <emilio> szager: All browsers need to compute it already<br> <astearns> ack fantasai<br> <emilio> [missed]<br> <emilio> fantasai: I was on the queue to say what florian said, I don't think text ink overflow is ambiguous<br> <emilio> ... if there's an actual ambiguity then we should fix the spec<br> <emilio> ... otherwise it's not ambiguous<br> <emilio> ... I don't think an API to expose it would be a good idea<br> <emilio> ... because of that issue<br> <emilio> q+<br> <emilio> astearns: I think what's currently in the spec is good enough for current use cases<br> <emilio> ... so propose to close unless spec is ambiguous<br> <fantasai> emilio: ambiguity is not so much the spec definition, but the fact that the same text in the same font may generate different ink overflow on different platforms due to shaping and rasterization<br> <fantasai> emilio: might be worth pointing out in the spec<br> <fantasai> emilio: so that people defining APIs that depend on ink overflow can take that into account<br> <fantasai> emilio: doesn't have to be long, just a paragraph, that says it'll differ across platforms and rendering engines<br> <astearns> s/think what's/think what I’m hearing is that what’s/<br> <fantasai> emilio: for Khush's proposal about exposing more directly, file a different issue<br> <astearns> ack emilio<br> <fantasai> emilio: idk to what extent that can increase fingerprinting surface<br> <fantasai> emilio: That's a good reason why someone might measure a div pixel by pixel<br> <fantasai> emilio: not something you really want to expose, maybe it's exposed on canvas already<br> <fantasai> emilio: worth more thinking<br> <astearns> ack fantasai<br> <emilio> fantasai: If you want a note saying this can differ due to different factors then happy to do that<br> <emilio> chrishtr: sounds great, ty for volunteering<br> <emilio> RESOLVED: Close the issue, adding a note to the ink overflow definition about platform and rendering differences<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8649#issuecomment-2125236006 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 May 2024 16:29:19 UTC