Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

[Madanagopal Damodharan]

Thanks James. We are able to add the header from our server's servlet 
filter code. It now appends the header for each response including static 
html files. It seems to be working fine so far. There are instances where 
it still gets blocked when a link is opened on new window. I believe we 
need to make sure the new window response contains the header as well, 
right? Also, if the header gets duplicated i.e. if the response contains 
the same header twice, it does not work. It looks as if the header is not 
sent at all. Is this how it is supposed to behave?

On Monday, 25 September 2023 at 20:23:51 UTC+5:30 W. James MacLean wrote:

> No, I think you need to get the server to send the header. Once you get as 
> far as the meta tags, the origin's isolation state has already been 
> decided. I'm not an expert on servers, but my experience in specifying 
> headers to be sent with static pages is to edit the .htaccess file in the 
> directory with the content, and include
>
> HEADER add Origin-Agent-Cluster: ?0
>
> But the exact details will depend on your setup.
>
> For Apache: https://httpd.apache.org/docs/2.4/howto/htaccess.html
>
> [image: GoogleAnimated.gif]
>
> ⭘ W. James MacLean
>
> ⭘ Software Engineer
>
> ⭘ Google Waterloo 
> , 
> Canada
>
> On Tue, 19 Sept 2023 at 23:40, Madanagopal Damodharan  
> wrote:
>
>> This helped us identify the response that did not have the header. We 
>> noticed that we have a static html called signon.html as our first entry 
>> into the application. Since this is a static html, our servlet changes to 
>> add response header does not hit when users invoke this signon.html. I 
>> think Chrome puts this origin into Origin-keyed cluster at this point and 
>> hence when users login and encounter document.domain, they get the error 
>> blocked frame error. 
>>
>> meta tags with http-equiv does not recognize this custom response header 
>> Origin-Agent-Cluster. Is there a way to add response headers in a static 
>> html page response?  
>>
>> On Wednesday, 13 September 2023 at 22:49:00 UTC+5:30 W. James MacLean 
>> wrote:
>>
>>> Perhaps try this:
>>> 1) open a new tab page (or about:blank if you prefer)
>>> 2) right-click and select "Inspect" at the bottom of the popup menu
>>> 3) in the DevTools menu at the top, click "Network"
>>> 4) then check the "Preserve Logs" checkbox in the row under that menu
>>> 5) finally, manually type the url for your app/site in the url bar
>>>
>>> As your content loads, the DevTools window will populate with an (in 
>>> order) list of all the network transactions. You can click on each element 
>>> in the list and see the response headers for each request. This should help 
>>> you determine which request is missing the Origin-Agent-Cluster:?0 header 
>>> and causing the origin keying to be applied for the tab.
>>>
>>> Let me know if that helps.
>>>
>>>
>>> [image: GoogleAnimated.gif]
>>>
>>> ⭘ W. James MacLean
>>>
>>> ⭘ Software Engineer
>>>
>>> ⭘ Google Waterloo 
>>> , 
>>> Canada
>>>
>>>
>>>
>>> On Wed, 13 Sept 2023 at 12:44, Madanagopal Damodharan <
>>> dmadan...@gmail.com> wrote:
>>>
 An update on the issue I am facing: We have a static html in web server 
 called signon.html. Users access this static html page first which has a 
 refresh directive with content=1. As soon as the user invokes this html 
 page first time from the origin, this redirects to a login form page. This 
 response contains the header too. But still chrome console says the origin 
 was in origin-keyed cluster. If I change the refresh directive content=5, 
 it takes 5 sec to redirect from signon.html to login form, this time I 
 don't get the console warning. Now I can login and dont see any errors. I 
 am not sure why the refresh directive 5 works but not 1. Is it because 
 Chrome could not capture request and place the origin in appropriate 
 cluster within its 1 second?

 Modified the CONTENT=5 from CONTENT=1 in the below line to get it 
 working - 

 Any thoughts?

 On Sunday, 10 September 2023 at 20:53:42 UTC+5:30 Madanagopal 
 Damodharan wrote:

 Thanks for response. In my case, I am getting the error when a new tab 
 is opened from an existing tab. My existing tab did not throw this error 
 whereas the new tab shows the error on the first request itself. So based 
 on what you mentioned, my parent tab should have been part of Origin-Keyed 
 cluster, right? I am seeing console warning as follows on my new tab that 
 was opened from an existing tab:

 "The page did not request an Origin-Keyed agent cluster but was put in 
 one anyway because the origin had previously been placed in an 
 origin-keyed 
 agent cluster. Update your headers to uniformly request origin-keying for 
 all pages on the 

[blink-dev] Intent to Ship: Fire toggle events using microtasks

[Joey Arhar]

Contact emailsjar...@chromium.org

Explainerhttps://github.com/whatwg/html/issues/9046

Specificationhttps://github.com/whatwg/html/pull/9775

Summary

The toggle events for the popover attribute and the details element, as
well as the close event for dialog elements, currently post a task to the
DOM manipulation task source to fire these events asynchronously. This
means that the event could fire before or after the next render, which
could lead to flaky rendering for one frame. By using microtasks instead,
the event will always fire before the next render. This was suggested in
this HTML spec issue: https://github.com/whatwg/html/issues/9046


Blink componentBlink>DOM


TAG reviewThis is a very small change so I'm not making a TAG review.

TAG review statusNot applicable

Risks


Interoperability and Compatibility

If websites are relying on the slower event timing somehow, then we could
run into problems.


*Gecko*: Positive?
https://github.com/whatwg/html/issues/9046#issuecomment-1724509340

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justification

I am not interested in any metrics changes for this feature, it should just
make the behavior more consistent for web developers. Should it prove to
have issues, I can disable it with a finch killswitch.


Requires code in //chrome?False

Adoption expectationIf we ship this without breaking websites, then I think
the other browsers will feel interested in implementing this as well.

Adoption planThis change modifies several WPTs which the other browsers are
likely watching, which will help encourage them to implement this as well.

Estimated milestones

No milestones specified


Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5123249231101952

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/CAK6btwJKWcg_ZCnSAs%3DML37a0Ov80V-gxcscbRwtCou15LE66w%40mail.gmail.com.

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

['Anupam Snigdha' via blink-dev]

Thanks Yoav! I pinged the TAG review thread.

From: Yoav Weiss 
Sent: Wednesday, October 4, 2023 3:58 AM
To: blink-dev 
Cc: Anupam Snigdha ; Sangwhan Moon ; 
blin...@chromium.org ; Sanket Joshi (EDGE) 
; Evan Stade ; jsb...@google.com 
; Chris Harrelson 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature 
detection for supported clipboard formats

Thanks for working on this! This seems like a welcome addition, and the example 
code of the current status quo is definitely something we need to solve!

On Wednesday, September 20, 2023 at 6:50:40 PM UTC+2 snianu wrote:
Thanks Chris for the clarification!
Filed TAG review: https://github.com/w3ctag/design-reviews/issues/901

Thanks for filing a TAG review. I think this can benefit from a holistic view 
of image formats and feature detection.
E.g. do we have such feature detection for 
drawImage()?
 
HTMLImageElement.decode()?
  Are there other APIs that can benefit from a similar pattern? Are there 
reasons for these APIs to have separate feature detection methods? (i.e. do we 
expect support to diverge between them)

I don't have any answers, but I appreciate you thinking through these questions 
with the TAG and coming up with some :)


Mozilla: https://github.com/mozilla/standards-positions/issues/889
Webkit: https://github.com/WebKit/standards-positions/issues/259

Please let me know if I missed anything. Thanks!

-Anupam

From: Chris Harrelson mailto:chris...@chromium.org>>
Sent: Wednesday, September 20, 2023 8:58 AM
To: Anupam Snigdha mailto:sni...@microsoft.com>>
Cc: Sangwhan Moon mailto:s...@chromium.org>>; 
blink-dev@chromium.org 
mailto:blink-dev@chromium.org>>; Sanket Joshi (EDGE) 
mailto:sa...@microsoft.com>>; Evan Stade 
mailto:est...@chromium.org>>; 
jsb...@google.com 
mailto:jsb...@google.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature 
detection for supported clipboard formats

Please do file a TAG review and ask for official vendor signals. It's great 
that it was approved by the editing WG, but we also need wider TAG review for 
features, and WebKit and Gecko would like to see signals requests go through 
their official process.

On Tue, Sep 19, 2023 at 9:25 AM 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Why is it not applicable?
Note that this API is already in the clipboard spec and was approved by the 
EditingWG 
members.
 I wasn't sure if we would need TAG to review it after it was approved by 
representatives from Webkit, Firefox and Chromium so I didn't file a TAG review 
request. I can certainly do it if it's required. Please let me know.


-Anupam


From: Sangwhan Moon mailto:s...@chromium.org>>
Sent: Monday, September 18, 2023 11:10 PM
To: Anupam Snigdha mailto:sni...@microsoft.com>>
Cc: blink-dev@chromium.org 
mailto:blink-dev@chromium.org>>; Sanket Joshi (EDGE) 
mailto:sa...@microsoft.com>>; Evan Stade 
mailto:est...@chromium.org>>; 
jsb...@google.com 
mailto:jsb...@google.com>>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature 
detection for supported clipboard formats

You don't often get email from s...@chromium.org. 
Learn why this is important
Interesting problem, never thought about this ergonomic problem.

On Sep 19, 2023, at 2:12, 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:


Contact emails
sni...@microsoft.com, 
sa...@microsoft.com, 
est...@chromium.org, 
jsb...@chromium.org, 
asu...@chromium.org

Explainer
https://github.com/w3c/clipboard-apis/issues/170


Specification

https://w3c.github.io/clipboard-apis/#clipboard-item-interface
https://w3c.github.io/clipboard-apis/#dom-clipboarditem-supports

Summary

Currently during async clipboard write operation, there is no way for the web 
authors to detect if a particular mime type is supported by the UAs or not 
before attempting to actually write the formats to the clipboard. This not only 
affects developer ergonomics as now web authors have to attempt to write to the 
clipboard first in order to find out whether write failed due to a particular 
mime type not supported by the UAs (or sometimes add version checks that are 
unreliable at best), but also leads to unnecessary cost in terms of CPU cycles, 
COGS etc in order to produce an expensive web custom format which may not be 
supported 

[blink-dev] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

['Anupam Snigdha' via blink-dev]

(edited the subject line)


From: Anupam Snigdha 
Sent: Thursday, October 5, 2023 4:22 PM
To: blink-dev@chromium.org 
Cc: Sanket Joshi (EDGE) ; Evan Stade 
; jsb...@google.com ; Ana Sollano Kim 

Subject: Intent to Implement and Ship: Async Clipboard API: Read unsanitized 
HTML and write well-formed HTML format.

Contact emails
sni...@microsoft.com, 
sa...@microsoft.com, 
est...@chromium.org, 
jsb...@chromium.org, 
asu...@chromium.org, 
ansol...@microsoft.com


Explainer
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md


Specification
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md

Summary

This proposal provides an `unsanitized` option in read() method to get the 
unsanitized HTML format. Unless sites explicitly opt-into reading the 
unsanitized HTML, they will get the sanitized HTML content by-default. 
Currently, when we read text/html MIME type using the async API, the sanitizer 
is invoked to strip out contents from the HTML markup due to security concerns, 
and styles are inlined into the HTML markup, which leads to a bloated HTML 
payload and loss of fidelity of HTML content when read by web authors or native 
apps. Firefox provides access to unsanitized HTML via DataTransfer APIs, which 
matches Chromium's behavior, and Safari only allows access to unsanitized HTML 
if it's being read within the same origin.


Comments

For more context on this change, here is a discussion between stakeholders: 
https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing


Blink component
Blink>DataTransfer

Search tags
unsanitized html, 
async api, 
clipboard

TAG review
There is no desire to standardize this behavior as discussed in 
https://github.com/w3c/clipboard-apis/issues/150#issuecomment-917273986. Also, 
Webkit was opposed to any change in behavior since their implementation of 
Async API interops with the DataTransfer API 
(https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1047152542).

TAG review status
Not applicable


WebFeature UseCounter name
AsyncClipboardAPIUnsanitizedRead

Risks


Interoperability and Compatibility

This is a Chromium-only feature (see discussion in 
https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing),
 so adding a dictionary as an argument in read will be ignored in non-Chromium 
browsers and the HTML read might be sanitized. As this change aligns the 
sanitization behavior of the DataTransfer API and the Clipboard Async API, 
existing paste targets that support DataTransfer APIs unsanitized HTML don't 
need to make updates on how they handle HTML if they decide to transition to 
the Clipboard Async API.

