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.
