Re: [blink-dev] Intent to Ship: Auto-expand details elements

[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

On Thu, Oct 14, 2021 at 12:05 PM Daniel Bratell  wrote:

> 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
> On 2021-10-14 21:02, Daniel Bratell wrote:
>
> LGTM3
>
> /Daniel
> On 2021-10-07 21:07, Mike West wrote:
>
> 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
>
>
> On Fri, Oct 1, 2021 at 11:42 AM Balazs Engedy  wrote:
>
>> Thank you for the detailed differential threat analysis, SGTM from the
>> permissions side. Glad to see the ongoing work on robust and comprehensive
>> mitigations.
>>
>> On Friday, October 1, 2021 at 1:41:54 AM UTC+2 Joey Arhar wrote:
>>
>>> > 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  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.
>>>
>>> On Thu, Sep 30, 2021 at 4:24 AM Balazs Engedy 
>>> wrote:
>>>
 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  element?
 On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike Taylor wrote:

> On 9/23/21 8:19 AM, Yoav Weiss wrote:
>
> On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner 
> 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?
>>
>> 
>>
> At the risk of jinxing UseCounter 

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[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

On 2021-10-14 21:02, Daniel Bratell wrote:


LGTM3

/Daniel

On 2021-10-07 21:07, Mike West wrote:

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


On Fri, Oct 1, 2021 at 11:42 AM Balazs Engedy  
wrote:


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

On Friday, October 1, 2021 at 1:41:54 AM UTC+2 Joey Arhar wrote:

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

On Thu, Sep 30, 2021 at 4:24 AM Balazs Engedy
 wrote:

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  element?
On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike
Taylor wrote:

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

On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner
 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?




At the risk of jinxing UseCounter metrics

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[Daniel Bratell]

LGTM3

/Daniel

On 2021-10-07 21:07, Mike West wrote:

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


On Fri, Oct 1, 2021 at 11:42 AM Balazs Engedy  wrote:

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

On Friday, October 1, 2021 at 1:41:54 AM UTC+2 Joey Arhar wrote:

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

On Thu, Sep 30, 2021 at 4:24 AM Balazs Engedy
 wrote:

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  element?
On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike
Taylor wrote:

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

On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner
 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?




At the risk of jinxing UseCounter metrics

,
another option would be to spec the `search` event
such that `preventDefault()` provides an opt-out here.

-- 
You received this message because you are 

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[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


On Fri, Oct 1, 2021 at 11:42 AM Balazs Engedy  wrote:

> Thank you for the detailed differential threat analysis, SGTM from the
> permissions side. Glad to see the ongoing work on robust and comprehensive
> mitigations.
>
> On Friday, October 1, 2021 at 1:41:54 AM UTC+2 Joey Arhar wrote:
>
>> > 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  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.
>>
>> On Thu, Sep 30, 2021 at 4:24 AM Balazs Engedy 
>> wrote:
>>
>>> 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  element?
>>> On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike Taylor wrote:
>>>
 On 9/23/21 8:19 AM, Yoav Weiss wrote:

 On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner 
 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?
>
> 
>
 At the risk of jinxing UseCounter metrics
 ,
 another option would be to spec the `search` event such that
 `preventDefault()` provides an opt-out here.

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

-- 
You received this message because you are 

Re: [blink-dev] Intent to Ship: Auto-expand details elements

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

On Friday, October 1, 2021 at 1:41:54 AM UTC+2 Joey Arhar wrote:

> > 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  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.
>
> On Thu, Sep 30, 2021 at 4:24 AM Balazs Engedy  wrote:
>
>> 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  element?
>> On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike Taylor wrote:
>>
>>> On 9/23/21 8:19 AM, Yoav Weiss wrote:
>>>
>>> On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner  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? 

 

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

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

Re: [blink-dev] Intent to Ship: Auto-expand details elements

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

On Thu, Sep 30, 2021 at 4:24 AM Balazs Engedy  wrote:

> 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  element?
> On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike Taylor wrote:
>
>> On 9/23/21 8:19 AM, Yoav Weiss wrote:
>>
>> On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner  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?
>>>
>>> 
>>>
>> At the risk of jinxing UseCounter metrics
>> ,
>> another option would be to spec the `search` event such that
>> `preventDefault()` provides an opt-out here.
>>
>

-- 
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/CAK6btwKN8w-Pna8v4z7wDodyKy%3DE0No%3DSM2-DXjAgCjSpdy0jg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[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  element?
On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike Taylor wrote:

> On 9/23/21 8:19 AM, Yoav Weiss wrote:
>
> On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner  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? 
>>
>> 
>>
> At the risk of jinxing UseCounter metrics 
> , 
> another option would be to spec the `search` event such that 
> `preventDefault()` provides an opt-out here.
>

-- 
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/59f4ba04-6078-43a6-907d-a4921098128bn%40chromium.org.

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[Mike Taylor]

On 9/23/21 8:19 AM, Yoav Weiss wrote:
On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner > 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?



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


--
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/32f6d7ac-0a08-8411-c485-2d26d578f6b5%40chromium.org.

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[Yoav Weiss]

LGTM1

On Thu, Sep 23, 2021 at 12:03 AM PhistucK  wrote:

> Not sure I completely agree, so, not so "right". :)
> Using / 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.


> 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*
>
>
> On Wed, Sep 22, 2021 at 10:28 PM Joey Arhar  wrote:
>
>> > 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?
>>
>> On Sat, Sep 18, 2021 at 10:58 AM PhistucK  wrote:
>>
>>> 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*
>>>
>>>
>>> On Sat, Sep 18, 2021 at 6:55 PM Joey Arhar  wrote:
>>>
 > 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.

 On Sat, Sep 18, 2021 at 10:54 AM PhistucK  wrote:

> Will there be an opt out (without resorting to using other elements)?
>
> ☆*PhistucK*
>
>
> On Fri, Sep 17, 2021 at 4:55 PM Joey Arhar 
> wrote:
>
>> > 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.
>>
>> On Fri, Sep 17, 2021 at 1:56 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 17, 2021 at 8:41 AM 'Thomas Steiner' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>


 On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar 
 wrote:

> Contact emailsjar...@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)
>>>
>>>

>
> Specificationhttps://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 componentBlink>HTML
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677
>

>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> If other browsers don't implement this feature for element

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[Yoav Weiss]

On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner  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?
>
> 
>

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

-- 
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/CAL5BFfUT_Mp3q9weCAWcEF89LQkrnRHJarxx-4UR2fs7Hyz%3DUw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Auto-expand details elements

['Thomas Steiner' via blink-dev]

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



-- 
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/CALgRrL%3DAL7xchm34A5_faVs0UmJBmvCvLivxXNVcdrkjpX836Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[PhistucK]

Not sure I completely agree, so, not so "right". :)
Using / 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*


On Wed, Sep 22, 2021 at 10:28 PM Joey Arhar  wrote:

> > 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?
>
> On Sat, Sep 18, 2021 at 10:58 AM PhistucK  wrote:
>
>> 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*
>>
>>
>> On Sat, Sep 18, 2021 at 6:55 PM Joey Arhar  wrote:
>>
>>> > 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.
>>>
>>> On Sat, Sep 18, 2021 at 10:54 AM PhistucK  wrote:
>>>
 Will there be an opt out (without resorting to using other elements)?

 ☆*PhistucK*


 On Fri, Sep 17, 2021 at 4:55 PM Joey Arhar  wrote:

> > 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.
>
> On Fri, Sep 17, 2021 at 1:56 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Fri, Sep 17, 2021 at 8:41 AM 'Thomas Steiner' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>>
>>>
>>> On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar 
>>> wrote:
>>>
 Contact emailsjar...@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)