Gecko: Neutral (https://github.com/mozilla/standards-positions/issues/769) 
https://github.com/w3c/clipboard-apis/issues/150#issuecomment-1031684598

WebKit: Negative 
(https://github.com/w3c/clipboard-apis/issues/150#issuecomment-974236367)

Web developers: Positive. Positive signals from Excel Online, 
https://groups.google.com/a/chromium.org/g/blink-dev/c/j9fDbU9E2Ds/m/IPocqIfEAwAJ?utm_medium=email_source=footer

Ergonomics
The spec'd read method doesn't accept any arguments. With this feature, we have 
overloaded the read method in order to add a dictionary argument, where web 
authors will explicitly request for the unsanitized HTML format.

Activation
The current Clipboard Async API read method as specified in 
https://w3c.github.io/clipboard-apis/ isn't affected by the introduction of 
this feature, the behavior is validated through existing web tests.

Security
Sites have to explicitly opt into reading unsanitized HTML content via the 
"unsanitized" option, so any sites that don't have that option, would get the 
default, sanitized HTML content. The legacy DataTransfer APIs already allow 
access to unsanitized HTML content, so we don't think this will create any 
additional security loopholes.
Threat Model document:
https://docs.google.com/document/d/1QLt50Q8UnlQksVltZ2PNkDZVdk9N58Pq7P0lzGTKh-U/edit?usp=sharing

WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?
No.

Ergonomics

N/A

Activation

N/A


Security

N/A


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?

N/A

Debuggability

No specific DevTools changes are required. 

[blink-dev] Intent to Implement and Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

['Anupam Snigdha' via blink-dev]

Contact emails
sni...@microsoft.com, 
sa...@microsoft.com, 
est...@chromium.org, 
jsb...@chromium.org, 
asu...@chromium.org, 
ansol...@microsoft.com


Explainer
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md


Specification
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md

Summary

This proposal provides an `unsanitized` option in read() method to get the 
unsanitized HTML format. Unless sites explicitly opt-into reading the 
unsanitized HTML, they will get the sanitized HTML content by-default. 
Currently, when we read text/html MIME type using the async API, the sanitizer 
is invoked to strip out contents from the HTML markup due to security concerns, 
and styles are inlined into the HTML markup, which leads to a bloated HTML 
payload and loss of fidelity of HTML content when read by web authors or native 
apps. Firefox provides access to unsanitized HTML via DataTransfer APIs, which 
matches Chromium's behavior, and Safari only allows access to unsanitized HTML 
if it's being read within the same origin.


Comments

For more context on this change, here is a discussion between stakeholders: 
https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing


Blink component
Blink>DataTransfer

Search tags
unsanitized html, 
async api, 
clipboard

TAG review
There is no desire to standardize this behavior as discussed in 
https://github.com/w3c/clipboard-apis/issues/150#issuecomment-917273986. Also, 
Webkit was opposed to any change in behavior since their implementation of 
Async API interops with the DataTransfer API 
(https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1047152542).

TAG review status
Not applicable


WebFeature UseCounter name
AsyncClipboardAPIUnsanitizedRead

Risks


Interoperability and Compatibility

This is a Chromium-only feature (see discussion in 
https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing),
 so adding a dictionary as an argument in read will be ignored in non-Chromium 
browsers and the HTML read might be sanitized. As this change aligns the 
sanitization behavior of the DataTransfer API and the Clipboard Async API, 
existing paste targets that support DataTransfer APIs unsanitized HTML don't 
need to make updates on how they handle HTML if they decide to transition to 
the Clipboard Async API.

Gecko: Neutral (https://github.com/mozilla/standards-positions/issues/769) 
https://github.com/w3c/clipboard-apis/issues/150#issuecomment-1031684598

WebKit: Negative 
(https://github.com/w3c/clipboard-apis/issues/150#issuecomment-974236367)

Web developers: Positive. Positive signals from Excel Online, 
https://groups.google.com/a/chromium.org/g/blink-dev/c/j9fDbU9E2Ds/m/IPocqIfEAwAJ?utm_medium=email_source=footer

Ergonomics
The spec'd read method doesn't accept any arguments. With this feature, we have 
overloaded the read method in order to add a dictionary argument, where web 
authors will explicitly request for the unsanitized HTML format.

Activation
The current Clipboard Async API read method as specified in 
https://w3c.github.io/clipboard-apis/ isn't affected by the introduction of 
this feature, the behavior is validated through existing web tests.

Security
Sites have to explicitly opt into reading unsanitized HTML content via the 
"unsanitized" option, so any sites that don't have that option, would get the 
default, sanitized HTML content. The legacy DataTransfer APIs already allow 
access to unsanitized HTML content, so we don't think this will create any 
additional security loopholes.
Threat Model document:
https://docs.google.com/document/d/1QLt50Q8UnlQksVltZ2PNkDZVdk9N58Pq7P0lzGTKh-U/edit?usp=sharing

WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?
No.

Ergonomics

N/A

Activation

N/A


Security

N/A


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?

N/A

Debuggability

No specific DevTools changes are required. This feature is treated like any 
other JS method.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, 
Chrome OS, Android, and Android WebView)?
Yes

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

Flag name on 

Re: [blink-dev] Intent to Ship: Media Session API: enterpictureinpicture action

['Chris Harrelson' via blink-dev]

Hi,

Please update your chromestatus entry to trigger the other 5 review
categories for this intent. I think it's probably the case that you ended
up with the wrong feature category and need to update it, sorry for any
confusion. @Jason Robbins  also.

On Wed, Oct 4, 2023 at 3:35 PM 'Tommy Steimel' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> stei...@chromium.org, liber...@chromium.org
>
> Explainer
>
> https://github.com/w3c/mediasession/issues/294
>
> Specification
>
> https://github.com/w3c/mediasession/pull/295
>
> API spec
>
> Yes
>
> Summary
>
> Adds an 'enterpictureinpicture' action to the Media Session API. Websites
> can register an action handler which can be used to open a
> Picture-in-Picture or Document Picture-in-Picture window.
>
> Blink component
>
> Blink>Media>Session
>
> TAG review
>
> This small addition to the Media Session API doesn’t seem to qualify for a
> TAG review.
>
> Note that one for video conferencing actions was approved previously at
> https://github.com/w3ctag/design-reviews/issues/608
>
> TAG review status
>
> N/A
>
> Debuggability
>
> No DevTools changes are required, treated like any other attribute/enum.
>
> Risks
>
>
> Interoperability and Compatibility
> It’s low risk as it's a small addition to an existing API that both Gecko
> and WebKit approve of.
>
>
> Signals from other implementations (Gecko, WebKit):
>
> Gecko: No signal
>
> WebKit: No signal - Generally positive feedback when discussed in the
> Media WG, but no official position pursued due to the small nature of the
> change
>
> Web / Framework developers: Positive
>
> (https://github.com/WICG/document-picture-in-picture/issues/96)
>
> The above citation is one example amongst many where developers want to be
> able to initiate pip through other means (e.g. automatically when switching
> tabs or when a picture-in-picture button is pressed in browser UI), and
> having a media session action for this enables the UA to allow the website
> to open a picture-in-picture window in these cases
>
>
> Ergonomics:
>
> N/A: small addition to an enum of an existing API
>
> Activation:
>
> Web developers will be able to simply set/unset a media session action
> handler for “enterpictureinpicture” to make use of this change. When the
> action name is not supported, it raises a TypeError which can be caught to
> detect feature support.
>
> Is this feature fully tested by web-platform-tests?
>
> https://wpt.fyi/results/mediasession/setactionhandler.html
>
> Tracking bug
>
> https://crbug.com/1457056
>
> Estimated milestones
>
> Shipping on desktop 120
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/6245717716238336
>
> --
> 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/CAE-AwAr3XMLjkds47PAf5_n-m%2Bv5mLXKBbX5211E_qs-W3sqTA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_MhTidY-mmVL7pa9smzEsBnJy_7OZ3Jw6njeZpOSKG8Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

[Chris Harrelson]

LGTM2

On Wed, Oct 4, 2023 at 10:46 PM Yoav Weiss  wrote:

> LGTM1
>
> On Wed, Oct 4, 2023 at 7:17 PM Alex Turner  wrote:
>
>> Mike: thanks for the clarification, I've added a comment to the TAG
>> review and kicked off those reviews in a new entry:
>> https://chromestatus.com/feature/5148973702840320. I'll ping this thread
>> when those reviews are complete.
>>
>> Yoav: yes, that's our understanding (although until enrollment is
>> enforced there is a chance we don't have a complete view of the testers).
>> We're in touch with a few partners who are using it that we will
>> communicate to directly. We also have a mailing list to broadcast these
>> kinds of updates more generally. Given that, we feel confident the impact
>> will be minimal to those testing the API.
>>
>> Alex
>>
>> On Wed, Oct 4, 2023 at 6:50 AM Yoav Weiss  wrote:
>>
>>> Am I right to assume that the API is still only being used by a
>>> relatively small number of partners to which y'all can communicate the new
>>> constraints?
>>>
>>> On Monday, October 2, 2023 at 11:08:43 PM UTC+2 Mike Taylor wrote:
>>>
 Hey Alex,

 Apologies for the delay. It would probably be good to make a new entry
 and request all the relevant review approvals (sorry for the extra work).

 Also, probably useful to drop a link in the TAG review to this Intent,
 so reviewers can eventually be aware of these changes.
 On 9/27/23 2:35 PM, Alex Turner wrote:

 I set this feature up as a "Web developer facing change to existing
 code", but I'm seeing that "New feature incubation" may have been more
 appropriate (although the guidance
  is
 a bit uncertain). Unfortunately, that means chromestatus won't let me
 request any reviews other than API owners; would it make sense to create a
 new feature entry? (Note also that these changes have already gone through
 internal privacy and security reviews.)

 Thanks!
 Alex

 On Wed, Sep 27, 2023 at 12:02 PM Chris Harrelson 
 wrote:

> Please also fill out the other chromestatus review categories for this
> Intent, in particular for Privacy and Security, thanks.
>
> On Tue, Sep 26, 2023 at 11:14 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Mon, Sep 25, 2023 at 11:52 PM Alex Turner 
>> wrote:
>>
>>> Contact emails ale...@chromium.org
>>>
>>> Specification
>>>
>>>-
>>>
>>>Null report fixes:
>>>
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91
>>>-
>>>
>>>Debug mode eligibility changes:
>>>
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90
>>>-
>>>
>>>Padding report payloads:
>>>
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98,
>>>https://github.com/WICG/attribution-reporting-api/pull/1030
>>>-
>>>
>>>Reducing delay:
>>>
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103
>>>
>>>
>>> Summary
>>>
>>> We're planning a few bundled changes to Private Aggregation:
>>>
>>>-
>>>
>>>Null report fixes: Currently reports with no contributions are
>>>inadvertently dropped. This change ensures that, when a context ID is
>>>specified, a null report is sent even if budget is denied. 
>>> Separately, it
>>>fixes a bug causing budget to always be denied for null reports.
>>>-
>>>
>>>Debug mode eligibility changes: Currently, debug mode is always
>>>available. This change only allows debug mode for callers that are 
>>> allowed
>>>access to third-party cookies, silently dropping the debug mode 
>>> otherwise.
>>>Note that this will allow debug mode to automatically sunset when
>>>third-party cookies are deprecated.
>>>-
>>>
>>>Padding report payloads: To avoid the payload size being
>>>dependent on the number of contributions, we will pad it with 'null'
>>>contributions to a fixed length. **Note**: this change will also 
>>> affect
>>>Attribution Reporting’s aggregatable reports.
>>>-
>>>
>>>Reducing delay: When a context ID is specified, we remove the
>>>randomized 10-60 minute delay, which is superfluous as a report is 
>>> always
>>>sent in this case. Instead, we just wait until the Shared Storage 
>>> operation
>>>timeout.
>>>
>>>
>>> Blink component Blink>PrivateAggregation
>>> 
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/846 (We
>>> have not requested a signal for these changes specifically.)
>>>
>>> TAG review 

Re: [blink-dev] Intent to Extend Origin Trial: Cross App and Web Attribution Measurement M120-M123

[Chris Harrelson]

Hi,

Two questions:
* Can you demonstrate any substantial progress

since the original OT request towards the requirements for shipping the
feature?
* Could you share any learnings or experimental feedback gathered so far?

On Wed, Oct 4, 2023 at 10:20 AM Nan Lin  wrote:

> Contact emails
>
> johni...@chromium.org, csharri...@chromium.org, lin...@chromium.org
>
> Explainer
>
> https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
> 
>
>
> Summary
>
> Currently, the Attribution Reporting API
>  supports attributing
> events within a single browser instance. This proposal expands the scope of
> attribution to allow attributing conversions that happen on the web to
> events that happen off the browser, within other applications such as
> mobile applications, or vice-versa.
>
> The proposal here takes advantage of OS-level support for attribution. In
> particular, it gives the developer an option to allow events on the mobile
> web to be joinable with events in Android’s Privacy Sandbox
> ,
> although support for other platforms could also be implemented in the
> future.
>
> The experiment will be on Android T
> , S
> , and R
>  devices only.
>
> We are planning to extend the experiment for 4 more milestones M120 to
> M123 inclusive.
>
>
> Blink component
>
> Internals>AttributionReporting
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/724 (Attribution
> Reporting API)
>
> TAG review status
>
> Pending
>
> Risks
> Interoperability
>
> Web developers: Some testers are currently implementing and providing
> feedback, and commitment from an additional 5+ testers to begin engagement
> later this year.
>
>
> Goals for experimentation
>
> For experimentation with the new extension of the Attribution Reporting
> API, we hope to see that the measurement data made available through the
> API provides useful ad conversion data cross app and web, and that
> developers are able to work against both the Chrome and Android Attribution
> APIs.
>
>
> Justification for extension
>
> Cross app web Attribution Reporting API is currently enabled on Android T+
> devices on the following platforms/channels:
>
> Android: Canary/Dev (50%), Beta (50%), Stable (99%)
>
> Android WebView: Canary/Dev (50%), Beta (50%), Stable (10%)
>
> The Android API itself is available on 90% on Android T.
>
> Currently the page load for the Cross App Web Attribution Reporting API is
> at 0.0128%
> ,
> which we feel also mitigates burn-in risk.
>
> The experiment on Android WebView is still being ramped up with a few
> planned enhancements. We plan to start the experiment on Android S and R
> devices soon as well.
>
> Given the complexity of using the new Web API in conjunction with the new
> Android APIs, partner testing has taken longer than expected. With this
> extension, we hope to get additional data on the usefulness of this API and
> insights into any issues in the system.
>
> Ongoing technical constraints
>
> None.
>
>
> Debuggability
>
> The Attribution Reporting API utilizes DevTools and an internal page
> (chrome://attribution-internals) to facilitate testing and integration. Debug
> reports
> 
> are supported (and when configured in a third-party context, require
> third-party cookies to be available).
>
>
> The debugging information for OS registrations is displayed in DevTools
> and in chrome://attribution-internals as well. Android Measurement is also
> implementing a similar debugging reports framework to facilitate cross app
> and web testing.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> No, only on Android and Android WebView for this experiment.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No, web platform tests are not supported for Android.
>
> Flag name
>
> privacy-sandbox-ads-apis
>
> Requires code in //chrome?
>
> No.
>
> Launch bug
>
> https://launch.corp.google.com/launch/4238495
>
> Estimated milestones
>
> We’d like to extend the origin 

Re: [blink-dev] Intent to Experiment: Open popups as fullscreen windows

[Chris Harrelson]

LGTM to experiment.

Thank you for completing the privacy and security reviews!

On Thu, Oct 5, 2023 at 9:16 AM 'Ajay Rahatekar' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi All,
>
> We have secured Privacy, Security and Debuggability approvals in
> chromestatus for the Origin Trial.
>
> On Wednesday, October 4, 2023 at 12:19:30 PM UTC-7 Ajay Rahatekar wrote:
>
>> Thank you Yoav, for your comments. We have requested Privacy and Security
>> reviews in chromestatus. The Security/Privacy questionnaire is available at
>> https://github.com/w3c/window-management/blob/main/security_and_privacy_fullscreen_popups.md
>> .
>>
>> The Privacy and Security review for this feature was started before the
>> Privacy/Security gates were required in chromestatus and so reviews were
>> conducted using internal process.
>> https://launch.corp.google.com/launch/4263088 (Sorry, internal only) .
>>
>>
>> On Wednesday, October 4, 2023 at 3:43:12 AM UTC-7 yoav...@chromium.org
>> wrote:
>>
>>> Personally, I'd love to see the Privacy and Security boxes in
>>> chromestatus turn to green before approving this, as this seems like a
>>> potentially risky feature.
>>> Bonus point for pointers to public notes from that review :)
>>>
>>> On Wednesday, October 4, 2023 at 6:25:58 AM UTC+2 ajayra...@google.com
>>> wrote:
>>>
 Hi API Owners,

 Please let us know if you have any other questions or comments. The
 Origin Trial is planned for M119 shipping to Stable on Tue, Oct 31, 2023.

 Thanks in advance.

 -Ajay

 On Thursday, September 28, 2023 at 3:30:56 PM UTC-7 btr...@chromium.org
 wrote:

> Avi: That's right, window-management permission must be granted for
> this feature to work (and appropriate permission policies). If not, the
> behavior falls back to opening the popup normally.
>
> Eric: We share your concerns. Besides the permission requirement,
> existing user security mitigations prohibit popups (fullscreen or
> otherwise) showing over existing HTML Fullscreen windows. Chromium-based
> browsers exit HTML Fullscreen when a popup window from the opener chain is
> opened or moved onto the same display. Attackers gain little advantage
> using this HTML Fullscreen API entrypoint over the classic
> Element.requestFullscreen().
>
>
> Regards,
> Brad
>
> On Thu, Sep 28, 2023 at 1:14 PM Avi Drissman  wrote:
>
 As a clarification, would this be behind and gated by the Window
>> Management permission? The URLs of the spec imply that but I wanted to be
>> sure.
>>
>> Avi
>>
>> On Tue, Sep 26, 2023 at 4:16 PM Brad Triebwasser 
>> wrote:
>>
> Contact emails
>>>
>>> btr...@chromium.org, m...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/w3c/window-management/blob/main/EXPLAINER_fullscreen_popups.md
>>>
>>> Specification
>>>
>>>
>>> https://github.com/w3c/window-management/blob/main/EXPLAINER_fullscreen_popups.md#spec-changes
>>>
>>> Design docs
>>>
>>>
>>> https://github.com/w3c/window-management/blob/main/security_and_privacy_fullscreen_popups.md
>>>
>>> Summary
>>>
>>> Adds the ability to open a popup directly to fullscreen.
>>>
>>> Adds a `fullscreen` option to the `windowFeatures` parameter to the
>>> `window.open()` JavaScript API, which allows the caller to open a popup
>>> directly to full-screen on the display that would contain the popup 
>>> (based
>>> on `screenX`/`screenY`). This eliminates the need for the developer to
>>> manually transition a popup into fullscreen, which could require a 
>>> separate
>>> user activation signal.
>>>
>>> Blink component
>>>
>>> Blink>Fullscreen
>>> ,
>>> Blink>WindowDialog
>>> ,
>>> Blink>Screen>MultiScreen
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/840
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/714)
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/standards-positions/issues/101)
>>>
>>> Web developers: Positive
>>> https://github.com/w3c/window-placement/issues/7
>>> https://github.com/w3c/window-placement/issues/98
>>> https://github.com/w3c/window-placement/issues/92
>>>
>>> Other signals:
>>>
>>> WebView application risks
>>>
>>> This feature is not supported on WebView, attempted usage will fall
>>> back 

Re: [blink-dev] Intent to Ship: Relaxed CSS Nesting

[Chris Harrelson]

LGTM3

On Wed, Oct 4, 2023 at 3:54 AM Manuel Rego Casasnovas 
wrote:

> LGTM2
>
> On 04/10/2023 11:49, Yoav Weiss wrote:
> > Thanks for clarifying and verifying! :) My LGTM still stands.
> >
> > On Wed, Oct 4, 2023 at 11:48 AM Anders Hartvoll Ruud
> > mailto:andr...@chromium.org>> wrote:
> >
> >
> >
> > On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud
> > mailto:andr...@chromium.org>> wrote:
> >
> > On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss
> > mailto:yoavwe...@chromium.org>> wrote:
> >
> > LGTM1
> >
> > Thanks for evaluating the compat risk for this. While
> > non-zero, it seems manageable given Mozilla already shipping
> > this, with Safari likely to follow, given the landed
> > implementation.
> >
> >
> > Clarification: Mozilla is shipping the main part of the feature
> > (retrying a failed declaration as a nested style rule), but they
> > are not (yet) shipping the tweaks to css-syntax described as
> > risk (1) and (2). (1) is a recent resolution (~three weeks), so
> > no mystery there. (2) has been part of this all along - I assume
> > it was seen as something that could be done separately (and it
> is).
> >
> >
> > Just to make sure it wasn't /deliberately/ omitted for whatever
> > reason, I checked with Emilio and they do intend to implement (1)
> > and (2) once it's specified.
> >
> >
> > So in this case "Mozilla: Shipping" should only be interpreted
> > as a positive signal for the overall change, not as a way to
> > manage compat risk. :-)
> >
> > I'll emphasize again though, that in both (1) and (2), we're
> > just changing from one kind of invalid/has-no-effect to a
> > /slightly/ different kind of invalid/has-no-effect.
> >
> > On Mon, Oct 2, 2023 at 1:30 PM Anders Hartvoll Ruud
> > mailto:andr...@chromium.org>> wrote:
> >
> >
> > Contact emails
> >
> > andr...@chromium.org 
> >
> >
> > Specification
> >
> >
> https://drafts.csswg.org/css-syntax/#consume-block-contents <
> https://drafts.csswg.org/css-syntax/#consume-block-contents>
> >
> >
> > Summary
> >
> > Allows nested style rules
> > <
> https://drafts.csswg.org/css-nesting-1/#nested-style-rule> to begin with
> an identifier. For example, the following will now be possible:
> >
> >
> > p {
> >
> >span { color: green; }
> >
> > }
> >
> >
> > 
> >
> >I am green
> >
> > 
> >
> >
> > Before this change, the inner spanselector had to be
> > “escaped” using :is()or similar, due to restrictions in
> > css-syntax. These restrictions have now been lifted by
> > giving the parser the ability to restart
> > <
> https://drafts.csswg.org/css-syntax/#token-stream-restore-a-mark>.
> >
> >
> > Blink component
> >
> > Blink>CSS
> > <
> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
> >
> >
> > TAG review
> >
> > None
> >
> >
> > TAG review status
> >
> > Not applicable
> >
> >
> > Risks
> >
> >
> >
> > Interoperability and Compatibility
> >
> > To address some problematic parsing edge cases, the
> > CSSWG has made two additional changes to css-syntax that
> > have theoretical web-facing impact. These changes will
> > ship in this intent as well:
> >
> >
> >  1.
> >
> > Braces ({}) are now fundamentally invalid in
> > standard properties, unless they span the whole
> > value. No property grammar allows {}in any part of
> > the value currently, so this is already invalid, but
> > when var()is used in combination with {}, this
> > intent changes whenit becomes invalid. With this
> > intent, e.g. color: var(--x) {};becomes invalid
> > parse-timeinstead of at computed-value time
> > <
> https://drafts.csswg.org/css-variables/#invalid-at-computed-value-time>.
> This isan observable difference, but there’s no known reason for this to
> occur in practice outside of mistakes. Nevertheless, I have tried to
> estimate the number of possibly-impacted sites:  ~0.0011% (Web Compat
> Analysis: Relaxed Nesting <
> https://docs.google.com/document/d/1WxIAXWFy3q9XJrFK8k2J5my71jn8Cvdxq6Z8NAg99Q0/edit#bookmark=id.ufp2erlyto93
> >[@chromium.org ]).
> 

