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.