>>
>>
>>>

 Specificationhttps://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 componentBlink>HTML
 

 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677

>>>

 TAG review statusPending

 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 (
 

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[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?

On Sat, Sep 18, 2021 at 10:58 AM PhistucK  wrote:

> 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*
>
>
> On Sat, Sep 18, 2021 at 6:55 PM Joey Arhar  wrote:
>
>> > 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.
>>
>> On Sat, Sep 18, 2021 at 10:54 AM PhistucK  wrote:
>>
>>> Will there be an opt out (without resorting to using other elements)?
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Fri, Sep 17, 2021 at 4:55 PM Joey Arhar  wrote:
>>>
 > 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.

 On Fri, Sep 17, 2021 at 1:56 AM Yoav Weiss 
 wrote:

>
>
> On Fri, Sep 17, 2021 at 8:41 AM 'Thomas Steiner' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>>
>>
>> On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar 
>> wrote:
>>
>>> Contact emailsjar...@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)
>
>
>>
>>>
>>> Specificationhttps://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 componentBlink>HTML
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677
>>>
>>
>>>
>>> TAG review statusPending
>>>
>>> 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:
>>> 

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[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*


On Sat, Sep 18, 2021 at 6:55 PM Joey Arhar  wrote:

> > 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.
>
> On Sat, Sep 18, 2021 at 10:54 AM PhistucK  wrote:
>
>> Will there be an opt out (without resorting to using other elements)?
>>
>> ☆*PhistucK*
>>
>>
>> On Fri, Sep 17, 2021 at 4:55 PM Joey Arhar  wrote:
>>
>>> > 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.
>>>
>>> On Fri, Sep 17, 2021 at 1:56 AM Yoav Weiss 
>>> wrote:
>>>


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

>
>
> On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar 
> wrote:
>
>> Contact emailsjar...@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)


>
>>
>> Specificationhttps://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 componentBlink>HTML
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677
>>
>
>>
>> TAG review statusPending
>>
>> 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.


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

Re: [blink-dev] Intent to Ship: Auto-expand details elements

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

On Sat, Sep 18, 2021 at 10:54 AM PhistucK  wrote:

> Will there be an opt out (without resorting to using other elements)?
>
> ☆*PhistucK*
>
>
> On Fri, Sep 17, 2021 at 4:55 PM Joey Arhar  wrote:
>
>> > 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.
>>
>> On Fri, Sep 17, 2021 at 1:56 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 17, 2021 at 8:41 AM 'Thomas Steiner' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>


 On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar  wrote:

> Contact emailsjar...@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)
>>>
>>>