Re: [blink-dev] Re: Intent to Ship: Close requests for CloseWatcher, , and popover=""

[Chris Harrelson]

Hi,

While Alex's concerns are totally valid to consider from a feature design
perspective, I think they are better to be discussed on the WHATWG issues
for this feature. I chatted offline with Alex and he agreed about that
point, and agreed to post comments and questions there.

So from an API owners perspective LGTM1 modulo considering and taking into
account all comments and feedback from Alex on the spec (as we should for
all such feedback from anyone, of course!).


On Wed, Oct 4, 2023 at 8:28 AM Domenic Denicola 
wrote:

>
>
> 2023年10月4日(水) 8:16 Alex Russell :
>
>>
>>
>> On Monday, October 2, 2023 at 10:16:53 AM UTC-7 Domenic Denicola wrote:
>>
>>
>>
>> 2023年10月2日(月) 10:11 Alex Russell :
>>
>>
>>
>> On Sunday, October 1, 2023 at 9:08:57 PM UTC-7 Domenic Denicola wrote:
>>
>> On Sat, Sep 30, 2023 at 5:01 AM Alex Russell 
>> wrote:
>>
>> The implicit behaviours based on construction order in this API are very
>> strange and seem like footguns.
>>
>>
>> I don't understand why you find this strange, or a footgun. It's intended
>> to be the opposite: it guides developers toward creating the experience the
>> user expects, where when the user requests to close something, the last
>> thing that was opened, is what closes.
>>
>>
>> Chris Palmer covered this pretty well recently, so I'll defer to his more
>> eloquent writeup:
>>
>> https://noncombatant.org/2023/05/29/complexities-of-allocation/
>>
>> Basically, this is spooky action at a distance and without _at least_
>> some reflection and manipulation surface (via DOM, probably), it's hard to
>> understand how this won't turn into a footgun.
>>
>> As a separate note, I'm disappointed in the proliferation of APIs that
>> affect DOM but have no API and reflection. Import Maps spring to mind, but
>> there are other recent examples too. If manual disposal is going to be
>> required for this, we should at least make it possible to introspect
>> outside the scope in which an object that defines this behaviour is
>> allocated.
>>
>>
>> In what way does this API affect the DOM? No parts of the DOM tree are
>> modified by CloseWatcher. The same is true for import maps...
>>
>>
>> This is view state, which is frequently reflected via DOM. The primary
>> concern here is that there's no way to inspect and/or modify the stack
>> (attached to Node instances or not) independently of closure-scoped object
>> lifetimes.
>>
>
> It's not clear to me what definition of "view state" you are using, such
> that it encompasses things like the module specifier resolution algorithm
> or the routing of Android back gestures.
>
> Maybe, if this is a principle you believe in, you could file it as a
> suggestion on the w3ctag/design-principles repository, ideally with a clear
> explanation of what the boundaries of this "view state" concept are.
> (Including what, in your view, would *not* quality as view state.)
>
>
>>
>> The TAG feedback didn't touch on this very much, AFAICT, but it's
>> somewhat surprising that the stack of close actions isn't inspectable.
>>
>>
>> I can't speak for the TAG, but here are the reasons why the stack of
>> close watchers isn't inspectable:
>>
>>- We received no developer or partner feedback requesting this
>>capability
>>- This could cause potential forward-compat problems without careful
>>design. E.g., it could make it possible for developers to write code that
>>assumes that only CloseWatchers, dialogs, and popover="" elements are 
>> close
>>watchers, and thus make it hard for the web platform to introduce a fourth
>>close watcher (e.g., ) in the future.
>>- This would be somewhat of an encapsulation leak between different
>>parts of the application, making it harder to write resilient components.
>>(This is not a strong argument, but rather a bias toward waiting for a use
>>case instead of just exposing the information automatically.)
>>
>> Thanks, I appreciate the context, and I am impressed by the thoroughness
>> of the design artifacts.
>>
>>
>> What's the behaviour of non-`destroy()`'d watchers; e.g. if a developer
>> forgets to dispose of one correctly? Can users get stuck?
>>
>>
>> Non-destroy()ed is the default state of a CloseWatcher, so such
>> CloseWatchers will respond to the next close request if they are on the top
>> of the stack. The user cannot really get stuck, as every close request will
>> either destroy the topmost close watcher on the stack, or possibly trigger
>> (at most once) a preventDefault()ed cancel event. See
>> https://github.com/WICG/close-watcher/blob/main/README.md#abuse-analysis
>> for more details.
>>
>>
>> Also helpful; thank you!
>>
>>
>> Note that the API generally guides you away from this possibility by
>> making the simpler code be the one that automatically calls destroy() for
>> you: https://github.com/WICG/close-watcher/blob/main/README.
>> md#requesting-close-yourself .
>>
>>
>>
>> On Wednesday, September 27, 2023 at 7:43:49 PM UTC-7 Domenic Denicola
>> 

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

[Alex Russell]

LGTM3

On Thursday, October 5, 2023 at 1:36:25 PM UTC-7 Scott Jehl wrote:

> Thanks!!
>
> On Thursday, 5 October 2023 at 16:14:19 UTC-4 Dale Curtis wrote:
>
>> Thanks!
>>
>
>> On Thu, Oct 5, 2023 at 12:53 PM Yoav Weiss  wrote:
>>
> LGTM1
>>>
>>> Thanks for correcting this historical mistake!
>>>
>>> On Thu, Oct 5, 2023, 21:11 Dale Curtis  wrote:
>>>
 Contact emailsdalec...@chromium.org

 ExplainerNone

>>>
>>> We could almost use MDN as the explainer, other than my comment below.
>>>
>>>

 Specification
 https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource

 Design docs
 https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source#media

>>>
>>> MDN still says the media on is only allowed with a  
>>> parent. Could y'all file an issue to get that fixed?
>>>
>> One was already filed here:
>> https://github.com/mdn/content/issues/27079
>>
>  
>>
>>>
>>>

 Summary

 Adds support for CSS media queries to  elements used with 
  elements. Allowing developers to use media query syntax to tell 
 the 
 browser which source should be preferred for a given environment.


 Blink componentBlink>Media>Video 
 

 TAG reviewNone

