Re: [csswg-drafts] [css-overflow-3] Specify extent of ink overflow (#8649)

@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 UA cannot absolutely guarantee that not a single pixel gets shaded by other content. It is prohibitively expensive to determine occlusion precisely; that's why "maximum possible extent" is an useful concept. We can analyze the maximum possible extent of all ink overflow on a page and conservatively mark content as "possibly occluded" whenever there is any overlap whatsoever.

We have done some monitoring and analysis of IntersectionObserver V2 as deployed on partner sites, and have concluded that this conservative approach based on maximum possible extent of ink overflow works well in practice. There is a very low incidence of embedders inadvertently causing V2 to report content as "possibly occluded." So we have confidence in this approach. However, other browsers have rightly pointed out that the lack of specificity in the HTML spec around the extent of ink overflow makes it hard to guarantee interoperability of this feature.

Blur radius is the quintessential example of a feature that runs exactly counter to the "maximum possible extent" approach, but fortunately all the major browser implementations are de facto interoperable because they all use the same math to determine the extent of a blur effect. The [change](https://github.com/w3c/fxtf-drafts/pull/544) I landed to the fxtf spec was simply to non-conformingly codify and document that.

Text and text decorations are the only sources of ink overflow for which there isn't a completely satisfying answer to the "maximum possible extent" question. However, in conversation with @drott and @kojiishi, I landed on the language in #9842. The tl;dr is: "for a given well-defined font and text input, across browser implementations, the maximum possible extent of ink overflow from hanging glyphs is no more that a 2px outset from the painted area determined by visual inspection in any conforming browser." Or, even more succinctly: "look at your content in any browser, and make sure there's a 2px gap between any painted text and any element you want to avoid occluding."

Text decorations are even harder than text in this regard: the extent of ink overflow is a combined product of the font rendering system *and* the browser implementation. #10085 is, I admit, not wholly satisfying, but it is the best guidance I could come up with for authors trying to reason about the maximum possible extent of ink overflow.

-- 
GitHub Notification of comment by szager-chromium
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8649#issuecomment-2010410926 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 20 March 2024 19:11:04 UTC