Intent to Ship: Auto-expand details elements

[Joey Arhar]

Contact emails

jar...@chromium.org

Explainer

https://github.com/WICG/display-locking/blob/main/explainers/auto-expanding-details-explainer.md

Specification

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

Design docs

https://github.com/WICG/display-locking/blob/main/privacy-assessments/auto-expanding-details-privacy.md

Summary

This feature will make closed details elements searchable and automatically expand when the browser tries to scroll to their hidden contents in response to find-in-page, ScrollToTextFragment, and element fragment navigation.

Blink component

Blink>HTML

TAG review

https://github.com/w3ctag/design-reviews/issues/677

TAG review status

Pending

Risks

Interoperability and Compatibility

If other browsers don't implement this feature for element fragments, it may be an observable difference to webpages, but this portion is the least contentious and complicated part of this feature, so other browsers are most likely to at least implement this for element fragments. If other browsers don't implement this feature for find-in-page or ScrollToTextFragment, it won't cause any websites to break because webpages can't observe the difference.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/578)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-September/031983.html)

Web developers: No signals
- Here is a user reported bug requesting this feature: https://bugs.chromium.org/p/chromium/issues/detail?id=1058732
- Here is an article I found describing the lack of element fragment navigation: https://www.sitepoint.com/fixing-the-details-element/#:~:text=the%20target%20element%20is%20inside%20a%20collapsed%20region

Debuggability

This feature does not have any added DevTools support. This feature does not add any state to the page that would need to be inspected with DevTools. Find-in-page, ScrollToTextFragment, and element fragment navigation do not provide any DevTools debugging that this feature could build on or leverage.

Is this feature fully tested by web-platform-tests?

No
- Auto-expanding details with element fragment navigation is tested here: https://wpt.fyi/results/html/semantics/interactive-elements/the-details-element/auto-expand-details-element-fragment.html
- I still need to add ScrollToTextFragment tests. ScrollToTextFragment tests do exist in WPT.
- Find-in-page can't be tested in WPT, but I may spec window.find and support it for this feature in the future just to make this WPT testable.

Flag name

--enable-blink-features=AutoExpandDetailsElement

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Estimated milestones

M96

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5032469667512320

This intent message was generated by Chrome Platform Status.

[Thomas Steiner]

On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar <jar...@chromium.org> wrote:

Contact emails

jar...@chromium.org

Explainer

https://github.com/WICG/display-locking/blob/main/explainers/auto-expanding-details-explainer.md

Specification

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

Design docs

https://github.com/WICG/display-locking/blob/main/privacy-assessments/auto-expanding-details-privacy.md

Summary

This feature will make closed details elements searchable and automatically expand when the browser tries to scroll to their hidden contents in response to find-in-page, ScrollToTextFragment, and element fragment navigation.

Blink component

Blink>HTML

TAG review

https://github.com/w3ctag/design-reviews/issues/677

TAG review status

Pending

Risks

Interoperability and Compatibility

If other browsers don't implement this feature for element fragments, it may be an observable difference to webpages, but this portion is the least contentious and complicated part of this feature, so other browsers are most likely to at least implement this for element fragments. If other browsers don't implement this feature for find-in-page or ScrollToTextFragment, it won't cause any websites to break because webpages can't observe the difference.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/578)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-September/031983.html)

Web developers: No signals

I think it's fair to say "positive", given the like and retweet signals on https://twitter.com/tomayac/status/1403119516922662913 and https://twitter.com/tomayac/status/1293696281370669057 where this behavior is described. 

 

- Here is a user reported bug requesting this feature: https://bugs.chromium.org/p/chromium/issues/detail?id=1058732
- Here is an article I found describing the lack of element fragment navigation: https://www.sitepoint.com/fixing-the-details-element/#:~:text=the%20target%20element%20is%20inside%20a%20collapsed%20region

Debuggability

This feature does not have any added DevTools support. This feature does not add any state to the page that would need to be inspected with DevTools. Find-in-page, ScrollToTextFragment, and element fragment navigation do not provide any DevTools debugging that this feature could build on or leverage.

Is this feature fully tested by web-platform-tests?

No
- Auto-expanding details with element fragment navigation is tested here: https://wpt.fyi/results/html/semantics/interactive-elements/the-details-element/auto-expand-details-element-fragment.html
- I still need to add ScrollToTextFragment tests. ScrollToTextFragment tests do exist in WPT.
- Find-in-page can't be tested in WPT, but I may spec window.find and support it for this feature in the future just to make this WPT testable.

Flag name

--enable-blink-features=AutoExpandDetailsElement

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Estimated milestones

M96

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5032469667512320

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/CAK6btwJKmGKbjhWCdqrVO-Dm5LMmuROQ9M7N4UADjNvnTUaDAg%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
-----END PGP SIGNATURE-----