>>>
>>> Not required as it's part of the spec and shipped in other 
>>> implementations.
>>>
>>

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 Chromium used to support this feature, but it was deprecated and 
 removed in https://bugs.chromium.org/p/chromium/issues/detail?id=338197 
 -- foolip@ now believes this removal was incorrect.


 *Gecko*: Shipped/Shipping (
 https://bugzilla.mozilla.org/show_bug.cgi?id=1836128)

 *WebKit*: Shipped/Shipping (
 https://github.com/whatwg/html/issues/6363#issuecomment-1556228111)

 *Web developers*: Positive (12 stars on the issue. Developers are 
 passionate enough to implement the feature themselves in Firefox)

 *Other signals*:

 WebView application risks

 Does this intent deprecate or change behavior of existing APIs, such 
 that it has potentially high risk for Android WebView-based applications?

 None


 Debuggability

 None


 Will this feature be supported on all six Blink platforms (Windows, 
 Mac, Linux, Chrome OS, Android, and Android WebView)?Yes

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


 https://wpt.fyi/results/html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-source-media-env-change.html?label=master=experimental
  


 Flag name on chrome://flagsNone

 Finch feature nameVideoSourceMediaQuerySupport

 Requires code in //chrome?False

 Tracking bug
 https://bugs.chromium.org/p/chromium/issues/detail?id=1450316

 Estimated milestones
 Shipping on desktop 120
 Shipping on Android 120
 Shipping on WebView 120

 Anticipated spec changes

 Open questions about a feature may be a source of future web compat or 
 interop issues. Please list open issues (e.g. links to known github issues 
 in the project for the feature specification) whose resolution may 
 introduce web compat/interop risk (e.g., changing to naming or structure 
 of 
 the API in a non-backward-compatible way).
 None

 Link to entry on the Chrome Platform Status
 https://chromestatus.com/feature/5144127067127808

 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/CAPUDrwcJ42qj-ddQQcRi8f-YmfmzbkU-VStxdeM%2By_8u3%3Dh9-Q%40mail.gmail.com
  
 
 .

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e7a53d3f-db6c-4622-81b4-9be31bcfda0an%40chromium.org.

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Jayakrishnan Gounder]

Hi All,

We are facing the same problem as others. We have chrome extension page in 
a Iframe on top of another web apps. When the *"Block third-party cookies"* 
is turned on, we are getting the following error:

*"DOMException: Failed to read the 'localStorage' property from 'Window': 
Access is denied for this document."*

As per this link Storage Partitioning - Chrome for Developers 
,
 
we've already set the host permissions for all the web apps, and Extension 
uses Manifest v3.

Only way to make it work is turn "Block third party cookies" off. It used 
to work before regardless of the state of "Block third-party cookies".

I am looking forward to your response, thanks for your cooperation.

Regards.

On Thursday, 5 October 2023 at 12:22:51 UTC-7 Kyra Seevers wrote:

> Hi Illia,
>
> Thanks for reaching out - does this bug answer any of your questions?: 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1481485=reporter%3Ame=1
>
> If not, could you please file a bug describing your set-up here: 
> https://bugs.chromium.org/p/chromium/issues/entry, and add the label 
> "Proj-StoragePartitioningTrial" and cc kyras...@chromium.org?
>
> In the bug, please include information about your extension set-up - does 
> the extension have host permissions for each of the websites? Is it 
> Manifest v2 or v3?
>
> Thanks,
> Kyra
>
> On Wed, Oct 4, 2023 at 8:19 AM Illia Kyselov  wrote:
>
>> Hi all,
>>
>> I hope this message finds you in good health. I am reaching out to seek 
>> your expertise in helping me solve a problem.
>>
>> Our app incorporates an extension that aids users in accruing information 
>> from diverse sites, a feature that is instrumental in social network and 
>> business development, among other applications. A crucial aspect of this 
>> function is the user's ability to open the extension and add contacts 
>> without the need to log in in our app in extension at each individual 
>> website (as login information is stored in Local Storage).
>>
>> From my understanding, we cannot use the option 
>> DisableThirdPartyStoragePartitioning because our extension has to work 
>> across all websites.
>>
>> This leads me to question if there is no immediate solution to this 
>> problem. Does this imply we need to contemplate workarounds, potentially 
>> affecting the user experience of our app?
>>
>> I eagerly await your advice on this matter. Your assistance and 
>> contribution are greatly appreciated. Thank you for your continued support.
>>
>> Best regards.
>>
>> On Thursday, September 28, 2023 at 5:01:12 PM UTC+3 Kyra Seevers wrote:
>>
>>> Hi all,
>>>
>>> Quick update: the ThirdPartyStoragePartitioning feature flag is now 
>>> enabled by default in Canary. We will be rolling out to 100% Stable shortly.
>>>
>>> Manish - could you please file a bug describing your set-up here: 
>>> https://bugs.chromium.org/p/chromium/issues/entry, and add the label 
>>> "Proj-StoragePartitioningTrial". Also, have you looked into our deprecation 
>>> trial in the meantime?: 
>>> https://developer.chrome.com/en/blog/storage-partitioning-deprecation-trial/
>>> .
>>>
>>> Thanks all,
>>> Kyra
>>>
>>> On Tue, Sep 26, 2023 at 11:56 AM Manish Bisht  
>>> wrote:
>>>
 Hi,

 Is this enabled by default to chrome dev without the use or feature 
 flag ?

 Also is there any example of host_permissions that is mentioned here 
 
  because 
 I don't think this is working with the chrome flag enabled.

 Thanks,

 On Monday, September 25, 2023 at 6:57:16 PM UTC+5:30 Kyra Seevers wrote:

> Hi all,
>
> Wanted to keep the thread updated and confirm that we have not shipped 
> to Stable 100% yet. We will be delaying another day or two due to 
> internal delays.
>
> Thanks,
> Kyra
>
> On Wed, Sep 20, 2023 at 8:53 AM Kyra Seevers  
> wrote:
>
>> Hi Chinmay,
>>
>> Thanks for reaching out! Due to internal delays, we won't be rolling 
>> out to Stable 100% likely until the end of the week or the beginning of 
>> next week. I'll keep the thread updated with any further delays.
>>
>> Thanks,
>> Kyra
>>
>> On Tue, Sep 19, 2023 at 7:50 PM Chinmay Manchanda  
>> wrote:
>>
>>> Hi Kyra,
>>>
>>> Do we have an update on what time the feature will be rolled out 
>>> today?
>>>
>>> Cheers,
>>> Chinmay
>>>
>>> On Tuesday, 12 September 2023 at 18:06:57 UTC+10 Kyra Seevers wrote:
>>>
 Hi Muhammad,

 I have filed this bug for the issue: 
 https://bugs.chromium.org/p/chromium/issues/detail?id=1481485. We 
 would appreciate it if you could describe your set-up with more detail 
 in 
 this bug. Have you registered for the deprecation 

Re: [blink-dev] Re: Intent to Ship: Deprecate old CSS custom state syntax

[Chris Harrelson]

Regarding why change to :state() instead of :--: as is typical, it was done
in order to gain consensus; in particular, the CSSWG resolution notes
indicate
 (see
comment from the chair) one motivation is to align with WHATWG and not end
up with a situation where two standards groups have opposing positions in a
gray-area situation and no progress is made.

I don't think that 0.03% is a big problem to deprecate, and recommend we
just make the change to match a hard-won consensus and move on. It's easy
enough to support both syntaxes for some amount of time before removing the
old one.

On Thu, Oct 5, 2023 at 1:49 PM Chris Harrelson 
wrote:

>
>
> On Wed, Oct 4, 2023 at 2:24 PM Jeffrey Yasskin 
> wrote:
>
>> Apparently +Chris Wilson  had part of this discussion
>> with Alan Stearns in April at
>> https://github.com/w3c/csswg-drafts/issues/8730#issuecomment-1524167658,
>> and the suggestion was that if a CSS spec for a feature is "unstable"
>> (meaning 'not at CR'?), then we should either post "we're about to send an
>> intent" to the last issue discussing it, or file an "Is X ready to ship?"
>> issue. I think +Chris Harrelson  is likely to
>> have the strongest opinions about this: should we add such a rule to our
>> launch process for CSS features?
>>
>
> I think we generally shouldn't ship CSS features before there is robust
> discussion and consensus at the CSSWG, and I think Chromium features have
> done a good job at that. The CSSWG resolution mechanism, and the various
> stages of W3C standardization help to build confidence about the degree of
> consensus and commitment, as do signals from other browser vendors. I don't
> think we should additionally require filing an "is X ready to ship?" issue
> at the CSSWG for CSS features.
>
>
>>
>> Jeffrey
>>
>> On Wed, Oct 4, 2023 at 1:15 PM Jeffrey Yasskin 
>> wrote:
>>
>>> On Wed, Oct 4, 2023 at 1:08 PM Joey Arhar  wrote:
>>>
 > I'd like to understand better how we wound up shipping :--foo and
 then having the CSSWG ask us to change it to :state(foo) instead, and what
 we could do in the future to avoid it happening again.

 I think if this was specced before shipping that would have been better
 and is a practice that I (and we?) currently follow, but this was shipped a
 number of years ago.

>>>
>>> Yeah, good point: it's totally possible that our more recent process
>>> rigor is sufficient, and we don't need anything new to prevent this in the
>>> future. No matter what, we should expect the occasional old feature to pop
>>> up and be an exception.
>>>
>>> I do think that it's worth finding a way to write down your current
>>> practice, so that it doesn't regress if you switch teams. I think you mean
>>> that you do "hold off on shipping CSS features until they land in an
>>> official draft", so let's try to record that if it's our idea of the
>>> solution.
>>>
>>>
 > As far as I can see, nobody asked for the ergonomic evidence that
 https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews
 says we can expect after Chrome has shipped a feature.

 This was my bad, I didn't realize or didn't completely consider
 usecounters before I presented the name change to the CSSWG.
 I am hoping that with an answer from the API owners, I can go back to
 the CSSWG and potentially change it back.
 There is still no merged spec in HTML or CSS for this feature yet, but
 I have open PRs in both specs.

>>>
>>> Thanks!
>>>
>>> On Wed, Oct 4, 2023 at 1:00 PM Jeffrey Yasskin 
 wrote:

> +1 on the API owners discussing this.
>
> I'd like to understand better how we wound up shipping :--foo and then
> having the CSSWG ask us to change it to :state(foo) instead, and what we
> could do in the future to avoid it happening again.
>
> It looks like the initial proposal was :state(foo); the CSSWG asked
> to change it to :--foo in 2020
> ;
> we shipped that in M90 in 2021
>  (with a feature
> entry that still says :state ); then Ryosuke suggested undoing that
> change in January 2023
> ,
> and the CSSWG accepted that suggestion in August
> .
> As far as I can see, nobody asked for the ergonomic evidence that
> https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews
> says we can expect after Chrome has shipped a feature. It doesn't seem 
> like
> this feature was so contentious that the team needed to use a name change
> as a bargaining chip, so we should probably have insisted on more evidence
> 

Re: [blink-dev] Re: Intent to Ship: Deprecate old CSS custom state syntax

[Chris Harrelson]

On Wed, Oct 4, 2023 at 2:24 PM Jeffrey Yasskin 
wrote:

> Apparently +Chris Wilson  had part of this discussion
> with Alan Stearns in April at
> https://github.com/w3c/csswg-drafts/issues/8730#issuecomment-1524167658,
> and the suggestion was that if a CSS spec for a feature is "unstable"
> (meaning 'not at CR'?), then we should either post "we're about to send an
> intent" to the last issue discussing it, or file an "Is X ready to ship?"
> issue. I think +Chris Harrelson  is likely to have
> the strongest opinions about this: should we add such a rule to our launch
> process for CSS features?
>

I think we generally shouldn't ship CSS features before there is robust
discussion and consensus at the CSSWG, and I think Chromium features have
done a good job at that. The CSSWG resolution mechanism, and the various
stages of W3C standardization help to build confidence about the degree of
consensus and commitment, as do signals from other browser vendors. I don't
think we should additionally require filing an "is X ready to ship?" issue
at the CSSWG for CSS features.


>
> Jeffrey
>
> On Wed, Oct 4, 2023 at 1:15 PM Jeffrey Yasskin 
> wrote:
>
>> On Wed, Oct 4, 2023 at 1:08 PM Joey Arhar  wrote:
>>
>>> > I'd like to understand better how we wound up shipping :--foo and then
>>> having the CSSWG ask us to change it to :state(foo) instead, and what we
>>> could do in the future to avoid it happening again.
>>>
>>> I think if this was specced before shipping that would have been better
>>> and is a practice that I (and we?) currently follow, but this was shipped a
>>> number of years ago.
>>>
>>
>> Yeah, good point: it's totally possible that our more recent process
>> rigor is sufficient, and we don't need anything new to prevent this in the
>> future. No matter what, we should expect the occasional old feature to pop
>> up and be an exception.
>>
>> I do think that it's worth finding a way to write down your current
>> practice, so that it doesn't regress if you switch teams. I think you mean
>> that you do "hold off on shipping CSS features until they land in an
>> official draft", so let's try to record that if it's our idea of the
>> solution.
>>
>>
>>> > As far as I can see, nobody asked for the ergonomic evidence that
>>> https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews
>>> says we can expect after Chrome has shipped a feature.
>>>
>>> This was my bad, I didn't realize or didn't completely consider
>>> usecounters before I presented the name change to the CSSWG.
>>> I am hoping that with an answer from the API owners, I can go back to
>>> the CSSWG and potentially change it back.
>>> There is still no merged spec in HTML or CSS for this feature yet, but I
>>> have open PRs in both specs.
>>>
>>
>> Thanks!
>>
>> On Wed, Oct 4, 2023 at 1:00 PM Jeffrey Yasskin 
>>> wrote:
>>>
 +1 on the API owners discussing this.

 I'd like to understand better how we wound up shipping :--foo and then
 having the CSSWG ask us to change it to :state(foo) instead, and what we
 could do in the future to avoid it happening again.

 It looks like the initial proposal was :state(foo); the CSSWG asked to
 change it to :--foo in 2020
 ;
 we shipped that in M90 in 2021
  (with a feature
 entry that still says :state ); then Ryosuke suggested undoing that
 change in January 2023
 ,
 and the CSSWG accepted that suggestion in August
 .
 As far as I can see, nobody asked for the ergonomic evidence that
 https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews
 says we can expect after Chrome has shipped a feature. It doesn't seem like
 this feature was so contentious that the team needed to use a name change
 as a bargaining chip, so we should probably have insisted on more evidence
 before agreeing with the change. Maybe that's still a "should" instead of a
 "should have": Joey's second email
 
  might
 say that the CSSWG's resolution
 
 about this isn't as committed as it appears to an external observer?

 Should we generally hold off on shipping CSS features until they land
 in an official draft, or even in a CR? Should we be clearer to the CSSWG
 when we decide to ship ahead of their consensus that the bar for changes is
 going up? There's not good support for this kind of per-WG restriction in
 Chrome Status yet, but maybe it'll fit near
 

Re: [blink-dev] Merging a UseCounter addition

['Daniel Cheng' via blink-dev]

I think what you've done is fine; that being said, I probably would have
just cherry-picked the specific use counter the diff uses, but I don't
think it really makes a difference either way.

Daniel

On Thu, 5 Oct 2023 at 13:25, Donn Denman  wrote:

> Can someone review a merge of new UseCounters in
> https://crrev.com/c/4915881?
>
> I'm merging a CL that adds UseCounters, but my counters are not the next
> sequential values due to other additions that are not being merged. I'm
> thinking it's OK to add those values
> to third_party/blink/public/mojom/use_counter/metrics/web_feature.mojom and
> the associated enums.xml even though they won't be used.
>
> LMK if there's a better list to ask this question on.
>
> --
> 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/CALCERB7%3DDLjqye-_u0g6X4k658f%3D6EHxcWJDTwL_djfFWR_fWQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF3XrKr3JG0G6anib-YvF0dYhWiVRzO0feT842r3r78BxOodag%40mail.gmail.com.

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

[Scott Jehl]

Thanks!!

On Thursday, 5 October 2023 at 16:14:19 UTC-4 Dale Curtis wrote:

> Thanks!
>
> On Thu, Oct 5, 2023 at 12:53 PM Yoav Weiss  wrote:
>
>> LGTM1
>>
>> Thanks for correcting this historical mistake!
>>
>> On Thu, Oct 5, 2023, 21:11 Dale Curtis  wrote:
>>
>>> Contact emailsdalec...@chromium.org
>>>
>>> ExplainerNone
>>>
>>
>> We could almost use MDN as the explainer, other than my comment below.
>>
>>
>>>
>>> Specification
>>> https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource
>>>
>>> Design docs
>>> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source#media
>>>
>>
>> MDN still says the media on is only allowed with a  
>> parent. Could y'all file an issue to get that fixed?
>>
>
> One was already filed here:
> https://github.com/mdn/content/issues/27079
>  
>
>>
>>
>>>
>>> Summary
>>>
>>> Adds support for CSS media queries to  elements used with 
>>>  elements. Allowing developers to use media query syntax to tell the 
>>> browser which source should be preferred for a given environment.
>>>
>>>
>>> Blink componentBlink>Media>Video 
>>> 
>>>
>>> TAG reviewNone
>>>
>>
>> Not required as it's part of the spec and shipped in other 
>> implementations.
>>
>
>>
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Chromium used to support this feature, but it was deprecated and removed 
>>> in https://bugs.chromium.org/p/chromium/issues/detail?id=338197 -- 
>>> foolip@ now believes this removal was incorrect.
>>>
>>>
>>> *Gecko*: Shipped/Shipping (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1836128)
>>>
>>> *WebKit*: Shipped/Shipping (
>>> https://github.com/whatwg/html/issues/6363#issuecomment-1556228111)
>>>
>>> *Web developers*: Positive (12 stars on the issue. Developers are 
>>> passionate enough to implement the feature themselves in Firefox)
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such 
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?Yes
>>>
>>>
>>> https://wpt.fyi/results/html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-source-media-env-change.html?label=master=experimental
>>>  
>>>
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameVideoSourceMediaQuerySupport
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1450316
>>>
>>> Estimated milestones
>>> Shipping on desktop 120
>>> Shipping on Android 120
>>> Shipping on WebView 120
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or 
>>> interop issues. Please list open issues (e.g. links to known github issues 
>>> in the project for the feature specification) whose resolution may 
>>> introduce web compat/interop risk (e.g., changing to naming or structure of 
>>> the API in a non-backward-compatible way).
>>> None
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5144127067127808
>>>
>>> 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/CAPUDrwcJ42qj-ddQQcRi8f-YmfmzbkU-VStxdeM%2By_8u3%3Dh9-Q%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68a539e9-c64e-4b24-9494-9aa35c0f4edan%40chromium.org.

[blink-dev] Merging a UseCounter addition

[Donn Denman]

Can someone review a merge of new UseCounters in https://crrev.com/c/4915881
?

I'm merging a CL that adds UseCounters, but my counters are not the next
sequential values due to other additions that are not being merged. I'm
thinking it's OK to add those values
to third_party/blink/public/mojom/use_counter/metrics/web_feature.mojom and
the associated enums.xml even though they won't be used.

LMK if there's a better list to ask this question on.

-- 
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/CALCERB7%3DDLjqye-_u0g6X4k658f%3D6EHxcWJDTwL_djfFWR_fWQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[Adam Semenenko]

Sorry, I'm not sure what you mean. I only get usability issues related to
this feature in Chrome, which to me indicates it's a Chrome issue

On Fri, 6 Oct 2023, 07:53 K. Moon,  wrote:

> If your complaint is about the URLs (and the resulting behavior), isn't
> that a site authoring issue, not a Chrome issue?
>
> On Thu, Oct 5, 2023, 10:25 AM Adam Semenenko 
> wrote:
>
>> Sorry Thomas, I should have specified that I am using Android. From what
>> I can tell there's no way to disable this anti-feature on Android.
>>
>> Also, while the macOS option removes some distraction, Chrome still
>> pollutes the URL with unnecessary content that's awkward to remove. (I've
>> never wanted to share a URL with this 'jump to text' option.)
>>
>> On Thu, 5 Oct 2023, 20:54 Thomas Steiner,  wrote:
>>
>>> See https://web.dev/text-fragments/#disabling-text-fragments for
>>> disabling the feature.
>>>
>>> On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi 
>>> wrote:
>>>
 Hi Adam,

 > Is it still not possible to disable this distraction yet?

 Chrome used to have an option to disable this feature, but the flag was
 removed. It is possible to remove highlights with extensions. I found 
 "Disable
 Google Search Text Highlights"
 
 on CWS, but never used it. It's open source (GitHub link on store page).
 The source seems fine (albeit I would have written it with declarative
 network rules for efficiency, but very few developers are familiar with
 this API).

 Hope this helps.

 On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko wrote:

> Is it still not possible to disable this distraction yet? I found a
> wonderfully ironic example today - see attached screenshot.
>
> There seem to be only two ways that this feature is used:
>
> 1. The first sentence of a page is highlighted, which is completely
> redundant and patronising. Yes Chrome, thank you for highlighting the very
> first sentence. However could I cope without you.
>
> 2. A random sentence halfway through the page is highlighted. This is
> never what I want: I always want to read the page so that I can understand
> the sentence in context.
>
>
>
> On Wed, 5 May 2021, 06:40 Adam Semenenko, 
> wrote:
>
>> Hi all,
>>
>> Do you know if there's a consistent and easy way to disable this yet?
>> It's really distracting for me. When I google something and click on a
>> result, I like consistent behaviour and to see the whole page from the
>> start. I feel disrupted when I'm randomly dropped into the middle of a 
>> page
>> with a garish colour jumping out at me.
>>
>> Cheers,
>> Adam
>>
>> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hi all,
>>>
>>> It’s been roughly nine months since we first utilized Scroll To Text
>>> Fragment in featured snippets in Google Search. In that time, we’ve seen
>>> that Scroll To Text Fragment links help us towards our goal to get users
>>> the information they need.  In particular:
>>>
>>>1. We find that Scroll To Text Fragment links increase
>>>engagement -- users are less likely to visit a page and then quickly 
>>> hit
>>>the back button, because they can more readily understand how 
>>> relevant the
>>>page is to their search after arriving at the page.
>>>
>>>2. In user surveys, we find that users prefer being scrolled to
>>>the relevant section of a page that’s in a featured snippet. Users 
>>> who were
>>>scrolled to the relevant section preferred the experience at a rate 
>>> of 2:1;
>>>even users who were not scrolled in the control group preferred the 
>>> option
>>>of being scrolled to the relevant section at the same 2:1 rate.
>>>
>>> Besides their usage on Google Search, we’ve noticed scroll to text
>>> fragments links during our crawls of the web.  One of the best use cases
>>> has been wikipedia citations.  For instance, citation 9
>>> 
>>> on this page:
>>> https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds) provides
>>> the detailed attribution to the fastest-ever time at the Melbourne Cup.
>>>
>>> Cheers,
>>> Grant
>>> On Thursday, December 12, 2019 at 12:24:40 PM UTC-8
>>> sligh...@chromium.org wrote:
>>>
 LGTM4


 On Thursday, December 12, 2019 at 12:17:49 PM UTC-8, Daniel Bratell
 wrote:
