szager-chromium

Hmm... this seems to be caused by running inside `screen`.

I have wrestled quite a bit with adding those spans and getting bikeshed to do the right thing; some constructs work, others don't. Here's an example spec produced with this...

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

@drott I presume all browsers must already compute glyph overhang extent, for the purpose of determining the size of composited layers, no? If I'm not mistaken, [here](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/ng/ng_ink_overflow.cc;drc=7fa0c25da15ae39bbd2fd720832ec4df4fee705a;l=450) is where chromium...

I'm hoping the CSSWG can resolve on whether to land these PR's, which relate to this issue and also #10066: https://github.com/w3c/csswg-drafts/pull/9823 https://github.com/w3c/csswg-drafts/pull/9842 https://github.com/w3c/csswg-drafts/pull/10085

@fantasai I refer to the issue links in the first comment, and to my comments below it. I'm not very familiar with view transitions so I don't have much to...

@fantasai At least in the case of IntersectionObserver V2, which is security-focused, we always want to err on the side of caution and report content as "possibly occluded" whenever the...

@jfkthame Those are legitimate concerns with respect to IntersectionObserver V2. If UA settings or accessibility features cause an element of interest to be occluded, then the correct behavior is for...

@noamr For the view transition case, similar to IntersectionObserver, it appears that "maximum possible extent of ink overflow" is a useful concept.

@fantasai @jfkthame Can I ask you to respond to my most recent comments? There is a genuine need here -- View Transitions is a [CR](https://drafts.csswg.org/css-view-transitions/), and IntersectionObserver V2 is used...