>
> Specificationhttps://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 componentBlink>HTML
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677
>

>
> TAG review statusPending
>
> 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.
>>>
>>>

>
> 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:
> 

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[PhistucK]

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

☆*PhistucK*


On Fri, Sep 17, 2021 at 4:55 PM Joey Arhar  wrote:

> > 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.
>
> On Fri, Sep 17, 2021 at 1:56 AM Yoav Weiss  wrote:
>
>>
>>
>> On Fri, Sep 17, 2021 at 8:41 AM 'Thomas Steiner' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>>
>>>
>>> On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar  wrote:
>>>
 Contact emailsjar...@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)
>>
>>
>>>

 Specificationhttps://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 componentBlink>HTML
 

 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677

>>>

 TAG review statusPending

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

 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

Re: [blink-dev] Intent to Ship: Auto-expand details elements

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

On Fri, Sep 17, 2021 at 1:56 AM Yoav Weiss  wrote:

>
>
> On Fri, Sep 17, 2021 at 8:41 AM 'Thomas Steiner' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>>
>>
>> On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar  wrote:
>>
>>> Contact emailsjar...@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)
>
>
>>
>>>
>>> Specificationhttps://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 componentBlink>HTML
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677
>>>
>>
>>>
>>> TAG review statusPending
>>>
>>> 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.
>
>
>>
>>>
>>> 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
>>> 

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[Yoav Weiss]

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

>
>
> On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar  wrote:
>
>> Contact emailsjar...@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)


>
>>
>> Specificationhttps://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 componentBlink>HTML
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677
>>
>
>>
>> TAG review statusPending
>>
>> 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.


>
>>
>> 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 bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1185950
>>
>> Launch bughttps://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+unsubscr...@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
> 

Re: [blink-dev] Intent to Ship: Auto-expand details elements

['Thomas Steiner' via blink-dev]

On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar  wrote:

> Contact emailsjar...@chromium.org
>
> Explainer
> https://github.com/WICG/display-locking/blob/main/explainers/auto-expanding-details-explainer.md
>
> Specificationhttps://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 componentBlink>HTML
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677
>
> TAG review statusPending
>
> 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 bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1185950
>
> Launch bughttps://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+unsubscr...@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-

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