>
> LGTM3
>
> /Daniel
>
>
> On Thursday, 12 

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[Adam Semenenko]

Thanks for the explanation. But I don't like the scroll to text fragments.
They're annoying, and have never been useful.

There seem to be only two ways that this feature is used:

1. The first sentence of a page is highlighted, which is completely
redundant and patronising. Yes Chrome, thank you for highlighting the very
first sentence. However could I cope without you.

2. A random sentence halfway through the page is highlighted. This is never
what I want: I always want to read the page so that I can understand the
sentence in context.

On Fri, 6 Oct 2023, 08:01 K. Moon,  wrote:

> If the URL doesn't contain a scroll-to-text fragment, then this feature
> doesn't get invoked. The site that serves you the URL is responsible for
> deciding whether or not to include a scroll-to-text fragment.
>
> On Thu, Oct 5, 2023, 11:59 AM Adam Semenenko 
> wrote:
>
>> Sorry, I'm not sure what you mean. I only get usability issues related to
>> this feature in Chrome, which to me indicates it's a Chrome issue
>>
>> On Fri, 6 Oct 2023, 07:53 K. Moon,  wrote:
>>
>>> If your complaint is about the URLs (and the resulting behavior), isn't
>>> that a site authoring issue, not a Chrome issue?
>>>
>>> On Thu, Oct 5, 2023, 10:25 AM Adam Semenenko 
>>> wrote:
>>>
 Sorry Thomas, I should have specified that I am using Android. From
 what I can tell there's no way to disable this anti-feature on Android.

 Also, while the macOS option removes some distraction, Chrome still
 pollutes the URL with unnecessary content that's awkward to remove. (I've
 never wanted to share a URL with this 'jump to text' option.)

 On Thu, 5 Oct 2023, 20:54 Thomas Steiner,  wrote:

> See https://web.dev/text-fragments/#disabling-text-fragments for
> disabling the feature.
>
> On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi <
> bershans...@gmail.com> wrote:
>
>> Hi Adam,
>>
>> > Is it still not possible to disable this distraction yet?
>>
>> Chrome used to have an option to disable this feature, but the flag
>> was removed. It is possible to remove highlights with extensions. I 
>> found "Disable
>> Google Search Text Highlights"
>> 
>> on CWS, but never used it. It's open source (GitHub link on store page).
>> The source seems fine (albeit I would have written it with declarative
>> network rules for efficiency, but very few developers are familiar with
>> this API).
>>
>> Hope this helps.
>>
>> On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko wrote:
>>
>>> Is it still not possible to disable this distraction yet? I found a
>>> wonderfully ironic example today - see attached screenshot.
>>>
>>> There seem to be only two ways that this feature is used:
>>>
>>> 1. The first sentence of a page is highlighted, which is completely
>>> redundant and patronising. Yes Chrome, thank you for highlighting the 
>>> very
>>> first sentence. However could I cope without you.
>>>
>>> 2. A random sentence halfway through the page is highlighted. This
>>> is never what I want: I always want to read the page so that I can
>>> understand the sentence in context.
>>>
>>>
>>>
>>> On Wed, 5 May 2021, 06:40 Adam Semenenko, 
>>> wrote:
>>>
 Hi all,

 Do you know if there's a consistent and easy way to disable this
 yet? It's really distracting for me. When I google something and click 
 on a
 result, I like consistent behaviour and to see the whole page from the
 start. I feel disrupted when I'm randomly dropped into the middle of a 
 page
 with a garish colour jumping out at me.

 Cheers,
 Adam

 On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
 blin...@chromium.org> wrote:

> Hi all,
>
> It’s been roughly nine months since we first utilized Scroll To
> Text Fragment in featured snippets in Google Search. In that time, 
> we’ve
> seen that Scroll To Text Fragment links help us towards our goal to 
> get
> users the information they need.  In particular:
>
>1. We find that Scroll To Text Fragment links increase
>engagement -- users are less likely to visit a page and then 
> quickly hit
>the back button, because they can more readily understand how 
> relevant the
>page is to their search after arriving at the page.
>
>2. In user surveys, we find that users prefer being scrolled
>to the relevant section of a page that’s in a featured snippet. 
> Users who
>were scrolled to the relevant section preferred the experience at 
> a 

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[Adam Semenenko]

The feature can be disabled in Safari
https://www.reddit.com/r/MacOS/comments/14l1gcu/how_to_disable_safari_automatically_highlighting/,
so it's a Chrome specific issue that it can't be disabled

On Fri, 6 Oct 2023, 08:06 K. Moon,  wrote:

> (Incidentally, it appears Safari 16+ also supports this feature, further
> illustrating that this is not a Chrome-specific concern.)
> https://caniuse.com/url-scroll-to-text-fragment
>
> On Thu, Oct 5, 2023, 12:01 PM K. Moon  wrote:
>
>> If the URL doesn't contain a scroll-to-text fragment, then this feature
>> doesn't get invoked. The site that serves you the URL is responsible for
>> deciding whether or not to include a scroll-to-text fragment.
>>
>> On Thu, Oct 5, 2023, 11:59 AM Adam Semenenko 
>> wrote:
>>
>>> Sorry, I'm not sure what you mean. I only get usability issues related
>>> to this feature in Chrome, which to me indicates it's a Chrome issue
>>>
>>> On Fri, 6 Oct 2023, 07:53 K. Moon,  wrote:
>>>
 If your complaint is about the URLs (and the resulting behavior), isn't
 that a site authoring issue, not a Chrome issue?

 On Thu, Oct 5, 2023, 10:25 AM Adam Semenenko 
 wrote:

> Sorry Thomas, I should have specified that I am using Android. From
> what I can tell there's no way to disable this anti-feature on Android.
>
> Also, while the macOS option removes some distraction, Chrome still
> pollutes the URL with unnecessary content that's awkward to remove. (I've
> never wanted to share a URL with this 'jump to text' option.)
>
> On Thu, 5 Oct 2023, 20:54 Thomas Steiner,  wrote:
>
>> See https://web.dev/text-fragments/#disabling-text-fragments for
>> disabling the feature.
>>
>> On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi <
>> bershans...@gmail.com> wrote:
>>
>>> Hi Adam,
>>>
>>> > Is it still not possible to disable this distraction yet?
>>>
>>> Chrome used to have an option to disable this feature, but the flag
>>> was removed. It is possible to remove highlights with extensions. I 
>>> found "Disable
>>> Google Search Text Highlights"
>>> 
>>> on CWS, but never used it. It's open source (GitHub link on store page).
>>> The source seems fine (albeit I would have written it with declarative
>>> network rules for efficiency, but very few developers are familiar with
>>> this API).
>>>
>>> Hope this helps.
>>>
>>> On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko
>>> wrote:
>>>
 Is it still not possible to disable this distraction yet? I found a
 wonderfully ironic example today - see attached screenshot.

 There seem to be only two ways that this feature is used:

 1. The first sentence of a page is highlighted, which is completely
 redundant and patronising. Yes Chrome, thank you for highlighting the 
 very
 first sentence. However could I cope without you.

 2. A random sentence halfway through the page is highlighted. This
 is never what I want: I always want to read the page so that I can
 understand the sentence in context.



 On Wed, 5 May 2021, 06:40 Adam Semenenko, 
 wrote:

> Hi all,
>
> Do you know if there's a consistent and easy way to disable this
> yet? It's really distracting for me. When I google something and 
> click on a
> result, I like consistent behaviour and to see the whole page from the
> start. I feel disrupted when I'm randomly dropped into the middle of 
> a page
> with a garish colour jumping out at me.
>
> Cheers,
> Adam
>
> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Hi all,
>>
>> It’s been roughly nine months since we first utilized Scroll To
>> Text Fragment in featured snippets in Google Search. In that time, 
>> we’ve
>> seen that Scroll To Text Fragment links help us towards our goal to 
>> get
>> users the information they need.  In particular:
>>
>>1. We find that Scroll To Text Fragment links increase
>>engagement -- users are less likely to visit a page and then 
>> quickly hit
>>the back button, because they can more readily understand how 
>> relevant the
>>page is to their search after arriving at the page.
>>
>>2. In user surveys, we find that users prefer being scrolled
>>to the relevant section of a page that’s in a featured snippet. 
>> Users who
>>were scrolled to the relevant section preferred the experience at 
>> a 

[blink-dev] Intent to Ship: WebGPU f16 support

[Ryan Harrison]

+cc cwallez, since he is the WebGPU lead, and can respond authoritatively
if I am OOO

Contact emailsrharri...@chromium.org

ExplainerNone

Specificationhttps://www.w3.org/TR/webgpu/#shader-f16

Summary

Allows for the use of the half-precision floating-point type f16 in WebGPU
shaders (WGSL). Developers can use the 'shader-f16' feature from the WebGPU
spec and the 'f16' extension from the WGSL spec to access 16-bit floating
point variables and APIs in their shaders.


Blink componentInternals>GPU>Dawn


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None


*Gecko*: Positive Mozilla has already implemented this feature.

*WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=254668)

*Web developers*: Positive f16 support in general has been requested
feature in multiple different web runtimes/frameworks, e.g.
https://github.com/microsoft/onnxruntime/issues/9758 and
http://tc39.es/proposal-float16array/ From the initial proposal,
https://github.com/gpuweb/gpuweb/issues/658, there were multiple
benchmarks/demoes that indicate a substantial performance benefit shown in
demos/tests, ~25% if ALU bound, and upto 50% if memory bound. TF.js has
been investigating using f16 in WebGPU,
https://github.com/gpuweb/gpuweb/issues/658#issuecomment-606492757 and
already has it available in the WebGL implementation TF.js has significant
improvements from forcing using Half Float (the GL equivalent feature),
https://github.com/tensorflow/tfjs/issues/1047 The Dawn team has interacted
with multiple internal and external partners that have indicated that f16
support is an important feature for them to get the performance needed to
adopt WebGPU

*Other signals*: Intel has dedicated significant resources to help
implement f16 in Dawn/Tint, and write proper testing coverage in the CTS.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None at the moment, WebGPU currently does not ship on Android WebView.
Parallel work is occuring to launch WebGPU on Android.


Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?No

All platforms will eventually have support. Will immediately be available
on Mac and Chrome OS, since those are platforms already support WebGPU.
Windows support depends on internal changes to use DXC, which are in
progress, so f16 will become availabe once that is finished. Linux and
Android are planned to have WebGPU support in the future, so feature will
become available when WebGPU does.


Is this feature fully tested by web-platform-tests

?No

WebGPU/WGSL have a conformance test suite (https://github.com/gpuweb/cts)
that is regularly pulled into Chromium and part of the testing of Dawn/Tint
in Chromium. Test coverage for execution of f16 operations has been
implemented, https://github.com/gpuweb/cts/issues/1248. Additional testing
is in development.


Flag name on chrome://flagsNone

Finch feature nameWebGPUExposeShader16

Requires code in //chrome?False

Availability expectationFeature is available only in Chromium browsers for
the near future, on the order of months. Other browsers intend to ship
WebGPU and f16 support, but don't have specified timelines.

Adoption expectationFeature is used by specific partner(s) to provide
functionality within 12 months of launch in Chrome.

Adoption planMultiple partners are actively developing products/features
that will use f16 in WebGPU.

Non-OSS dependencies

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

Estimated milestones
Shipping on desktop 120

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None, f16 has been landed in the WebGPU and WGSL specs
https://github.com/gpuweb/gpuweb/pull/2696 (There is some discussion about
whether or not explicit enabling of extensions should be required.
Currently it is, so If this changes existing shaders would be fine because
the desire is to make enabling optional, not removing the mechanism
entirely).

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5180552617656320

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 

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

['Dale Curtis' via blink-dev]

Thanks!

On Thu, Oct 5, 2023 at 12:53 PM Yoav Weiss  wrote:

> LGTM1
>
> Thanks for correcting this historical mistake!
>
> On Thu, Oct 5, 2023, 21:11 Dale Curtis  wrote:
>
>> Contact emailsdalecur...@chromium.org
>>
>> ExplainerNone
>>
>
> We could almost use MDN as the explainer, other than my comment below.
>
>
>>
>> Specification
>> https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource
>>
>> Design docs
>> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source#media
>>
>
> MDN still says the media on is only allowed with a 
> parent. Could y'all file an issue to get that fixed?
>

One was already filed here:
https://github.com/mdn/content/issues/27079


>
>
>>
>> Summary
>>
>> Adds support for CSS media queries to  elements used with 
>> elements. Allowing developers to use media query syntax to tell the browser
>> which source should be preferred for a given environment.
>>
>>
>> Blink componentBlink>Media>Video
>> 
>>
>> TAG reviewNone
>>
>
> Not required as it's part of the spec and shipped in other implementations.
>

