Intent to Ship: Accordion pattern using name attribute on <details> elements

[David Baron]

Contact emails

dba...@chromium.org

Explainer

https://open-ui.org/components/accordion.explainer

Specification

https://github.com/whatwg/html/pull/9400

Summary

This feature adds the ability to construct exclusive accordions using a sequence of HTML <details> elements. It adds a name attribute to the <details> element. When this attribute is used, multiple <details> elements that have the same name form a group. At most one element in the group can be open at once.

Blink component

Blink>HTML>Details

TAG review

https://github.com/w3ctag/design-reviews/issues/866 (design review)

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/831)

WebKit: In development (https://github.com/WebKit/standards-positions/issues/209) positive standards position and code landed (although a little behind the most recent changes to the proposal)

Web developers: No signals Got significant feedback from web developers in https://github.com/openui/open-ui/issues/812 . See examples of use on live sites in https://open-ui.org/components/accordion.explainer/#developer-demand-for-exclusive-accordion

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?

no

Debuggability

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?

Yes

Flag name on chrome://flags

Finch feature name

kAccordionPattern

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1444057

Availability expectation

Hoping to get cross-browser adoption relatively quickly (<12 months) given that it's a small feature that seems to be widely supported.

Adoption expectation

Wider adoption may depend on also doing other changes, like improved stylability of <details> and <summary> elements.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

no

Estimated milestones

Shipping on desktop

120

Shipping on Android

120

Shipping on WebView

120

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).

There may still be some small changes as part of the process of getting https://github.com/whatwg/html/pull/9400 finished, but I hope to implement those before shipping (at least those that happen soon).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6710427028815872

Links to previous Intent discussions

Intent 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.

[Yoav Weiss]

On Fri, Sep 29, 2023 at 11:04 PM David Baron <dba...@chromium.org> wrote:

Contact emails

dba...@chromium.org

Explainer

https://open-ui.org/components/accordion.explainer

Specification

https://github.com/whatwg/html/pull/9400

Summary

This feature adds the ability to construct exclusive accordions using a sequence of HTML <details> elements. It adds a name attribute to the <details> element. When this attribute is used, multiple <details> elements that have the same name form a group. At most one element in the group can be open at once.

This looks great!!

The only tiny concern I have is the question of compatibility: Is it possible that existing <details> elements share a name attribute?

Would it be possible for you to run a quick HTTPArchive scan and see this is not a semi-common pattern?

The PR is merged. Is there more work happening on it?

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6710427028815872

Links to previous Intent discussions

Intent 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.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3jdK2cMo8_hwyEFQLWUQ9W0xa60uy4wJnAMpZMdBApDfQ%40mail.gmail.com.

[David Baron]

On Wed, Oct 4, 2023 at 6:30 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Sep 29, 2023 at 11:04 PM David Baron <dba...@chromium.org> wrote:

Summary

This feature adds the ability to construct exclusive accordions using a sequence of HTML <details> elements. It adds a name attribute to the <details> element. When this attribute is used, multiple <details> elements that have the same name form a group. At most one element in the group can be open at once.

This looks great!!

The only tiny concern I have is the question of compatibility: Is it possible that existing <details> elements share a name attribute?

Would it be possible for you to run a quick HTTPArchive scan and see this is not a semi-common pattern?

I ran a query with HTTPArchive, in particular, the following query:

SELECT page, url

FROM `httparchive.all.requests`

WHERE

date = '2023-09-01' AND

client = 'desktop' AND

is_main_document AND

REGEXP_CONTAINS(response_body, r'(?is)<details[[:space:]][^>]*?[[:space:]]name(=|[[:space:]]|>)')

This produced 6 urls (for 7 pages; two of them redirect to the same URL).  I did view-source: of the 6 urls and based on visual inspection found that 0 of the 6 would be broken by shipping this feature.  In more detail:

• 3 of the 6 (associated with the same site, mailchimp.com) had multiple <details> elements, on each of which the name and id attributes had the same value, and these values were properly unique (at least among the <details> elements)
• 1 had a single <details> with name="somename"
• 1 had a single <details> with name="body" and id="body"; there were other elements with this name/id, but none of the others were <details>
• 1 had a single <details> element with a unique-ish looking name

So none of the pages found used the name attribute in a way that would be affected by shipping this feature (i.e., multiple <details> elements with the same name).

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).

There may still be some small changes as part of the process of getting https://github.com/whatwg/html/pull/9400 finished, but I hope to implement those before shipping (at least those that happen soon).

The PR is merged. Is there more work happening on it?

No.  I sent the intent before the PR was merged.  I do still need to follow up on a piece of the discussion there and file an issue on html-aam, though.

-David

[Yoav Weiss]

LGTM1

Thanks for the compat analysis! :)

[Daniel Bratell]

LGTM2

/Daniel

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/392c410e-acb3-4e55-bba1-d2d6612b4ba0n%40chromium.org.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/56206f57-a2df-4bc7-a510-aeb29ae4dc07%40gmail.com.