[Yoav Weiss]

On Fri, Sep 17, 2021 at 8:41 AM 'Thomas Steiner' via blink-dev <blin...@chromium.org> wrote:

On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar <jar...@chromium.org> wrote:

Contact emails

jar...@chromium.org

Explainer

https://github.com/WICG/display-locking/blob/main/explainers/auto-expanding-details-explainer.md

Do I understand correctly and developers don't need to do anything for their users to benefit from this? (and just need not to break their content when many toggle events are fired)

 

Specification

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

Design docs

https://github.com/WICG/display-locking/blob/main/privacy-assessments/auto-expanding-details-privacy.md

Summary

This feature will make closed details elements searchable and automatically expand when the browser tries to scroll to their hidden contents in response to find-in-page, ScrollToTextFragment, and element fragment navigation.

Blink component

Blink>HTML

TAG review

https://github.com/w3ctag/design-reviews/issues/677

TAG review status

Pending

Risks

Interoperability and Compatibility

If other browsers don't implement this feature for element fragments, it may be an observable difference to webpages, but this portion is the least contentious and complicated part of this feature, so other browsers are most likely to at least implement this for element fragments. If other browsers don't implement this feature for find-in-page or ScrollToTextFragment, it won't cause any websites to break because webpages can't observe the difference.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/578)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-September/031983.html)

Web developers: No signals

I think it's fair to say "positive", given the like and retweet signals on https://twitter.com/tomayac/status/1403119516922662913 and https://twitter.com/tomayac/status/1293696281370669057 where this behavior is described. 

 

- Here is a user reported bug requesting this feature: https://bugs.chromium.org/p/chromium/issues/detail?id=1058732
- Here is an article I found describing the lack of element fragment navigation: https://www.sitepoint.com/fixing-the-details-element/#:~:text=the%20target%20element%20is%20inside%20a%20collapsed%20region

I think I'd describe all these put together as "slightly positive".

At the same time, if I'm assuming correctly and developer opt-in is not required, then luke-warm developer reception and happy users sounds like a win.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLnkya4wkC7r-tWBcWoOkoJnGof%3DLt_reiM6AyKtm-BNDQ%40mail.gmail.com.

[Joey Arhar]

> I think it's fair to say "positive", given the like and retweet signals on https://twitter.com/tomayac/status/1403119516922662913 and https://twitter.com/tomayac/status/1293696281370669057 where this behavior is described.

Thanks Thomas!

> Do I understand correctly and developers don't need to do anything for their users to benefit from this? (and just need not to break their content when many toggle events are fired)

That's correct! Details elements will be opened and toggle events will be fired when the browser actually scrolls to the content inside a closed details element.

> I think I'd describe all these put together as "slightly positive".

> At the same time, if I'm assuming correctly and developer opt-in is not required, then luke-warm developer reception and happy users sounds like a win.

Great! I agree.

You are assuming correctly that developer opt-in is not required.

[PhistucK]

Will there be an opt out (without resorting to using other elements)?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BDmDf3s95mS%2Ba2kQKFCKA4DXhcL59%3Dm8ZmO6tskjQG%3Dg%40mail.gmail.com.

[Joey Arhar]

> Will there be an opt out (without resorting to using other elements)?

No, there is no plan to add an opt-out for this feature.

[PhistucK]

I imagine it could break a little some pages that hide the answer to a question (in a quiz type of thing) via this element...

☆PhistucK

[Joey Arhar]

> I imagine it could break a little some pages that hide the answer to a question (in a quiz type of thing) via this element...

If a site doesn't like this behavior, they could just not use the details element, right? There are plenty of other ways to implement an accordion like this.

I think it's more important for the user to be able to find content in the page than it is for the page to hide content from the user by default, right?

[PhistucK]

Not sure I completely agree, so, not so "right". :)

Using <summary>/<details> for "accordions" is kind of the prescribed way to do this. I do not think encouraging other, maybe less accessible, semantic or simple ways is so "right".

And this is breaking/changing an existing behaviour. You would not say this ("they could just not use the details element, right?") so casually about other platform changes, I think.

This is why I think a way to opt-out is fair.

I would not say this is a huge use case or that it must block shipping this, but it is worth a thoughtful consideration, anyway.

☆PhistucK

[Thomas Steiner]

Not sure this was discussed before, but could a new boolean attribute that opts the element in to the new behavior be the answer?

<details searchable><!-- … --></details>

[Yoav Weiss]

On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner <to...@google.com> wrote:

Not sure this was discussed before, but could a new boolean attribute that opts the element in to the new behavior be the answer?

<details searchable><!-- … --></details>

It seems like an opt-in would significantly diminish the user value of this feature, for all existing content. 