>
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Chromium used to support this feature, but it was deprecated and removed
>> in https://bugs.chromium.org/p/chromium/issues/detail?id=338197 --
>> foolip@ now believes this removal was incorrect.
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1836128)
>>
>> *WebKit*: Shipped/Shipping (
>> https://github.com/whatwg/html/issues/6363#issuecomment-1556228111)
>>
>> *Web developers*: Positive (12 stars on the issue. Developers are
>> passionate enough to implement the feature themselves in Firefox)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>>
>> https://wpt.fyi/results/html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-source-media-env-change.html?label=master=experimental
>>
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameVideoSourceMediaQuerySupport
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1450316
>>
>> Estimated milestones
>> Shipping on desktop 120
>> Shipping on Android 120
>> Shipping on WebView 120
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5144127067127808
>>
>> 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/CAPUDrwcJ42qj-ddQQcRi8f-YmfmzbkU-VStxdeM%2By_8u3%3Dh9-Q%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwek%2BBx%2BvZVkWbpOzrG7FenSgneGTh95o%2BmUjz_8U0jsVQ%40mail.gmail.com.

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

[Chris Harrelson]

LGTM2

On Thu, Oct 5, 2023 at 12:53 PM Yoav Weiss  wrote:

> LGTM1
>
> Thanks for correcting this historical mistake!
>
> On Thu, Oct 5, 2023, 21:11 Dale Curtis  wrote:
>
>> Contact emailsdalecur...@chromium.org
>>
>> ExplainerNone
>>
>
> We could almost use MDN as the explainer, other than my comment below.
>
>
>>
>> Specification
>> https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource
>>
>> Design docs
>> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source#media
>>
>
> MDN still says the media on is only allowed with a 
> parent. Could y'all file an issue to get that fixed?
>
>
>>
>> Summary
>>
>> Adds support for CSS media queries to  elements used with 
>> elements. Allowing developers to use media query syntax to tell the browser
>> which source should be preferred for a given environment.
>>
>>
>> Blink componentBlink>Media>Video
>> 
>>
>> TAG reviewNone
>>
>
> Not required as it's part of the spec and shipped in other implementations.
>
>
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Chromium used to support this feature, but it was deprecated and removed
>> in https://bugs.chromium.org/p/chromium/issues/detail?id=338197 --
>> foolip@ now believes this removal was incorrect.
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1836128)
>>
>> *WebKit*: Shipped/Shipping (
>> https://github.com/whatwg/html/issues/6363#issuecomment-1556228111)
>>
>> *Web developers*: Positive (12 stars on the issue. Developers are
>> passionate enough to implement the feature themselves in Firefox)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>>
>> https://wpt.fyi/results/html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-source-media-env-change.html?label=master=experimental
>>
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameVideoSourceMediaQuerySupport
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1450316
>>
>> Estimated milestones
>> Shipping on desktop 120
>> Shipping on Android 120
>> Shipping on WebView 120
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5144127067127808
>>
>> 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/CAPUDrwcJ42qj-ddQQcRi8f-YmfmzbkU-VStxdeM%2By_8u3%3Dh9-Q%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUftmz%3DW0a669TettTi%2BJbpYnrydgMsNYLhaeALa_CUuA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_TMaYo2Mw7y6ABUODAtDj5XxaONsJsK7rvO-dYsN9d3A%40mail.gmail.com.

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

[Yoav Weiss]

LGTM1

Thanks for correcting this historical mistake!

On Thu, Oct 5, 2023, 21:11 Dale Curtis  wrote:

> Contact emailsdalecur...@chromium.org
>
> ExplainerNone
>

We could almost use MDN as the explainer, other than my comment below.


>
> Specification
> https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource
>
> Design docs
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source#media
>

MDN still says the media on is only allowed with a 
parent. Could y'all file an issue to get that fixed?


>
> Summary
>
> Adds support for CSS media queries to  elements used with 
> elements. Allowing developers to use media query syntax to tell the browser
> which source should be preferred for a given environment.
>
>
> Blink componentBlink>Media>Video
> 
>
> TAG reviewNone
>

Not required as it's part of the spec and shipped in other implementations.


>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Chromium used to support this feature, but it was deprecated and removed
> in https://bugs.chromium.org/p/chromium/issues/detail?id=338197 -- foolip@
> now believes this removal was incorrect.
>
>
> *Gecko*: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1836128)
>
> *WebKit*: Shipped/Shipping (
> https://github.com/whatwg/html/issues/6363#issuecomment-1556228111)
>
> *Web developers*: Positive (12 stars on the issue. Developers are
> passionate enough to implement the feature themselves in Firefox)
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-source-media-env-change.html?label=master=experimental
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameVideoSourceMediaQuerySupport
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1450316
>
> Estimated milestones
> Shipping on desktop 120
> Shipping on Android 120
> Shipping on WebView 120
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5144127067127808
>
> 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/CAPUDrwcJ42qj-ddQQcRi8f-YmfmzbkU-VStxdeM%2By_8u3%3Dh9-Q%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUftmz%3DW0a669TettTi%2BJbpYnrydgMsNYLhaeALa_CUuA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[K. Moon]

You haven't said where your scroll-to-text links are coming from, but I
assume it's a search engine, which is the most common case. If you don't
like the quality of the links, the proper place to address your complaint
is to that search engine.

As this feature has shipped (it appears all the way back in M80),
complaining on this thread isn't going to accomplish anything. If you want
the spec to change, there are other forums for that. If you want Chrome's
behavior to change, you should file a feature request (or ideally, find an
existing one).

On Thu, Oct 5, 2023, 12:10 PM Adam Semenenko 
wrote:

> The feature can be disabled in Safari
> https://www.reddit.com/r/MacOS/comments/14l1gcu/how_to_disable_safari_automatically_highlighting/,
> so it's a Chrome specific issue that it can't be disabled
>
> On Fri, 6 Oct 2023, 08:06 K. Moon,  wrote:
>
>> (Incidentally, it appears Safari 16+ also supports this feature, further
>> illustrating that this is not a Chrome-specific concern.)
>> https://caniuse.com/url-scroll-to-text-fragment
>>
>> On Thu, Oct 5, 2023, 12:01 PM K. Moon  wrote:
>>
>>> If the URL doesn't contain a scroll-to-text fragment, then this feature
>>> doesn't get invoked. The site that serves you the URL is responsible for
>>> deciding whether or not to include a scroll-to-text fragment.
>>>
>>> On Thu, Oct 5, 2023, 11:59 AM Adam Semenenko 
>>> wrote:
>>>
 Sorry, I'm not sure what you mean. I only get usability issues related
 to this feature in Chrome, which to me indicates it's a Chrome issue

 On Fri, 6 Oct 2023, 07:53 K. Moon,  wrote:

> If your complaint is about the URLs (and the resulting behavior),
> isn't that a site authoring issue, not a Chrome issue?
>
> On Thu, Oct 5, 2023, 10:25 AM Adam Semenenko 
> wrote:
>
>> Sorry Thomas, I should have specified that I am using Android. From
>> what I can tell there's no way to disable this anti-feature on Android.
>>
>> Also, while the macOS option removes some distraction, Chrome still
>> pollutes the URL with unnecessary content that's awkward to remove. (I've
>> never wanted to share a URL with this 'jump to text' option.)
>>
>> On Thu, 5 Oct 2023, 20:54 Thomas Steiner,  wrote:
>>
>>> See https://web.dev/text-fragments/#disabling-text-fragments for
>>> disabling the feature.
>>>
>>> On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi <
>>> bershans...@gmail.com> wrote:
>>>
 Hi Adam,

 > Is it still not possible to disable this distraction yet?

 Chrome used to have an option to disable this feature, but the flag
 was removed. It is possible to remove highlights with extensions. I 
 found "Disable
 Google Search Text Highlights"
 
 on CWS, but never used it. It's open source (GitHub link on store 
 page).
 The source seems fine (albeit I would have written it with declarative
 network rules for efficiency, but very few developers are familiar with
 this API).

 Hope this helps.

 On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko
 wrote:

> Is it still not possible to disable this distraction yet? I found
> a wonderfully ironic example today - see attached screenshot.
>
> There seem to be only two ways that this feature is used:
>
> 1. The first sentence of a page is highlighted, which is
> completely redundant and patronising. Yes Chrome, thank you for
> highlighting the very first sentence. However could I cope without 
> you.
>
> 2. A random sentence halfway through the page is highlighted. This
> is never what I want: I always want to read the page so that I can
> understand the sentence in context.
>
>
>
> On Wed, 5 May 2021, 06:40 Adam Semenenko, 
> wrote:
>
>> Hi all,
>>
>> Do you know if there's a consistent and easy way to disable this
>> yet? It's really distracting for me. When I google something and 
>> click on a
>> result, I like consistent behaviour and to see the whole page from 
>> the
>> start. I feel disrupted when I'm randomly dropped into the middle of 
>> a page
>> with a garish colour jumping out at me.
>>
>> Cheers,
>> Adam
>>
>> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hi all,
>>>
>>> It’s been roughly nine months since we first utilized Scroll To
>>> Text Fragment in featured snippets in Google Search. In that time, 
>>> we’ve
>>> seen that Scroll To Text Fragment 

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

['Kyra Seevers' via blink-dev]

Hi Illia,

Thanks for reaching out - does this bug answer any of your questions?:
https://bugs.chromium.org/p/chromium/issues/detail?id=1481485=reporter%3Ame=1

If not, could you please file a bug describing your set-up here:
https://bugs.chromium.org/p/chromium/issues/entry, and add the label
"Proj-StoragePartitioningTrial" and cc kyraseev...@chromium.org?

In the bug, please include information about your extension set-up - does
the extension have host permissions for each of the websites? Is it
Manifest v2 or v3?

Thanks,
Kyra

On Wed, Oct 4, 2023 at 8:19 AM Illia Kyselov  wrote:

> Hi all,
>
> I hope this message finds you in good health. I am reaching out to seek
> your expertise in helping me solve a problem.
>
> Our app incorporates an extension that aids users in accruing information
> from diverse sites, a feature that is instrumental in social network and
> business development, among other applications. A crucial aspect of this
> function is the user's ability to open the extension and add contacts
> without the need to log in in our app in extension at each individual
> website (as login information is stored in Local Storage).
>
> From my understanding, we cannot use the option
> DisableThirdPartyStoragePartitioning because our extension has to work
> across all websites.
>
> This leads me to question if there is no immediate solution to this
> problem. Does this imply we need to contemplate workarounds, potentially
> affecting the user experience of our app?
>
> I eagerly await your advice on this matter. Your assistance and
> contribution are greatly appreciated. Thank you for your continued support.
>
> Best regards.
>
> On Thursday, September 28, 2023 at 5:01:12 PM UTC+3 Kyra Seevers wrote:
>
>> Hi all,
>>
>> Quick update: the ThirdPartyStoragePartitioning feature flag is now
>> enabled by default in Canary. We will be rolling out to 100% Stable shortly.
>>
>> Manish - could you please file a bug describing your set-up here:
>> https://bugs.chromium.org/p/chromium/issues/entry, and add the label
>> "Proj-StoragePartitioningTrial". Also, have you looked into our deprecation
>> trial in the meantime?:
>> https://developer.chrome.com/en/blog/storage-partitioning-deprecation-trial/
>> .
>>
>> Thanks all,
>> Kyra
>>
>> On Tue, Sep 26, 2023 at 11:56 AM Manish Bisht 
>> wrote:
>>
>>> Hi,
>>>
>>> Is this enabled by default to chrome dev without the use or feature flag
>>> ?
>>>
>>> Also is there any example of host_permissions that is mentioned here
>>> 
>>>  because
>>> I don't think this is working with the chrome flag enabled.
>>>
>>> Thanks,
>>>
>>> On Monday, September 25, 2023 at 6:57:16 PM UTC+5:30 Kyra Seevers wrote:
>>>
 Hi all,

 Wanted to keep the thread updated and confirm that we have not shipped
 to Stable 100% yet. We will be delaying another day or two due to
 internal delays.

 Thanks,
 Kyra

 On Wed, Sep 20, 2023 at 8:53 AM Kyra Seevers 
 wrote:

> Hi Chinmay,
>
> Thanks for reaching out! Due to internal delays, we won't be rolling
> out to Stable 100% likely until the end of the week or the beginning of
> next week. I'll keep the thread updated with any further delays.
>
> Thanks,
> Kyra
>
> On Tue, Sep 19, 2023 at 7:50 PM Chinmay Manchanda 
> wrote:
>
>> Hi Kyra,
>>
>> Do we have an update on what time the feature will be rolled out
>> today?
>>
>> Cheers,
>> Chinmay
>>
>> On Tuesday, 12 September 2023 at 18:06:57 UTC+10 Kyra Seevers wrote:
>>
>>> Hi Muhammad,
>>>
>>> I have filed this bug for the issue:
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1481485. We
>>> would appreciate it if you could describe your set-up with more detail 
>>> in
>>> this bug. Have you registered for the deprecation trial described here?:
>>> https://developer.chrome.com/en/blog/storage-partitioning-deprecation-trial/
>>>
>>> Thanks,
>>> Kyra
>>>
>>> On Mon, Sep 11, 2023 at 10:48 PM Muhammad Ahmed Mallick <
>>> amal...@folio3.com> wrote:
>>>
 Hi All,
 I'm also facing challenges with the current situation. We're
 loading my own website within the Chrome extension, and we manage the
 user's login state (tokens) on my website. The extension's iframe is
 supposed to retrieve the token from local storage, but it's currently
 broken. It's not feasible to ask the user to log in twice just to 
 access
 the extension's content.

 Please let me know if there is any solution to get it fixed asap.

 Thanks
 Ahmed

 On Wednesday, September 6, 2023 at 2:03:55 PM UTC+5 Kyra Seevers
 wrote:

> Hi all,
>
> Another quick update: we began the rollout to 50% stable 

[blink-dev] Intent to implement and ship: Media query support for video elements

[Dale Curtis]

Contact emailsdalecur...@chromium.org

ExplainerNone

Specification
https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource

Design docs
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source#media

Summary

Adds support for CSS media queries to  elements used with 
elements. Allowing developers to use media query syntax to tell the browser
which source should be preferred for a given environment.


Blink componentBlink>Media>Video


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Chromium used to support this feature, but it was deprecated and removed in
https://bugs.chromium.org/p/chromium/issues/detail?id=338197 -- foolip@ now
believes this removal was incorrect.


*Gecko*: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1836128)

*WebKit*: Shipped/Shipping (
https://github.com/whatwg/html/issues/6363#issuecomment-1556228111)

*Web developers*: Positive (12 stars on the issue. Developers are
passionate enough to implement the feature themselves in Firefox)

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-source-media-env-change.html?label=master=experimental


Flag name on chrome://flagsNone

Finch feature nameVideoSourceMediaQuerySupport

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1450316

Estimated milestones
Shipping on desktop 120
Shipping on Android 120
Shipping on WebView 120

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5144127067127808

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/CAPUDrwcJ42qj-ddQQcRi8f-YmfmzbkU-VStxdeM%2By_8u3%3Dh9-Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[K. Moon]

(Incidentally, it appears Safari 16+ also supports this feature, further
illustrating that this is not a Chrome-specific concern.)
https://caniuse.com/url-scroll-to-text-fragment

On Thu, Oct 5, 2023, 12:01 PM K. Moon  wrote:

> If the URL doesn't contain a scroll-to-text fragment, then this feature
> doesn't get invoked. The site that serves you the URL is responsible for
> deciding whether or not to include a scroll-to-text fragment.
>
> On Thu, Oct 5, 2023, 11:59 AM Adam Semenenko 
> wrote:
>
>> Sorry, I'm not sure what you mean. I only get usability issues related to
>> this feature in Chrome, which to me indicates it's a Chrome issue
>>
>> On Fri, 6 Oct 2023, 07:53 K. Moon,  wrote:
>>
>>> If your complaint is about the URLs (and the resulting behavior), isn't
>>> that a site authoring issue, not a Chrome issue?
>>>
>>> On Thu, Oct 5, 2023, 10:25 AM Adam Semenenko 
>>> wrote:
>>>
 Sorry Thomas, I should have specified that I am using Android. From
 what I can tell there's no way to disable this anti-feature on Android.

 Also, while the macOS option removes some distraction, Chrome still
 pollutes the URL with unnecessary content that's awkward to remove. (I've
 never wanted to share a URL with this 'jump to text' option.)

 On Thu, 5 Oct 2023, 20:54 Thomas Steiner,  wrote:

> See https://web.dev/text-fragments/#disabling-text-fragments for
> disabling the feature.
>
> On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi <
> bershans...@gmail.com> wrote:
>
>> Hi Adam,
>>
>> > Is it still not possible to disable this distraction yet?
>>
>> Chrome used to have an option to disable this feature, but the flag
>> was removed. It is possible to remove highlights with extensions. I 
>> found "Disable
>> Google Search Text Highlights"
>> 
>> on CWS, but never used it. It's open source (GitHub link on store page).
>> The source seems fine (albeit I would have written it with declarative
>> network rules for efficiency, but very few developers are familiar with
>> this API).
>>
>> Hope this helps.
>>
>> On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko wrote:
>>
>>> Is it still not possible to disable this distraction yet? I found a
>>> wonderfully ironic example today - see attached screenshot.
>>>
>>> There seem to be only two ways that this feature is used:
>>>
>>> 1. The first sentence of a page is highlighted, which is completely
>>> redundant and patronising. Yes Chrome, thank you for highlighting the 
>>> very
>>> first sentence. However could I cope without you.
>>>
>>> 2. A random sentence halfway through the page is highlighted. This
>>> is never what I want: I always want to read the page so that I can
>>> understand the sentence in context.
>>>
>>>
>>>
>>> On Wed, 5 May 2021, 06:40 Adam Semenenko, 
>>> wrote:
>>>
 Hi all,

 Do you know if there's a consistent and easy way to disable this
 yet? It's really distracting for me. When I google something and click 
 on a
 result, I like consistent behaviour and to see the whole page from the
 start. I feel disrupted when I'm randomly dropped into the middle of a 
 page
 with a garish colour jumping out at me.

 Cheers,
 Adam

 On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
 blin...@chromium.org> wrote:

> Hi all,
>
> It’s been roughly nine months since we first utilized Scroll To
> Text Fragment in featured snippets in Google Search. In that time, 
> we’ve
> seen that Scroll To Text Fragment links help us towards our goal to 
> get
> users the information they need.  In particular:
>
>1. We find that Scroll To Text Fragment links increase
>engagement -- users are less likely to visit a page and then 
> quickly hit
>the back button, because they can more readily understand how 
> relevant the
>page is to their search after arriving at the page.
>
>2. In user surveys, we find that users prefer being scrolled
>to the relevant section of a page that’s in a featured snippet. 
> Users who
>were scrolled to the relevant section preferred the experience at 
> a rate of
>2:1; even users who were not scrolled in the control group 
> preferred the
>option of being scrolled to the relevant section at the same 2:1 
> rate.
>
> Besides their usage on Google Search, we’ve noticed scroll to text
> fragments links during our crawls of the web.  One of the best use 

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[K. Moon]

