#677: Auto-expanding details elements

Visit on Github.

Opened Sep 16, 2021

Ya ya yawm TAG!

I'm requesting a TAG review of Auto-expanding details elements.

Summary: Today, closed details elements aren't searchable by find-in-page or ScrollToTextFragment, and if a user wants to search in them with find-in-page they would have to manually open every details element in the page before beginning their search. This feature makes closed details elements searchable and automatically expands them when the browser tries to scroll to content inside of them for find-in-page, ScrollToTextFragment, and element fragment navigation.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: none
  • The group where the work on this specification is currently being done: WICG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
  • Major unresolved issues with or opposition to this specification: none
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

Discussions

2021-10-11

Minutes

Lea: seems like a reasonable feature but there are accessibility considerations, there's a linked thread from mozilla standards position that talks about it

Dan: they don't say it's harmful. Not sure what Anne means about dashboard entry

Lea: looks like there are no a11y concerns, just discussion of implications, but nothing problematic. I don't see anything against it.

Dan: filled out security & privacy

Lea: already in html spec..

Dan: in the s&p questionnaire there is a find in page vulnerability.. there's a mitigation being implemented in chrome. Worth mentioning that we'd like to see what impact that has, or we support the proposed mitigation. Worth noting they've considered this. Is it documented anywhere? If it's an addition to the html spec it doesn't seem to be documented anywhere other than the explainer. Is there security and privacy considerations in html?

Lea: there are in individual parts of the html spec

Dan: [writes comment] Any other questions/comments?

Lea: do you think the question would block the review?

Dan: I don't think so, not blocking

Lea: if we post a comment saying it looks good and add proposed close they might not get to your question.

Dan: maybe we can close at plenary or next week

Sangwhan: it can be used to tell what user is searching for, problematic?

Amy: they link to a demo of that in s&p

Dan: could be problematic

Sangwhan: possible through an indirect channel..

Dan: is the user expectation that what they're searching for in an article is private to them?

Sangwhan: huge meta question here, I'm not sure. The query string can be referred to so what the user was looking for in a given webpage can be inferred by the referrer which contains the query string from a search engine (google removes that), except when you have scrolltotextfragment enabled when you can infer to some level. I don't really know the implications.

Dan: should we ask privacy ig to weigh in?

2021-10-18

Minutes

Dan: opener responded helpfully with a PR

Lea: do we need to wait for it to be merged to close?

Dan: looking at PR.. writes closing comment.