[Yoav Weiss]

LGTM1

On Thu, Sep 23, 2021 at 12:03 AM PhistucK <phis...@gmail.com> wrote:

Not sure I completely agree, so, not so "right". :)

Using <summary>/<details> for "accordions" is kind of the prescribed way to do this. I do not think encouraging other, maybe less accessible, semantic or simple ways is so "right".

And this is breaking/changing an existing behaviour. You would not say this ("they could just not use the details element, right?") so casually about other platform changes, I think.

This is why I think a way to opt-out is fair.

I'm sympathetic to the semantic element argument. I suspect that the need for such an opt-out is not huge (as it seems fairly niche for content to want to be hidden), so I wouldn't consider this a blocker, but it seems worthwhile to keep close tabs of the developer ecosystem and see if such a need arises.

If it does, adding an opt-out seems worthwhile.

[Mike Taylor]

On 9/23/21 8:19 AM, Yoav Weiss wrote:

On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner <to...@google.com> wrote:

Not sure this was discussed before, but could a new boolean attribute that opts the element in to the new behavior be the answer?

<details searchable><!-- … --></details>

At the risk of jinxing UseCounter metrics, another option would be to spec the `search` event such that `preventDefault()` provides an opt-out here.

[Balazs Engedy]

For the `beforeMatch` event we requested that if the website does not reveal `hidden-matchable` content in response to this event, sending the event be stopped for the reminder of the lifetime of the page. This was to prevent adding new ways of snooping on what the user types in the find-in-page box without any user-visible feedback; and in anticipation of a future world where the preexisting vectors of snooping have been mitigated.

However, back then, we were unsure if there exists a robust solution to verify that content actually got revealed in response to `beforeMatch`. There was some discussion about this on the TAG review thread, but I am not sure if we ended up finding a good approach. Do you think there is a viable technical enforcement here, for the <details> element?

[Joey Arhar]

> in anticipation of a future world where the preexisting vectors of snooping have been mitigated

I am planning on adding a delay to find-in-page in order to mitigate find-in-page snooping which would work with this feature, beforematch, and the existing scroll events: https://bugs.chromium.org/p/chromium/issues/detail?id=1250158

I am hoping that this mitigation, when complete, will make it harder or impossible to recreate what the user typed into the find-in-page dialog regardless of the attack vector and I believe it will be much more robust than the beforematch mitigations I proposed.

> For the `beforeMatch` event we requested that if the website does not reveal `hidden-matchable` content in response to this event, sending the event be stopped for the reminder of the lifetime of the page. This was to prevent adding new ways of snooping on what the user types in the find-in-page box without any user-visible feedback

> However, back then, we were unsure if there exists a robust solution to verify that content actually got revealed in response to `beforeMatch`. There was some discussion about this on the TAG review thread, but I am not sure if we ended up finding a good approach. Do you think there is a viable technical enforcement here, for the <details> element?

This feature is different from beforematch in a couple ways:

1. We aren't adding a new signal to the page like the beforematch event.

2. The existing toggle event which would be fired upon expanding the details element is fired asynchronously, so it wouldn't be able to close the details element again and undo the scroll "without any user-visible feedback" as you mentioned.

Technically, the page could also listen to deprecated mutation events to be notified when the open attribute is added to the details element, but this still happens at the same time that the existing problematic scroll events are fired: synchronously.

Since I don't see the open attribute or the toggle event as being worse than the existing scroll event, I don't believe we need a mitigation like we discussed for beforematch.

[Balazs Engedy]

Thank you for the detailed differential threat analysis, SGTM from the permissions side. Glad to see the ongoing work on robust and comprehensive mitigations.

[Mike West]

LGTM2.

Please do follow up on any feedback you obtain from the TAG, since I believe the review request there is still outstanding. It doesn't appear to me that there are substantial design questions that are still open, but if something interesting is raised, we should respond to it expediently.

In particular, if we do end up deciding that we need an opt-out, it should be straightforward to ship on top of this feature.

-mike

--

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/cc3efcbb-85a8-4689-a892-100b81e4ee70n%40chromium.org.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Ddta1BOirR73vuy61808GHRYUXT4n95CFA6j9jdg0WBSw%40mail.gmail.com.

[Daniel Bratell]

Though I notice that there were some good comments about documentation in the TAG thread and that documentation should be added before this reaches stable (the sooner the better).

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c66847c5-80bd-1ebb-7e86-b1f61467507c%40gmail.com.

[Joey Arhar]

> Though I notice that there were some good comments about documentation in the TAG thread and that documentation should be added before this reaches stable (the sooner the better).

As per the TAG thread, I have opened a PR to add a non-normative note about this to the HTML spec: https://github.com/whatwg/html/pull/7229