If the URL doesn't contain a scroll-to-text fragment, then this feature
doesn't get invoked. The site that serves you the URL is responsible for
deciding whether or not to include a scroll-to-text fragment.

On Thu, Oct 5, 2023, 11:59 AM Adam Semenenko 
wrote:

> Sorry, I'm not sure what you mean. I only get usability issues related to
> this feature in Chrome, which to me indicates it's a Chrome issue
>
> On Fri, 6 Oct 2023, 07:53 K. Moon,  wrote:
>
>> If your complaint is about the URLs (and the resulting behavior), isn't
>> that a site authoring issue, not a Chrome issue?
>>
>> On Thu, Oct 5, 2023, 10:25 AM Adam Semenenko 
>> wrote:
>>
>>> Sorry Thomas, I should have specified that I am using Android. From what
>>> I can tell there's no way to disable this anti-feature on Android.
>>>
>>> Also, while the macOS option removes some distraction, Chrome still
>>> pollutes the URL with unnecessary content that's awkward to remove. (I've
>>> never wanted to share a URL with this 'jump to text' option.)
>>>
>>> On Thu, 5 Oct 2023, 20:54 Thomas Steiner,  wrote:
>>>
 See https://web.dev/text-fragments/#disabling-text-fragments for
 disabling the feature.

 On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi 
 wrote:

> Hi Adam,
>
> > Is it still not possible to disable this distraction yet?
>
> Chrome used to have an option to disable this feature, but the flag
> was removed. It is possible to remove highlights with extensions. I found 
> "Disable
> Google Search Text Highlights"
> 
> on CWS, but never used it. It's open source (GitHub link on store page).
> The source seems fine (albeit I would have written it with declarative
> network rules for efficiency, but very few developers are familiar with
> this API).
>
> Hope this helps.
>
> On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko wrote:
>
>> Is it still not possible to disable this distraction yet? I found a
>> wonderfully ironic example today - see attached screenshot.
>>
>> There seem to be only two ways that this feature is used:
>>
>> 1. The first sentence of a page is highlighted, which is completely
>> redundant and patronising. Yes Chrome, thank you for highlighting the 
>> very
>> first sentence. However could I cope without you.
>>
>> 2. A random sentence halfway through the page is highlighted. This is
>> never what I want: I always want to read the page so that I can 
>> understand
>> the sentence in context.
>>
>>
>>
>> On Wed, 5 May 2021, 06:40 Adam Semenenko, 
>> wrote:
>>
>>> Hi all,
>>>
>>> Do you know if there's a consistent and easy way to disable this
>>> yet? It's really distracting for me. When I google something and click 
>>> on a
>>> result, I like consistent behaviour and to see the whole page from the
>>> start. I feel disrupted when I'm randomly dropped into the middle of a 
>>> page
>>> with a garish colour jumping out at me.
>>>
>>> Cheers,
>>> Adam
>>>
>>> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Hi all,

 It’s been roughly nine months since we first utilized Scroll To
 Text Fragment in featured snippets in Google Search. In that time, 
 we’ve
 seen that Scroll To Text Fragment links help us towards our goal to get
 users the information they need.  In particular:

1. We find that Scroll To Text Fragment links increase
engagement -- users are less likely to visit a page and then 
 quickly hit
the back button, because they can more readily understand how 
 relevant the
page is to their search after arriving at the page.

2. In user surveys, we find that users prefer being scrolled to
the relevant section of a page that’s in a featured snippet. Users 
 who were
scrolled to the relevant section preferred the experience at a rate 
 of 2:1;
even users who were not scrolled in the control group preferred the 
 option
of being scrolled to the relevant section at the same 2:1 rate.

 Besides their usage on Google Search, we’ve noticed scroll to text
 fragments links during our crawls of the web.  One of the best use 
 cases
 has been wikipedia citations.  For instance, citation 9
 
 on this page:
 https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds) provides
 the detailed 

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[K. Moon]

If your complaint is about the URLs (and the resulting behavior), isn't
that a site authoring issue, not a Chrome issue?

On Thu, Oct 5, 2023, 10:25 AM Adam Semenenko 
wrote:

> Sorry Thomas, I should have specified that I am using Android. From what I
> can tell there's no way to disable this anti-feature on Android.
>
> Also, while the macOS option removes some distraction, Chrome still
> pollutes the URL with unnecessary content that's awkward to remove. (I've
> never wanted to share a URL with this 'jump to text' option.)
>
> On Thu, 5 Oct 2023, 20:54 Thomas Steiner,  wrote:
>
>> See https://web.dev/text-fragments/#disabling-text-fragments for
>> disabling the feature.
>>
>> On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi 
>> wrote:
>>
>>> Hi Adam,
>>>
>>> > Is it still not possible to disable this distraction yet?
>>>
>>> Chrome used to have an option to disable this feature, but the flag was
>>> removed. It is possible to remove highlights with extensions. I found 
>>> "Disable
>>> Google Search Text Highlights"
>>> 
>>> on CWS, but never used it. It's open source (GitHub link on store page).
>>> The source seems fine (albeit I would have written it with declarative
>>> network rules for efficiency, but very few developers are familiar with
>>> this API).
>>>
>>> Hope this helps.
>>>
>>> On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko wrote:
>>>
 Is it still not possible to disable this distraction yet? I found a
 wonderfully ironic example today - see attached screenshot.

 There seem to be only two ways that this feature is used:

 1. The first sentence of a page is highlighted, which is completely
 redundant and patronising. Yes Chrome, thank you for highlighting the very
 first sentence. However could I cope without you.

 2. A random sentence halfway through the page is highlighted. This is
 never what I want: I always want to read the page so that I can understand
 the sentence in context.



 On Wed, 5 May 2021, 06:40 Adam Semenenko,  wrote:

> Hi all,
>
> Do you know if there's a consistent and easy way to disable this yet?
> It's really distracting for me. When I google something and click on a
> result, I like consistent behaviour and to see the whole page from the
> start. I feel disrupted when I'm randomly dropped into the middle of a 
> page
> with a garish colour jumping out at me.
>
> Cheers,
> Adam
>
> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Hi all,
>>
>> It’s been roughly nine months since we first utilized Scroll To Text
>> Fragment in featured snippets in Google Search. In that time, we’ve seen
>> that Scroll To Text Fragment links help us towards our goal to get users
>> the information they need.  In particular:
>>
>>1. We find that Scroll To Text Fragment links increase engagement
>>-- users are less likely to visit a page and then quickly hit the back
>>button, because they can more readily understand how relevant the 
>> page is
>>to their search after arriving at the page.
>>
>>2. In user surveys, we find that users prefer being scrolled to
>>the relevant section of a page that’s in a featured snippet. Users 
>> who were
>>scrolled to the relevant section preferred the experience at a rate 
>> of 2:1;
>>even users who were not scrolled in the control group preferred the 
>> option
>>of being scrolled to the relevant section at the same 2:1 rate.
>>
>> Besides their usage on Google Search, we’ve noticed scroll to text
>> fragments links during our crawls of the web.  One of the best use cases
>> has been wikipedia citations.  For instance, citation 9
>> 
>> on this page:
>> https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds) provides
>> the detailed attribution to the fastest-ever time at the Melbourne Cup.
>>
>> Cheers,
>> Grant
>> On Thursday, December 12, 2019 at 12:24:40 PM UTC-8
>> sligh...@chromium.org wrote:
>>
>>> LGTM4
>>>
>>>
>>> On Thursday, December 12, 2019 at 12:17:49 PM UTC-8, Daniel Bratell
>>> wrote:

 LGTM3

 /Daniel


 On Thursday, 12 December 2019 19:45:38 UTC+1, Chris Harrelson wrote:
>
> LGTM2
>
> On Wed, Dec 11, 2019 at 10:27 PM Yoav Weiss  wrote:
>
>> LGTM1
>>
>>
>> On Wed, Dec 11, 2019, 22:03 Nick Burris 
>> wrote:
>>
>>> Hi all,
>>>

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[Adam Semenenko]

Sorry Thomas, I should have specified that I am using Android. From what I
can tell there's no way to disable this anti-feature on Android.

Also, while the macOS option removes some distraction, Chrome still
pollutes the URL with unnecessary content that's awkward to remove. (I've
never wanted to share a URL with this 'jump to text' option.)

On Thu, 5 Oct 2023, 20:54 Thomas Steiner,  wrote:

> See https://web.dev/text-fragments/#disabling-text-fragments for
> disabling the feature.
>
> On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi 
> wrote:
>
>> Hi Adam,
>>
>> > Is it still not possible to disable this distraction yet?
>>
>> Chrome used to have an option to disable this feature, but the flag was
>> removed. It is possible to remove highlights with extensions. I found 
>> "Disable
>> Google Search Text Highlights"
>> 
>> on CWS, but never used it. It's open source (GitHub link on store page).
>> The source seems fine (albeit I would have written it with declarative
>> network rules for efficiency, but very few developers are familiar with
>> this API).
>>
>> Hope this helps.
>>
>> On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko wrote:
>>
>>> Is it still not possible to disable this distraction yet? I found a
>>> wonderfully ironic example today - see attached screenshot.
>>>
>>> There seem to be only two ways that this feature is used:
>>>
>>> 1. The first sentence of a page is highlighted, which is completely
>>> redundant and patronising. Yes Chrome, thank you for highlighting the very
>>> first sentence. However could I cope without you.
>>>
>>> 2. A random sentence halfway through the page is highlighted. This is
>>> never what I want: I always want to read the page so that I can understand
>>> the sentence in context.
>>>
>>>
>>>
>>> On Wed, 5 May 2021, 06:40 Adam Semenenko,  wrote:
>>>
 Hi all,

 Do you know if there's a consistent and easy way to disable this yet?
 It's really distracting for me. When I google something and click on a
 result, I like consistent behaviour and to see the whole page from the
 start. I feel disrupted when I'm randomly dropped into the middle of a page
 with a garish colour jumping out at me.

 Cheers,
 Adam

 On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
 blin...@chromium.org> wrote:

> Hi all,
>
> It’s been roughly nine months since we first utilized Scroll To Text
> Fragment in featured snippets in Google Search. In that time, we’ve seen
> that Scroll To Text Fragment links help us towards our goal to get users
> the information they need.  In particular:
>
>1. We find that Scroll To Text Fragment links increase engagement
>-- users are less likely to visit a page and then quickly hit the back
>button, because they can more readily understand how relevant the page 
> is
>to their search after arriving at the page.
>
>2. In user surveys, we find that users prefer being scrolled to
>the relevant section of a page that’s in a featured snippet. Users who 
> were
>scrolled to the relevant section preferred the experience at a rate of 
> 2:1;
>even users who were not scrolled in the control group preferred the 
> option
>of being scrolled to the relevant section at the same 2:1 rate.
>
> Besides their usage on Google Search, we’ve noticed scroll to text
> fragments links during our crawls of the web.  One of the best use cases
> has been wikipedia citations.  For instance, citation 9
> 
> on this page: https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds)
> provides the detailed attribution to the fastest-ever time at the 
> Melbourne
> Cup.
>
> Cheers,
> Grant
> On Thursday, December 12, 2019 at 12:24:40 PM UTC-8
> sligh...@chromium.org wrote:
>
>> LGTM4
>>
>>
>> On Thursday, December 12, 2019 at 12:17:49 PM UTC-8, Daniel Bratell
>> wrote:
>>>
>>> LGTM3
>>>
>>> /Daniel
>>>
>>>
>>> On Thursday, 12 December 2019 19:45:38 UTC+1, Chris Harrelson wrote:

 LGTM2

 On Wed, Dec 11, 2019 at 10:27 PM Yoav Weiss  wrote:

> LGTM1
>
>
> On Wed, Dec 11, 2019, 22:03 Nick Burris 
> wrote:
>
>> Hi all,
>>
>> We feel that we're now in good shape for shipping. We have
>> addressed all of the shipping blockers that I listed in my previous 
>> email,
>> and the corresponding implementation changes have landed in Chrome. 
>> We're
>> still continuing to make improvements 

Re: [blink-dev] Intent to Experiment: Open popups as fullscreen windows

['Ajay Rahatekar' via blink-dev]

Hi All, 

We have secured Privacy, Security and Debuggability approvals in 
chromestatus for the Origin Trial.

On Wednesday, October 4, 2023 at 12:19:30 PM UTC-7 Ajay Rahatekar wrote:

> Thank you Yoav, for your comments. We have requested Privacy and Security 
> reviews in chromestatus. The Security/Privacy questionnaire is available at 
> https://github.com/w3c/window-management/blob/main/security_and_privacy_fullscreen_popups.md
> .
>
> The Privacy and Security review for this feature was started before the 
> Privacy/Security gates were required in chromestatus and so reviews were 
> conducted using internal process. 
> https://launch.corp.google.com/launch/4263088 (Sorry, internal only) .
>
>
> On Wednesday, October 4, 2023 at 3:43:12 AM UTC-7 yoav...@chromium.org 
> wrote:
>
>> Personally, I'd love to see the Privacy and Security boxes in 
>> chromestatus turn to green before approving this, as this seems like a 
>> potentially risky feature.
>> Bonus point for pointers to public notes from that review :)
>>
>> On Wednesday, October 4, 2023 at 6:25:58 AM UTC+2 ajayra...@google.com 
>> wrote:
>>
>>> Hi API Owners,
>>>
>>> Please let us know if you have any other questions or comments. The 
>>> Origin Trial is planned for M119 shipping to Stable on Tue, Oct 31, 2023.
>>>
>>> Thanks in advance.
>>>
>>> -Ajay
>>>
>>> On Thursday, September 28, 2023 at 3:30:56 PM UTC-7 btr...@chromium.org 
>>> wrote:
>>>
 Avi: That's right, window-management permission must be granted for 
 this feature to work (and appropriate permission policies). If not, the 
 behavior falls back to opening the popup normally.

 Eric: We share your concerns. Besides the permission requirement, 
 existing user security mitigations prohibit popups (fullscreen or 
 otherwise) showing over existing HTML Fullscreen windows. Chromium-based 
 browsers exit HTML Fullscreen when a popup window from the opener chain is 
 opened or moved onto the same display. Attackers gain little advantage 
 using this HTML Fullscreen API entrypoint over the classic 
 Element.requestFullscreen().


 Regards,
 Brad

 On Thu, Sep 28, 2023 at 1:14 PM Avi Drissman  wrote:

>>> As a clarification, would this be behind and gated by the Window 
> Management permission? The URLs of the spec imply that but I wanted to be 
> sure.
>
> Avi
>
> On Tue, Sep 26, 2023 at 4:16 PM Brad Triebwasser  
> wrote:
>
 Contact emails
>>
>> btr...@chromium.org, m...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/w3c/window-management/blob/main/EXPLAINER_fullscreen_popups.md
>>
>> Specification
>>
>>
>> https://github.com/w3c/window-management/blob/main/EXPLAINER_fullscreen_popups.md#spec-changes
>>
>> Design docs
>>
>>
>> https://github.com/w3c/window-management/blob/main/security_and_privacy_fullscreen_popups.md
>>
>> Summary
>>
>> Adds the ability to open a popup directly to fullscreen. 
>>
>> Adds a `fullscreen` option to the `windowFeatures` parameter to the 
>> `window.open()` JavaScript API, which allows the caller to open a popup 
>> directly to full-screen on the display that would contain the popup 
>> (based 
>> on `screenX`/`screenY`). This eliminates the need for the developer to 
>> manually transition a popup into fullscreen, which could require a 
>> separate 
>> user activation signal.
>>
>> Blink component
>>
>> Blink>Fullscreen 
>> ,
>>  
>> Blink>WindowDialog 
>> ,
>>  
>> Blink>Screen>MultiScreen 
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/840
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/714)
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/101)
>>
>> Web developers: Positive 
>> https://github.com/w3c/window-placement/issues/7 
>> https://github.com/w3c/window-placement/issues/98 
>> https://github.com/w3c/window-placement/issues/92
>>
>> Other signals:
>>
>> WebView application risks
>>
>> This feature is not supported on WebView, attempted usage will fall 
>> back to existing behavior.
>>
>> Goals for experimentation
>>
>> Gather feedback from early adopters on the API shape, ease of 
>> integration, edge cases that may require attention. Iterate on potential 
>> UX 
>> improvements related to 

