Please send this as an FYI to the TAG. The fact of something being agreed in the CSS WG does not say much for platform consistency and quality.
Given that I grok this and think it's reasonable (with my ex-TAG member hat on), I'll give y'all a pass on a full review, but please file in future. LGTM1, contingent on sending an FYI to the TAG. On Thursday, July 13, 2023 at 12:16:00 PM UTC-7 Vladimir Levin wrote: > Contact [email protected] > > Specification > https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override > > Summary > > This feature is a result of a CSSWG resolution: > https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558 > content-visibility: auto is a property that can be used to optimize > rendering of off-screen content. However, when rendering is optimized it > also means that the size of the element cannot be determined using the > descendant information. This is done with size containment. As a result, > contain-intrinsic-size was added to help with this. When > content-visibility: auto skips contents, contain-intrinsic-size determines > its size (roughly as if it had a single child of specified size). > contain-intrinsic-size also has an option to add an "auto" keyword which > means "if the element has been previously rendered, then use that size; if > not, use the specified size". This helps with layout stability by ensuring > that elements that come into the viewport and then leave remain the same > size as before. This feature tracks forcing contain-intrinsic-size: auto if > content-visibility's value is auto. > > > Blink componentBlink>Paint > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPaint> > > TAG reviewNone > > TAG review statusNot applicable > > Risks > > > Interoperability and Compatibility > > There is a risk of interoperability here, since this changes the behavior > of content-visibility: auto and contain-intrinsic-size interaction. > Specifically, this forces the layout size of content-visibility: auto > elements to be different after it becomes relevant to the user, even when > the element starts skipping contents once again. Note that the developer > does not have to specify contain-intrinsic-size values, since the default > value of "none" can also gain the "auto" keyword. Although this risk > exists, I believe the change is for the better, since the ability to size > things appropriately under content-visibility has been a challenging piece > of content-visibility adoption. Out of httparchive sites that use > contain-intrinsic-size, roughly half already use "auto" variety. > > > *Gecko*: Shipped/Shipping ( > https://hg.mozilla.org/mozilla-central/rev/af2192d1c537) > > *WebKit*: No signal ( > https://github.com/WebKit/standards-positions/issues/228) > > *Web developers*: No signals ( > https://github.com/WebKit/standards-positions/issues/228) > > *Other signals*: > > Ergonomics > > This feature makes adoption of content-visibility: auto more > straightforward, since off-screen element sizing becomes easier to deal > with. > > > Activation > > There are no activation risks. > > > Security > > There are no security risks with this feature, since it deals with CSS and > Layout sizing. > > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > None > > > Debuggability > > This feature uses CSS and is debuggable as any other CSS feature would be. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)?Yes > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?Yes > > Flag name on chrome://flags > > Finch feature nameCSSContentVisibilityImpliesContainIntrinsicSizeAuto > > Requires code in //chrome?False > > Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1418453 > > Estimated milestones > Shipping on desktop 117 > Shipping on Android 117 > Shipping on WebView 117 > > Anticipated spec changes > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > None > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5111301323358208 > > Links to previous Intent discussions > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/35983500-d811-476e-aa4a-d726c6308ac8n%40chromium.org.
