LGTM2 On Sun, Oct 6, 2024 at 9:31 PM Domenic Denicola <dome...@chromium.org> wrote:
> LGTM1. > > This seems like a great, well-thought-out, and widely-reviewed improvement > to the status quo. I appreciate the detailed compat notes, and the > mitigations taken so far (testing in Canary and Dev). A use counter would > have been ideal, but I don't think we should hold this up waiting for that, > especially since you have a Finch feature so if this somehow causes > terrible regressions, we can flip it back. (I agree with your assumption > that using `display: contents` on details is likely rare.) > > On Fri, Oct 4, 2024 at 11:54 PM David Baron <dba...@chromium.org> wrote: > >> Contact emailsdba...@chromium.org >> >> Explainerhttps://github.com/dbaron/details-styling >> https://dbaron.github.io/details-styling/phase-1 >> >> Specification >> https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements >> >> Summary >> >> Support more CSS styling for the structure of <details> and <summary> >> elements to allow these elements to be used in more cases where disclosure >> widgets or accordion widgets are built on the web. In particular, this >> change removes restrictions that prevented setting the display property on >> these elements, and adds a ::details-content pseudo-element to style the >> container for the part that expands and collapses. >> >> >> Blink componentBlink>HTML>Details >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3EDetails> >> >> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/965 >> >> TAG review statusIssues addressed >> >> Risks >> >> >> Interoperability and Compatibility >> >> There's some interoperability and compatibility risk around changes to >> <details> styling. Currently styling of the list marker is not >> interoperable as there are two different approaches, one taken by Gecko and >> (current) Chromium, and another taken by WebKit (which was previously >> shared with Chromium). However, this initial phase of work doesn't address >> marker styling very much. In most cases, the changes being proposed here >> are compatible with existing content. However, they do include one breaking >> change, in that they make the <slot> matched by the ::details-content >> pseudo-element be display:block by default rather than being display:block >> when closed and display:contents when open. This could potentially break >> content that is currently using display:contents on the details element, >> although such content is likely rare, and could be easily fixed by >> explicitly setting the old style (details[open]::details-content { display: >> contents }). This change is included because it significantly improves the >> developer ergonomics of using ::details-content; however, if it turns out >> to cause compatibility issues then it could be rolled back (at the cost of >> developer ergonomics for users of ::details-content, some of which who >> would need to explicitly specify display to override the display:contents >> default). For more details, see https://crrev.com/c/5594192 . >> >> >> In order to get additional testing to uncover problems, this feature was >> enabled for 50% of canary and dev channels from early July until mid >> September. During that time no issues were reported (or at least none that >> found their way to me). >> >> >> *Gecko*: Positive ( >> https://github.com/mozilla/standards-positions/issues/1027) >> >> *WebKit*: Support ( >> https://github.com/WebKit/standards-positions/issues/351) >> >> *Web developers*: No signals >> >> *Other signals*: >> >> 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? >> >> see above regarding Compatibility risks >> >> >> Debuggability >> >> https://issues.chromium.org/40280502 describes one small-ish issue with >> the way devtools shows the resulting CSS cascade. >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, 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 >> >> >> https://wpt.fyi/results/html/rendering/the-details-element/details-display-type-001.html >> https://wpt.fyi/results/html/rendering/the-details-element/details-display-type-002.html >> https://wpt.fyi/results/html/rendering/the-details-element/details-display-type-001-ref.html >> https://wpt.fyi/results/html/rendering/the-details-element/details-display.html >> https://wpt.fyi/results/html/rendering/the-details-element/details-pseudo-elements-001.html >> https://wpt.fyi/results/html/rendering/the-details-element/details-pseudo-elements-002.html >> https://wpt.fyi/results/html/rendering/the-details-element/details-pseudo-elements-003.html >> >> >> Flag name on chrome://flagsNone >> >> Finch feature nameDetailsStyling >> >> Requires code in //chrome?False >> >> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1469418 >> >> Availability expectationMy hope is that this will be implemented >> reasonably soon in other engines. It seems reasonably likely that this will >> happen (in so far as we can predict such things for features where Chrome >> is the first implementation). >> >> Estimated milestones >> Shipping on desktop 131 >> DevTrial on desktop 119 >> Shipping on Android 131 >> DevTrial on Android 119 >> Shipping on WebView 131 >> >> 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/5112013093339136?gate=6299990444212224 >> >> Links to previous Intent discussionsIntent to Prototype: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/Q1OX6ZA_aaE/m/ALwkAOfHAwAJ >> >> >> 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 blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3hQtLqCeUfV7u%2BzVE2KxrAXrGeYJjMHb6MmngpQr5awUQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3hQtLqCeUfV7u%2BzVE2KxrAXrGeYJjMHb6MmngpQr5awUQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_0%3Dm1LMJ%3D%3Dp3P7-8hPEqp4QXE6cAaPRQ9B1yLjGh6TTg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_0%3Dm1LMJ%3D%3Dp3P7-8hPEqp4QXE6cAaPRQ9B1yLjGh6TTg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8vDbF%3DbhKmvNdk90p9Sf2vWxA_pGbZkLi9MGv5tO%3D40Q%40mail.gmail.com.