[blink-dev] Re: Unstanding StyleSheet

[uazo]

I'll join the request, if possible and if I am not in the way, it's 
something I'm also interested in.

>  I am trying to find one point in code from where I can pick final style 
for any node.

As far as I understood from reading the code, the correct point should be 
StyleAdjuster::AdjustComputedStyle.

if I may, I would also like to understand the difference between 
GetComputedStyle() and GetLayoutObject()->Style().

Thanks

On Wednesday, October 4, 2023 at 5:28:00 PM UTC+2 kalyani Shinde wrote:

> Hi Team,
>
> I am new to blink and I want to understand how and when css computation is 
> done for every node and how to serialize that computed values. By 
> computation I mean, after applying all possible rules apply to that 
> node(own style, external style, insert rule, parent style, Pseudo element 
> styles, Css Pseudo Elements etc).
>
>
> I am trying to find one point in code from where I can pick final style 
> for any node. also want to capture the updates of style for that node may 
> be from same point in code or different. 
>
> And if there is no single point from where I can get it, then can I have 
> one point(class) from where I get all css_rules as vector for any document 
> (Initial after parsing and all updates through various ways like 
> insertRule, innerHtml change for style node etc)
>
> Things I have already referred are as follows but couldn't identify 
> linking after FrameLoader::FinishedParsing().
>
> document.h - Chromium Code Search 
> 
>
> css_style_sheet.h - Chromium Code Search 
> 
>
> style_sheet_contents.h - Chromium Code Search 
> 
>
> Thanks in advance.
>
>

-- 
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/963eb653-c389-4cd1-a95a-3c1169e929ben%40chromium.org.

Re: [blink-dev] Intent to Ship: Document picture-in-picture

[Mariano M]

Oh!! You're right, i no longer need the Chrome flag. So awesome! Good job 
on this feature, love it!
On Thursday, October 5, 2023 at 4:18:09 AM UTC-3 François Beaufort wrote:

> This API shipped in Chrome 116. See 
> https://developer.chrome.com/docs/web-platform/document-picture-in-picture/
>
>
> On Thu, Oct 5, 2023 at 1:26 AM Mariano M  wrote:
>
>> Hey, is there any official release date for the new PiP window without 
>> having to have the chrome flag enabled? Thanks!
>>
>> On Wednesday, June 14, 2023 at 12:47:58 PM UTC-3 Mike Taylor wrote:
>>
>>> LGTM3
>>> On 6/14/23 11:47 AM, slightlyoff via Chromestatus wrote:
>>>
>>> LGTM2
>>>
>>> -- 
>>> 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/d6062405fe18ddcb%40google.com
>>>  
>>> 
>>> .
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to blink-dev+...@chromium.org.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/91d4591b-052b-42e9-8925-06a0d211e869n%40chromium.org
>>  
>> 
>> .
>>
>

-- 
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/e83a5976-48c6-447a-8b04-177846e73b2fn%40chromium.org.

[blink-dev] Re: Intent to Ship: Deprecate old CSS custom state syntax

['Chris Wilson' via blink-dev]

Oh yes, I recall this now.  :) IIRC, we generally follow this convention
anyway; that feature had some communication gaps, but we did follow that
convention.

On Wed, Oct 4, 2023 at 5:24 PM Jeffrey Yasskin 
wrote:

> Apparently +Chris Wilson  had part of this discussion
> with Alan Stearns in April at
> https://github.com/w3c/csswg-drafts/issues/8730#issuecomment-1524167658,
> and the suggestion was that if a CSS spec for a feature is "unstable"
> (meaning 'not at CR'?), then we should either post "we're about to send an
> intent" to the last issue discussing it, or file an "Is X ready to ship?"
> issue. I think +Chris Harrelson  is likely to have
> the strongest opinions about this: should we add such a rule to our launch
> process for CSS features?
>
> Jeffrey
>
> On Wed, Oct 4, 2023 at 1:15 PM Jeffrey Yasskin 
> wrote:
>
>> On Wed, Oct 4, 2023 at 1:08 PM Joey Arhar  wrote:
>>
>>> > I'd like to understand better how we wound up shipping :--foo and then
>>> having the CSSWG ask us to change it to :state(foo) instead, and what we
>>> could do in the future to avoid it happening again.
>>>
>>> I think if this was specced before shipping that would have been better
>>> and is a practice that I (and we?) currently follow, but this was shipped a
>>> number of years ago.
>>>
>>
>> Yeah, good point: it's totally possible that our more recent process
>> rigor is sufficient, and we don't need anything new to prevent this in the
>> future. No matter what, we should expect the occasional old feature to pop
>> up and be an exception.
>>
>> I do think that it's worth finding a way to write down your current
>> practice, so that it doesn't regress if you switch teams. I think you mean
>> that you do "hold off on shipping CSS features until they land in an
>> official draft", so let's try to record that if it's our idea of the
>> solution.
>>
>>
>>> > As far as I can see, nobody asked for the ergonomic evidence that
>>> https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews
>>> says we can expect after Chrome has shipped a feature.
>>>
>>> This was my bad, I didn't realize or didn't completely consider
>>> usecounters before I presented the name change to the CSSWG.
>>> I am hoping that with an answer from the API owners, I can go back to
>>> the CSSWG and potentially change it back.
>>> There is still no merged spec in HTML or CSS for this feature yet, but I
>>> have open PRs in both specs.
>>>
>>
>> Thanks!
>>
>> On Wed, Oct 4, 2023 at 1:00 PM Jeffrey Yasskin 
>>> wrote:
>>>
 +1 on the API owners discussing this.

 I'd like to understand better how we wound up shipping :--foo and then
 having the CSSWG ask us to change it to :state(foo) instead, and what we
 could do in the future to avoid it happening again.

 It looks like the initial proposal was :state(foo); the CSSWG asked to
 change it to :--foo in 2020
 ;
 we shipped that in M90 in 2021
  (with a feature
 entry that still says :state ); then Ryosuke suggested undoing that
 change in January 2023
 ,
 and the CSSWG accepted that suggestion in August
 .
 As far as I can see, nobody asked for the ergonomic evidence that
 https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews
 says we can expect after Chrome has shipped a feature. It doesn't seem like
 this feature was so contentious that the team needed to use a name change
 as a bargaining chip, so we should probably have insisted on more evidence
 before agreeing with the change. Maybe that's still a "should" instead of a
 "should have": Joey's second email
 
  might
 say that the CSSWG's resolution
 
 about this isn't as committed as it appears to an external observer?

 Should we generally hold off on shipping CSS features until they land
 in an official draft, or even in a CR? Should we be clearer to the CSSWG
 when we decide to ship ahead of their consensus that the bar for changes is
 going up? There's not good support for this kind of per-WG restriction in
 Chrome Status yet, but maybe it'll fit near
 https://github.com/GoogleChrome/chromium-dashboard/issues/3390...

 Jeffrey

 On Fri, Sep 29, 2023 at 12:32 PM Alex Russell 
 wrote:

> hrm, this is another instance of bikeshedding after shipping, and I'm
> not inclined to approve. Perhaps we can discuss at next week's API OWNERs
> meeting?
>
> Adding others who I know are 

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

['Thomas Steiner' via blink-dev]

See https://web.dev/text-fragments/#disabling-text-fragments for disabling
the feature.

On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi 
wrote:

> Hi Adam,
>
> > Is it still not possible to disable this distraction yet?
>
> Chrome used to have an option to disable this feature, but the flag was
> removed. It is possible to remove highlights with extensions. I found "Disable
> Google Search Text Highlights"
> 
> on CWS, but never used it. It's open source (GitHub link on store page).
> The source seems fine (albeit I would have written it with declarative
> network rules for efficiency, but very few developers are familiar with
> this API).
>
> Hope this helps.
>
> On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko wrote:
>
>> Is it still not possible to disable this distraction yet? I found a
>> wonderfully ironic example today - see attached screenshot.
>>
>> There seem to be only two ways that this feature is used:
>>
>> 1. The first sentence of a page is highlighted, which is completely
>> redundant and patronising. Yes Chrome, thank you for highlighting the very
>> first sentence. However could I cope without you.
>>
>> 2. A random sentence halfway through the page is highlighted. This is
>> never what I want: I always want to read the page so that I can understand
>> the sentence in context.
>>
>>
>>
>> On Wed, 5 May 2021, 06:40 Adam Semenenko,  wrote:
>>
>>> Hi all,
>>>
>>> Do you know if there's a consistent and easy way to disable this yet?
>>> It's really distracting for me. When I google something and click on a
>>> result, I like consistent behaviour and to see the whole page from the
>>> start. I feel disrupted when I'm randomly dropped into the middle of a page
>>> with a garish colour jumping out at me.
>>>
>>> Cheers,
>>> Adam
>>>
>>> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Hi all,

 It’s been roughly nine months since we first utilized Scroll To Text
 Fragment in featured snippets in Google Search. In that time, we’ve seen
 that Scroll To Text Fragment links help us towards our goal to get users
 the information they need.  In particular:

1. We find that Scroll To Text Fragment links increase engagement
-- users are less likely to visit a page and then quickly hit the back
button, because they can more readily understand how relevant the page 
 is
to their search after arriving at the page.

2. In user surveys, we find that users prefer being scrolled to the
relevant section of a page that’s in a featured snippet. Users who were
scrolled to the relevant section preferred the experience at a rate of 
 2:1;
even users who were not scrolled in the control group preferred the 
 option
of being scrolled to the relevant section at the same 2:1 rate.

 Besides their usage on Google Search, we’ve noticed scroll to text
 fragments links during our crawls of the web.  One of the best use cases
 has been wikipedia citations.  For instance, citation 9
 
 on this page: https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds)
 provides the detailed attribution to the fastest-ever time at the Melbourne
 Cup.

 Cheers,
 Grant
 On Thursday, December 12, 2019 at 12:24:40 PM UTC-8
 sligh...@chromium.org wrote:

> LGTM4
>
>
> On Thursday, December 12, 2019 at 12:17:49 PM UTC-8, Daniel Bratell
> wrote:
>>
>> LGTM3
>>
>> /Daniel
>>
>>
>> On Thursday, 12 December 2019 19:45:38 UTC+1, Chris Harrelson wrote:
>>>
>>> LGTM2
>>>
>>> On Wed, Dec 11, 2019 at 10:27 PM Yoav Weiss  wrote:
>>>
 LGTM1


 On Wed, Dec 11, 2019, 22:03 Nick Burris 
 wrote:

> Hi all,
>
> We feel that we're now in good shape for shipping. We have
> addressed all of the shipping blockers that I listed in my previous 
> email,
> and the corresponding implementation changes have landed in Chrome. 
> We're
> still continuing to make improvements to the spec, functionality, and 
> web
> platform tests but we consider the outstanding issues to be minor and
> wouldn't have an effect on interop, so we don't believe they're
> ship-blocking.
>
> We have received positive signal on the feature from Safari, thank
> you Maciej for the reply on webkit-dev
> !
> Note that we actually do have feature detectability specified 
> 

Re: [blink-dev] Intent to Ship: Document picture-in-picture

['François Beaufort' via blink-dev]

This API shipped in Chrome 116. See
https://developer.chrome.com/docs/web-platform/document-picture-in-picture/


On Thu, Oct 5, 2023 at 1:26 AM Mariano M  wrote:

> Hey, is there any official release date for the new PiP window without
> having to have the chrome flag enabled? Thanks!
>
> On Wednesday, June 14, 2023 at 12:47:58 PM UTC-3 Mike Taylor wrote:
>
>> LGTM3
>> On 6/14/23 11:47 AM, slightlyoff via Chromestatus wrote:
>>
>> LGTM2
>>
>> --
>> 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/d6062405fe18ddcb%40google.com
>> 
>> .
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/91d4591b-052b-42e9-8925-06a0d211e869n%40chromium.org
> 
> .
>

-- 
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/CAPpwU5JDykF1iRdMA0nGuu%2BAExJ_yCS%3DLevJQWE_wv%2BzGvXbsQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[Anton Bershanskyi]

Hi Adam,

> Is it still not possible to disable this distraction yet?

Chrome used to have an option to disable this feature, but the flag was 
removed. It is possible to remove highlights with extensions. I found "Disable 
Google Search Text Highlights" 

 
on CWS, but never used it. It's open source (GitHub link on store page). 
The source seems fine (albeit I would have written it with declarative 
network rules for efficiency, but very few developers are familiar with 
this API).

Hope this helps.

On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko wrote:

> Is it still not possible to disable this distraction yet? I found a 
> wonderfully ironic example today - see attached screenshot. 
>
> There seem to be only two ways that this feature is used:
>
> 1. The first sentence of a page is highlighted, which is completely 
> redundant and patronising. Yes Chrome, thank you for highlighting the very 
> first sentence. However could I cope without you.
>
> 2. A random sentence halfway through the page is highlighted. This is 
> never what I want: I always want to read the page so that I can understand 
> the sentence in context. 
>
>
>
> On Wed, 5 May 2021, 06:40 Adam Semenenko,  wrote:
>
>> Hi all,
>>
>> Do you know if there's a consistent and easy way to disable this yet? 
>> It's really distracting for me. When I google something and click on a 
>> result, I like consistent behaviour and to see the whole page from the 
>> start. I feel disrupted when I'm randomly dropped into the middle of a page 
>> with a garish colour jumping out at me. 
>>
>> Cheers,
>> Adam
>>
>> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hi all,
>>>
>>> It’s been roughly nine months since we first utilized Scroll To Text 
>>> Fragment in featured snippets in Google Search. In that time, we’ve seen 
>>> that Scroll To Text Fragment links help us towards our goal to get users 
>>> the information they need.  In particular:
>>>
>>>1. We find that Scroll To Text Fragment links increase engagement -- 
>>>users are less likely to visit a page and then quickly hit the back 
>>> button, 
>>>because they can more readily understand how relevant the page is to 
>>> their 
>>>search after arriving at the page.
>>>
>>>2. In user surveys, we find that users prefer being scrolled to the 
>>>relevant section of a page that’s in a featured snippet. Users who were 
>>>scrolled to the relevant section preferred the experience at a rate of 
>>> 2:1; 
>>>even users who were not scrolled in the control group preferred the 
>>> option 
>>>of being scrolled to the relevant section at the same 2:1 rate.
>>>
>>> Besides their usage on Google Search, we’ve noticed scroll to text 
>>> fragments links during our crawls of the web.  One of the best use cases 
>>> has been wikipedia citations.  For instance, citation 9 
>>> 
>>>  
>>> on this page: https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds) 
>>> provides the detailed attribution to the fastest-ever time at the Melbourne 
>>> Cup.
>>>
>>> Cheers,
>>> Grant
>>> On Thursday, December 12, 2019 at 12:24:40 PM UTC-8 
>>> sligh...@chromium.org wrote:
>>>
 LGTM4


 On Thursday, December 12, 2019 at 12:17:49 PM UTC-8, Daniel Bratell 
 wrote:
>
> LGTM3
>
> /Daniel
>
>
> On Thursday, 12 December 2019 19:45:38 UTC+1, Chris Harrelson wrote:
>>
>> LGTM2
>>
>> On Wed, Dec 11, 2019 at 10:27 PM Yoav Weiss  wrote:
>>
>>> LGTM1
>>>
>>>
>>> On Wed, Dec 11, 2019, 22:03 Nick Burris  wrote:
>>>
 Hi all,

 We feel that we're now in good shape for shipping. We have 
 addressed all of the shipping blockers that I listed in my previous 
 email, 
 and the corresponding implementation changes have landed in Chrome. 
 We're 
 still continuing to make improvements to the spec, functionality, and 
 web 
 platform tests but we consider the outstanding issues to be minor and 
 wouldn't have an effect on interop, so we don't believe they're 
 ship-blocking.

 We have received positive signal on the feature from Safari, thank 
 you Maciej for the reply on webkit-dev 
 !
  
 Note that we actually do have feature detectability specified 
 implemented 
 per my reply 
 .
  
 My apologies this was not mentioned in the initial intent to ship 
 email, it