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 
>

[blink-dev] Re: Intent to Ship: Intersection Observer Scroll Margin

[Yoav Weiss]

On Wed, Oct 4, 2023 at 10:27 PM Traian Captan  wrote:

> Hi Yoav,
>
> I don't know of Gecko's and WebKit's concrete implementation plans for
> Intersection Observer Scroll Margin.
> However, based on their responses on the github issue they were supportive.
>

Just wanted to note that we typically ask for official positions on the
different vendors standard positions repo.
But given the fact that this is a change Mozilla folks requested and Apple
folks consistently supported on the issue, I think it's fine to not file
those in this case.


> Regards,
> Traian
>
>
> On Wed, Oct 4, 2023 at 3:46 AM Yoav Weiss  wrote:
>
>>
>>
>> On Tuesday, September 26, 2023 at 1:10:34 AM UTC+2 Traian Captan wrote:
>>
>> Contact emailstcap...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://w3c.github.io/IntersectionObserver/#dom-
>> intersectionobserver-scrollmargin
>>
>> Summary
>>
>> Intersection Observer scrollMargin allows developers to observe targets
>> inside nested scroll containers that are currently clipped away by the
>> scroll containers. This is achieved by expanding the container's clipping
>> rect by the scrollMargin when calculating the intersection.
>>
>>
>> Blink componentBlink
>> 
>>
>> Search tagsIntersection Observer
>> ,
>> scrollMargin 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431
>> )
>>
>> *WebKit*: Positive (https://github.com/w3c/IntersectionObserver/issues/
>> 431)
>>
>>
>> Do you know of Gecko and WebKit's implementation plans for this?
>>
>>
>> *Web developers*: Positive (https://github.com/w3c/
>> IntersectionObserver/issues/431)
>>
>> *Other signals*:
>>
>> 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?
>>
>> None
>>
>>
>> Debuggability
>>
>> N/A
>>
>>
>> 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://flagsIntersectionObserverScrollMargin
>>
>> Finch feature nameNone
>>
>> Non-finch justification
>>
>> This feature is behind an enabled-by-default flag that can be disabled if
>> needed.
>>
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1469500
>>
>> Estimated milestonesShipping on desktop119DevTrial on desktop119Shipping
>> on Android119DevTrial on Android119Shipping on WebView119
>>
>> 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 Statushttps://chromestatus.com/
>> feature/5091020593430528
>>
>> Links to previous Intent discussionsIntent to prototype: https://groups.
>> google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsWGzF5au6c5%
>> 2BfVrh1hOCq_Y0rY0VF_bsmO8VVysg3QTg%40mail.gmail.com
>>
>> 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/CAL5BFfUaXafEJaKGLd2P11g1ocKrqZfdtLDmEb7Ru4VaJVmx2w%40mail.gmail.com.

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

[Yoav Weiss]

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 status Pending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>- Null report fixes: Increases the number of reports sent to
>>reporting

Re: [blink-dev] Intent to Ship: Shared Storage API Enhancements

['Jason Robbins' via blink-dev]

At this morning's API Owners meeting, they asked me to add all review gate 
types to all of the "web developer facing code change" features that are 
currently under review, including this one.  So, I have added Privacy, 
Security, Enterprise, Debuggability, and Testing gates to your feature 
entry. 

Please click the gate chips in the "Prepare to ship" stage on your feature 
detail page.  For each one, answer survey questions and request that 
cross-functional review.  You can request them all in parallel.  In cases 
where you already have the go/launch bit approved, you can note that in a 
comment on that gate for a potentially faster review.

Thanks,
jason!

On Wednesday, October 4, 2023 at 9:01:02 AM UTC-7 Chris Harrelson wrote:

> This looks good, but please file for all of the 5 other chips necessary 
> for shipping a feature.
>
> On Wed, Sep 27, 2023 at 11:13 AM Cammie Smith Barnes  
> wrote:
>
>> Contact emails
>>
>> cam...@chromium.org
>>
>> jka...@chromium.org
>>
>> ale...@chromium.org
>>
>> yao...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/shared-storage
>>
>> Specification
>>
>> https://wicg.github.io/shared-storage/
>>
>> Summary
>>
>> We plan to ship the following changes to the Shared Storage API:
>>
>>1. 
>>
>>Only allow Private Aggregation reports for up to 5 seconds after a 
>>worklet operation starts
>>1. 
>>   
>>   This is a privacy measure to prevent timing attacks.
>>   2. 
>>   
>>   Reports sent after this point are silently dropped
>>   2. 
>>
>>Allow writing to and deleting from Shared Storage via HTTP response 
>>header
>>1. 
>>   
>>   This is a performance improvement and is backwards compatible
>>   3. 
>>
>>Per-site privacy budgeting
>>1. 
>>   
>>   This change enforces budgets to per-site rather than per-origin
>>   
>>
>> Blink component
>>
>> Blink>Storage>SharedStorage 
>> 
>>
>>
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Change [1] will drop the private aggregation contributions issued after 5 
>> seconds after a worklet operation starts. 5 seconds should be sufficient 
>> for all known use cases, so this change should have negligible backward 
>> compatibility issues.
>>
>> Change [2] is optional and fully backwards compatible.  
>>
>> Change [3] could decrease budget for those that are using multiple 
>> origins today that are considered part of the same eTLD+1. Since the API is 
>> new (shipped in M115), the expectation is for the impact to be low. It will 
>> not break script since the APIs gracefully handle situations where the 
>> budget is exceeded, but could impact the overall quality of the returned 
>> data for that site.
>>
>> Gecko: No signal
>>
>> 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
>>
>> Shared Storage database contents for an origin can be viewed and modified 
>> within devtools. Support for debugging Shared Storage worklets will be 
>> available within the next couple of milestones.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> All but WebView
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>>
>> Yes
>>
>> Flag name
>>
>> Finch feature name
>>
>> SharedStorageAPIM118
>>
>> Requires code in //chrome?
>>
>> No
>>
>> Estimated milestones
>>
>> We intend to ship in  M119. 
>>
>> Anticipated spec changes
>>
>>1. 
>>
>>Timeout enforcement: 
>>
>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/102
>>2. 
>>
>>Allow writing to Shared Storage via response headers
>>
>> https://github.com/WICG/shared-storage/pull/110
>>
>>1. 
>>
>>Per-site privacy budgeting
>>
>> https://github.com/WICG/shared-storage/pull/118
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5112254843846656
>>
>> -- 
>> 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/CAJ8xcq5HooQ3L6HbL9z8-xP9fFw3gjW6150H8RSJ_a4pfDmMcQ%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
You received

Re: [blink-dev] Intent to Ship: CORS non-wildcard request-header

['Jason Robbins' via blink-dev]

At this morning's API Owners meeting, they asked me to add all review gate 
types to all of the "web developer facing code change" features that are 
currently under review, including this one.  So, I have added Privacy, 
Security, Enterprise, Debuggability, and Testing gates to your feature 
entry. 

Please click the gate chips in the "Prepare to ship" stage on your feature 
detail page.  For each one, answer survey questions and request that 
cross-functional review.  You can request them all in parallel.  In cases 
where you already have the go/launch bit approved, you can note that in a 
comment on that gate for a potentially faster review.

Thanks,
jason!

On Friday, July 21, 2023 at 1:12:51 AM UTC-7 vis...@chromium.org wrote:

> There is an ongoing conversation with Mozilla and Safari for the 
> coordinated removal of wildcard support for ACAH. 
>
> Firefox has this implemented 
>  behind a flag, 
> same as we do, and we are waiting for Safari's plans at this point. 
>
> On Thu, Jul 20, 2023 at 12:46 AM Yoav Weiss  wrote:
>
>> Any updates on this? :)
>>
>> On Wed, May 24, 2023 at 10:48 AM Javier Garcia Visiedo <
>> vis...@chromium.org> wrote:
>>
>>> I was targeting M116, which is aligned with what Firefox indicated. 
>>> However, other browsers are yet to confirm their timeline, and they have 
>>> indicated they might need more time, which makes 116 unrealistic if we want 
>>> to get other browsers in addition to Firefox onboard. 
>>>
>>> Regarding the outreach plan, we haven't discussed it in detail, but I 
>>> imagine it'd be something like blog posts from each vendor, in addition to 
>>> the existing warnings on the developer tools. 
>>>
>>> I'll come back once I get more details from the remaining vendors. 
>>>
>>> On Tue, May 23, 2023 at 8:07 PM Yoav Weiss  wrote:
>>>
 I'd be supportive of a coordinated change, given that popular 3P 
 outreach was successful, and 1P use is unlikely to result in user visible 
 breakage.
 What's the timeline you have in mind? What's the outreach plan to make 
 developers aware of this upcoming change?

 On Tuesday, May 16, 2023 at 7:03:34 PM UTC+2 vis...@google.com wrote:

> Yes, I've got a positive response from the two 3P APIs  (relatively 
> popular). One case is already solved and in production, the second one, 
> responsible for a huge increase on the UKM entries from February - March 
> is 
> solved and testing right now.
>
> However, I believe we still want to coordinate the launch with other 
> browsers. Discussions are ongoing in this sense, and so far Firefox 
> confirmed they are in a similar situation, code complete and ready to 
> ship 
> if / when we are.  
>
> On Mon, May 15, 2023 at 10:57 PM Mike Taylor  
> wrote:
>
>> Hi Javier,
>>
>> On 4/5/23 5:54 AM, Javier Garcia Visiedo wrote:
>>
>> For these visual elements, are there any common threads that you 
>>> could notice? E.g. Any common 3P providers?
>>>
>>
>>  In all cases I've seen, these are 1P requests of the form 
>> https://foo.example to https://api.foo.example/api/v1/blah. I've not 
>> found many sites with these visual element impacts, so I've been trying 
>> to contact them. So far with no luck.
>>
>> I guess the same question also applies to the non-visual breakage. 
>>> (you mentioned analytics and personalization providers)
>>
>>
>> These account for the majority of the cases I found, and all but 2 of 
>> them are 1P.
>>
>> I have identified two cases of 3P which are quite relevant, and have 
>> just made contact with them. I will provide an update once I receive 
>> feedback.
>>
>> Any luck hearing back from these sites?
>>
>>  
>>
>> On Thu, Mar 30, 2023 at 1:35 AM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Wed, Mar 29, 2023 at 11:01 AM Yoav Weiss  
>>> wrote:
>>>


 On Wed, Mar 29, 2023 at 10:32 AM Javier Garcia Visiedo <
 vis...@chromium.org> wrote:

> Thank you for your quick reply Yoav, 
>
> Please find my answers inline.
>
>
> On Wednesday, March 29, 2023 at 4:35:32 PM UTC+9 Yoav Weiss wrote:
>
> Thank you so much, Javier! :) That's some great analysis!
>
> On Wed, Mar 29, 2023 at 7:51 AM Javier Garcia Visiedo <
> vis...@chromium.org> wrote:
>
> Hi all, 
>
> Please find the summary of my findings, after analyzing the UKM 
> data.
>
> Currently, the UKM data shows 2,087 distinct domains (eTLD+1) 
> sending a wildcard for ACAH and/or ACAO in response to a 
> credentialled 
> request. The UKM data is not good at showing events over time, but 
> the use 
> counter 
> 

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

['Jason Robbins' via blink-dev]

At this morning's API Owners meeting, they asked me to add all review gate 
types to all of the "web developer facing code change" features that are 
currently under review, including this one.  So, I have added Privacy, 
Security, Enterprise, Debuggability, and Testing gates to your feature 
entry. 

Please click the gate chips in the "Prepare to ship" stage on your feature 
detail page.  For each one, answer survey questions and request that of the 
cross-functional review.  You can request them all in parallel.  In cases 
where you already have the go/launch bit approved, you can note that in a 
comment on that gate for a potentially faster review.

Thanks,
jason!
On Monday, October 2, 2023 at 9:09:18 AM UTC-7 Jason Robbins wrote:

> On Friday, September 29, 2023 at 1:01:54 PM UTC-7 Chris Harrelson wrote:
>
> Please also make sure to complete all of the other shipping gate reviews 
> 
> .
>
>
> I think a bug in ChromeStatus may have caused some confusion on this 
> feature entry.  The feature entry has type "Web developer facing code 
> change", so its bilnk-dev thread should have had subject line prefix 
> "Web-facing change PSA" rather than "Intent to ship".  And, according to 
> the launching-features doc 
> , 
> it does not require any approvals, which is why there are no other gates 
> offered in the ChromeStatus UI.  A fix for that subject-line prefix bug 
> should go live today.
>
> Of course, the point of a PSA is to allow concerns to be raised and I see 
> that this is a very active thread.  So, all that should be worked through.  
> Its a mater of the the API Owners prerogative to request any other reviews 
> that they think are appropriate, but it is not automatically required by 
> the process for this feature type.  Also, I see that the launch entry 
>  had some approvals.
>
> Thanks,
> jason! 
>

-- 
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/32522361-0802-45e3-95b6-a781c6d536efn%40chromium.org.

[blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

['Sahir Vellani' via blink-dev]

Contact emails
gerch...@microsoft.com, 
sahir.vell...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Specification
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Summary

As devices with advanced pen input capabilities are becoming increasingly 
prevalent, it is important that the web platform continues to evolve to fully 
support these advanced features in order to unlock rich experiences for both 
end users and developers. One such advancement is the ability for a device's 
digitizer to recognize more than one pen device interacting with it 
simultaneously. This feature is an extension to the PointerEvent interface to 
include a new attribute, deviceId, that represents a session-persistent, 
document isolated, unique identifier that a developer can reliably use to 
identify individual pens interacting with the page.


Blink component
Blink>Input

TAG review
https://github.com/w3ctag/design-reviews/issues/880

TAG review status
Pending. TAG review has been pending for 2 months.

Risks


Interoperability and Compatibility


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

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/102)

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


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

Is this feature fully tested by 
web-platform-tests?
No. However, there are web tests in Chromium that test PointerEventInit with 
this feature.

Flag name on chrome://flags
PointerEventDeviceId

Finch feature name


Non-finch justification
Edge origin trials successfully underway.

Requires code in //chrome?
False

Measurement
PointerEventDeviceId use counter implemented.

Availability expectation
Initially available on Chromium browsers on Windows.

Adoption expectation
Feature is used by specific partner(s) to provide functionality immediately 
upon launch.

Adoption plan
This feature has been through origin trials on Edge. It is being used by 
partners that provide features on devices with multi pen support.

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?

Operating system API's are used to obtain the device id, and are necessary for 
this feature to function. Please see the security questionnaire in the TAG 
review on security and privacy concerns related to the use of these APIs.

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

WICG Proposal: https://github.com/WICG/proposals/issues/101 No web 
compat/interop risk.

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

Links to previous Intent discussions
Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SA0PR00MB1033E5DE0BDE42239E647E9AFB189%40SA0PR00MB1033.namprd00.prod.outlook.com

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/PH0PR00MB1349B7917876E7AC505E790AFBCBA%40PH0PR00MB1349.namprd00.prod.outlook.com.

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

[Mariano M]

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.

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

['Tommy Steimel' via blink-dev]

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.

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

[Jeffrey Yasskin]

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 interested in this topic.

 On Friday, September 29, 2023 at 9:16:13 AM UTC-7 Joey Arhar wrote:

> The spec for the new syntax hasn't been merged yet, I haven't finished
> implementing it in chromium yet, and I don't have estimated milestones 
> yet,
> but I'd like to get the API owners thoughts on whether th

[blink-dev] Re: Intent to Ship: Intersection Observer Scroll Margin

[Traian Captan]

Hi Yoav,

I don't know of Gecko's and WebKit's concrete implementation plans for
Intersection Observer Scroll Margin.
However, based on their responses on the github issue they were supportive.

Regards,
Traian


On Wed, Oct 4, 2023 at 3:46 AM Yoav Weiss  wrote:

>
>
> On Tuesday, September 26, 2023 at 1:10:34 AM UTC+2 Traian Captan wrote:
>
> Contact emailstcap...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://w3c.github.io/IntersectionObserver/#dom-
> intersectionobserver-scrollmargin
>
> Summary
>
> Intersection Observer scrollMargin allows developers to observe targets
> inside nested scroll containers that are currently clipped away by the
> scroll containers. This is achieved by expanding the container's clipping
> rect by the scrollMargin when calculating the intersection.
>
>
> Blink componentBlink
> 
>
> Search tagsIntersection Observer
> ,
> scrollMargin 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)
>
> *WebKit*: Positive (https://github.com/w3c/IntersectionObserver/issues/431
> )
>
>
> Do you know of Gecko and WebKit's implementation plans for this?
>
>
> *Web developers*: Positive (https://github.com/w3c/
> IntersectionObserver/issues/431)
>
> *Other signals*:
>
> 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?
>
> None
>
>
> Debuggability
>
> N/A
>
>
> 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://flagsIntersectionObserverScrollMargin
>
> Finch feature nameNone
>
> Non-finch justification
>
> This feature is behind an enabled-by-default flag that can be disabled if
> needed.
>
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1469500
>
> Estimated milestonesShipping on desktop119DevTrial on desktop119Shipping
> on Android119DevTrial on Android119Shipping on WebView119
>
> 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 Statushttps://chromestatus.com/
> feature/5091020593430528
>
> Links to previous Intent discussionsIntent to prototype: https://groups.
> google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsWGzF5au6c5%
> 2BfVrh1hOCq_Y0rY0VF_bsmO8VVysg3QTg%40mail.gmail.com
>
> 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/CAFxahvuOnT-94DXwNTm%3DGu3qnjqK4yNMG2gamw%2BQTpRG%3D7tiaQ%40mail.gmail.com.

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

[Jeffrey Yasskin]

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 interested in this topic.
>>>
>>> On Friday, September 29, 2023 at 9:16:13 AM UTC-7 Joey Arhar wrote:
>>>
 The spec for the new syntax hasn't been merged yet, I haven't finished
 implementing it in chromium yet, and I don't have estimated milestones yet,
 but I'd like to get the API owners thoughts on whether this deprecation
 would be acceptable to help guide the spec discussion.

 I did some analysis of the top 8 websites on the chromestatus entry to
 see what the breakage would be like:
 https://docs.google.com/document/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing
 I found that most of them had the affected custom elements behind
 display:none rules that I had to manually remove in order to use them.
 There was only one website where there was actual breakage by default, in
 which case the carousel buttons didn't work on firefox and safari. If the
 new syntax is just for the CSS property and we keep CustomStateSet the
 same, then the affe

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

[Joey Arhar]

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

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

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 interested in this topic.
>>
>> On Friday, September 29, 2023 at 9:16:13 AM UTC-7 Joey Arhar wrote:
>>
>>> The spec for the new syntax hasn't been merged yet, I haven't finished
>>> implementing it in chromium yet, and I don't have estimated milestones yet,
>>> but I'd like to get the API owners thoughts on whether this deprecation
>>> would be acceptable to help guide the spec discussion.
>>>
>>> I did some analysis of the top 8 websites on the chromestatus entry to
>>> see what the breakage would be like:
>>> https://docs.google.com/document/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing
>>> I found that most of them had the affected custom elements behind
>>> display:none rules that I had to manually remove in order to use them.
>>> There was only one website where there was actual breakage by default, in
>>> which case the carousel buttons didn't work on firefox and safari. If the
>>> new syntax is just for the CSS property and we keep CustomStateSet the
>>> same, then the affected website's buttons would continue to work but
>>> whatever custom styles they have (which I couldn't trigger) wouldn't apply
>>> anymore.
>>>
>>> Personally, I think that this breakage would not be bad especially if we
>>> keep CustomStateSet the same, and I kind of like :state(foo) more than
>>> :--foo. However, I might have not made it clear in the spec discussions yet
>>> that we have already shipped :--foo by default for several years.
>>>
>>> On Fri, Sep 29, 2023 at 9:15 AM Joey Arhar  wrote:
>>>
 Contact emailsjar...@chromium.org

 ExplainerNone

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

 Summary

 CSS custom state, which allows cu

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

[Jeffrey Yasskin]

+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 interested in this topic.
>
> On Friday, September 29, 2023 at 9:16:13 AM UTC-7 Joey Arhar wrote:
>
>> The spec for the new syntax hasn't been merged yet, I haven't finished
>> implementing it in chromium yet, and I don't have estimated milestones yet,
>> but I'd like to get the API owners thoughts on whether this deprecation
>> would be acceptable to help guide the spec discussion.
>>
>> I did some analysis of the top 8 websites on the chromestatus entry to
>> see what the breakage would be like:
>> https://docs.google.com/document/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing
>> I found that most of them had the affected custom elements behind
>> display:none rules that I had to manually remove in order to use them.
>> There was only one website where there was actual breakage by default, in
>> which case the carousel buttons didn't work on firefox and safari. If the
>> new syntax is just for the CSS property and we keep CustomStateSet the
>> same, then the affected website's buttons would continue to work but
>> whatever custom styles they have (which I couldn't trigger) wouldn't apply
>> anymore.
>>
>> Personally, I think that this breakage would not be bad especially if we
>> keep CustomStateSet the same, and I kind of like :state(foo) more than
>> :--foo. However, I might have not made it clear in the spec discussions yet
>> that we have already shipped :--foo by default for several years.
>>
>> On Fri, Sep 29, 2023 at 9:15 AM Joey Arhar  wrote:
>>
>>> Contact emailsjar...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://github.com/whatwg/html/pull/8467
>>>
>>> Summary
>>>
>>> CSS custom state, which allows custom elements to expose their own
>>> pseudo-classes, was shipped here:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dJibhmzE73o/m/VT-NceIhAAAJ
>>>
>>> This feature has not been implemented in gecko or webkit yet. I recently
>>> made an effort to spec this feature in CSSWG and WHATWG, but there was
>>> pushback to change the syntax back from :--foo to :state(foo), and the
>>> CSSWG has resolved to do this as well:
>>> https://github.com/w3c/csswg-drafts/issues/4805
>>>
>>> The UseCounter is currently at 0.03%
>>> https://chromestatus.com/metrics/feature/timeline/popularity/3796
>>>
>>> This deprecation will have a window where we support both the old syntax
>>> and the new syntax so websites can switch to the new one.
>>>
>>>
>>> Blink componentBlink>HTML>CustomElements
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Websites which are currently using the old syntax and don't migrate to
>>> the ne

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

['Ajay Rahatekar' via blink-dev]

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 this alternative fullscreen entrypoint.
>
> Ongoing technical constraints
>
> None
>
> Debuggability
>
> This feature utilizes the existing `windowFeatures` string parameter 
> in `window.open()` and does not modify any structured (i.e. WebIDL) API 
> surface. This feature will utilize existing

Re: [blink-dev] Intent to Ship: Protected Audiences Negative Targeting

['Orr Bernstein' via blink-dev]

Thank you all so much. I'll update this thread when
https://github.com/WICG/turtledove/pull/796 has landed.

All the best,
- Orr


On Wed, Oct 4, 2023 at 11:51 AM Chris Harrelson 
wrote:

> LGTM3, same.
>
> On Wed, Oct 4, 2023 at 8:50 AM Yoav Weiss  wrote:
>
>> LGTM2 with the same conditions
>>
>> On Monday, October 2, 2023 at 11:00:07 PM UTC+2 Mike Taylor wrote:
>>
>>> LGTM1 % landing https://github.com/WICG/turtledove/pull/796. Please
>>> follow up with the WPTs as well.
>>> On 9/27/23 11:56 AM, Chris Harrelson wrote:
>>>
>>> Please fill out the other chromestatus review categories (privacy,
>>> security, etc); we'll re-review once those are done.
>>>
>>> On Wed, Sep 20, 2023 at 2:42 PM 'Orr Bernstein' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 o...@google.com, pauljen...@chromium.org

 Explainer

 https://github.com/WICG/turtledove/pull/780

 Specification

 https://github.com/WICG/turtledove/pull/796

 Summary

 In online ad auctions for ad space, it’s sometimes useful to prevent
 showing an ad to certain audiences, a concept known as negative targeting.
 For example, you might not want to show a new customer advertisement to
 existing customers. New customer acquisition campaigns most often have this
 as a critical requirement. Protected Audience currently enables ads to
 target users that have been joined to a given interest group through some
 past activity on the web. This feature extends Protected Audience to enable
 negative targeting by allowing new ads to target only those users who have
 not been joined to a given interest group. In this way, we're enabling
 advertisers to target new groups of users using the existing
 privacy-preserving concepts of the Protected Audience API.


 Blink component

 Blink>InterestGroups
 

 TAG review

 The parent proposal, Protected Audience, is still pending:
 https://github.com/w3ctag/design-reviews/issues/723

 TAG review status

 Pending

 Risks

 Interoperability and Compatibility

 None. This is an optional new feature of the Protected Audience API. Ad
 techs can use this new feature by specifying values for new fields in the
 auction config. Without explicit values for those new fields, there's no
 functional behavioral change as a result of this feature.

 Gecko & WebKit: No signal on parent proposal, Protected Audience.
 Asked in the Mozilla forum here
 , and in
 the Webkit forum here
 .

 Web developers: Adtech asked for this via Protected Audience Github
 issue #319 .


 Debuggability

 Additional bids sent into the auction are visible in their response
 headers via DevTools. You can determine if the additional bid was sent for
 scoring by adding a breakpoint in the scoring script in DevTools. Error
 scenarios, e.g. signature verification errors and joining origin mismatch
 on negative interest groups - are written to the console. We're considering
 additional DevTools enhancements to aid additional bids debugging.

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

 It will be supported on all platforms that support Protected Audience,
 so all but WebView.

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

 We plan to add WPTs to cover this API in the next month.

 Flag name on chrome://flags

 None

 Finch feature name

 FledgeNegativeTargeting

 Requires code in //chrome?

 False

 Estimated milestones

 Shipping on desktop and Android in M118.

 Anticipated spec changes

 None related to this feature.

 Link to entry on the Chrome Platform Status

 https://chromestatus.com/feature/5021508157571072

 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/5ebd44f6-57b2-448f-b32c-87d63acfa471n%40chromium.org
 

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

[Nan Lin]

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 trial for 4 additional milestones, with the
extension starting in M120 continuing through M123. The experiment is
therefore running from Chrome M114 through M123.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4994430156668928

Links to previous Intent discussions

Cross App Web Attribution Measurement I2E


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

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

[Alex Turner]

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 status Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>- Null report fixes: Increases the number of reports sent to
>reporting endpoints, reporting endpoints using plaintext debug payloads
>will need to handle the null report case.
>
> Do you know if current reporting endpoints are ready to handle this
 change?
>>>

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

[Joey Arhar]

> Have Firefox and Safari implemented the new syntax?

No, I don't think they have started implementing anything yet.

On Wed, Oct 4, 2023 at 3:35 AM Yoav Weiss  wrote:

>
>
> On Friday, September 29, 2023 at 9:32:16 PM UTC+2 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?
>
>
> We should definitely discuss this broader subject!
>
>
>
> Adding others who I know are interested in this topic.
>
> On Friday, September 29, 2023 at 9:16:13 AM UTC-7 Joey Arhar wrote:
>
> The spec for the new syntax hasn't been merged yet, I haven't finished
> implementing it in chromium yet, and I don't have estimated milestones yet,
> but I'd like to get the API owners thoughts on whether this deprecation
> would be acceptable to help guide the spec discussion.
>
> I did some analysis of the top 8 websites on the chromestatus entry to see
> what the breakage would be like: https://docs.google.com/docume
> nt/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing
> I found that most of them had the affected custom elements behind
> display:none rules that I had to manually remove in order to use them.
> There was only one website where there was actual breakage by default, in
> which case the carousel buttons didn't work on firefox and safari.
>
>
> Have Firefox and Safari implemented the new syntax?
>
>
> If the new syntax is just for the CSS property and we keep CustomStateSet
> the same, then the affected website's buttons would continue to work but
> whatever custom styles they have (which I couldn't trigger) wouldn't apply
> anymore.
>
> Personally, I think that this breakage would not be bad especially if we
> keep CustomStateSet the same, and I kind of like :state(foo) more than
> :--foo. However, I might have not made it clear in the spec discussions yet
> that we have already shipped :--foo by default for several years.
>
>
> 0.03% is not nothing. 1/8 ratio of breakage there is encouraging, but we'd
> probably need slightly broader sampling approach to get a sense of
> real-life breakage. (e.g. ~20 random sites)
>
>
>
> On Fri, Sep 29, 2023 at 9:15 AM Joey Arhar  wrote:
>
> Contact emailsjar...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/whatwg/html/pull/8467
>
> Summary
>
> CSS custom state, which allows custom elements to expose their own
> pseudo-classes, was shipped here: https://groups.google.com/a/ch
> romium.org/g/blink-dev/c/dJibhmzE73o/m/VT-NceIhAAAJ
>
> This feature has not been implemented in gecko or webkit yet. I recently
> made an effort to spec this feature in CSSWG and WHATWG, but there was
> pushback to change the syntax back from :--foo to :state(foo), and the
> CSSWG has resolved to do this as well: https://github.com/w3c/csswg-d
> rafts/issues/4805
>
> The UseCounter is currently at 0.03% https://chromestatus.com/metri
> cs/feature/timeline/popularity/3796
>
> This deprecation will have a window where we support both the old syntax
> and the new syntax so websites can switch to the new one.
>
>
> Blink componentBlink>HTML>CustomElements
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Websites which are currently using the old syntax and don't migrate to the
> new syntax will have CSS selectors which become invalid which would impact
> the styling of their custom elements.
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal (https://github.com/whatwg/htm
> l/pull/8467#issuecomment-1381645661)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Activation
>
> Switching to the new syntax should be quite easy.
>
>
> 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 justificationNone
>
> Requires code in //chrome?False
>
> 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 Statushttps://chromestatus.com/featu
> re/5140610730426368
>
> This intent message w

Re: [blink-dev] Intent to Ship: Shared Storage API Enhancements

[Chris Harrelson]

This looks good, but please file for all of the 5 other chips necessary for
shipping a feature.

On Wed, Sep 27, 2023 at 11:13 AM Cammie Smith Barnes 
wrote:

> Contact emails
>
> cam...@chromium.org
>
> jkar...@chromium.org
>
> ale...@chromium.org
>
> yao...@chromium.org
>
> Explainer
>
> https://github.com/WICG/shared-storage
>
> Specification
>
> https://wicg.github.io/shared-storage/
>
> Summary
>
> We plan to ship the following changes to the Shared Storage API:
>
>1.
>
>Only allow Private Aggregation reports for up to 5 seconds after a
>worklet operation starts
>1.
>
>   This is a privacy measure to prevent timing attacks.
>   2.
>
>   Reports sent after this point are silently dropped
>   2.
>
>Allow writing to and deleting from Shared Storage via HTTP response
>header
>1.
>
>   This is a performance improvement and is backwards compatible
>   3.
>
>Per-site privacy budgeting
>1.
>
>   This change enforces budgets to per-site rather than per-origin
>
>
> Blink component
>
> Blink>Storage>SharedStorage
> 
>
>
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> Change [1] will drop the private aggregation contributions issued after 5
> seconds after a worklet operation starts. 5 seconds should be sufficient
> for all known use cases, so this change should have negligible backward
> compatibility issues.
>
> Change [2] is optional and fully backwards compatible.
>
> Change [3] could decrease budget for those that are using multiple origins
> today that are considered part of the same eTLD+1. Since the API is new
> (shipped in M115), the expectation is for the impact to be low. It will not
> break script since the APIs gracefully handle situations where the budget
> is exceeded, but could impact the overall quality of the returned data for
> that site.
>
> Gecko: No signal
>
> 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
>
> Shared Storage database contents for an origin can be viewed and modified
> within devtools. Support for debugging Shared Storage worklets will be
> available within the next couple of milestones.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> All but WebView
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
> Flag name
>
> Finch feature name
>
> SharedStorageAPIM118
>
> Requires code in //chrome?
>
> No
>
> Estimated milestones
>
> We intend to ship in  M119.
>
> Anticipated spec changes
>
>1.
>
>Timeout enforcement:
>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/102
>2.
>
>Allow writing to Shared Storage via response headers
>
> https://github.com/WICG/shared-storage/pull/110
>
>1.
>
>Per-site privacy budgeting
>
> https://github.com/WICG/shared-storage/pull/118
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5112254843846656
>
> --
> 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/CAJ8xcq5HooQ3L6HbL9z8-xP9fFw3gjW6150H8RSJ_a4pfDmMcQ%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%2Bw8G%3DYcHzE51CNvR1LRuVq-mM%2Bjqg6haLW7y3M9oYs_crA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Unprefix -webkit-background-clip for "text" and make it an alias

[Daniel Bratell]

LGTM3

/Daniel

On 2023-10-02 23:16, Mike Taylor wrote:


LGTM2, can you also please request reviews for the other categories in 
chromestatus (and file any relevant issues in the compat spec, if needed)?


On 9/28/23 1:16 PM, Daniil Sakhapov wrote:
Sure, I'm saying that old -webkit-background-clip works with 
keywords: border, content, padding. The new one - background-clip 
works with border-box, content-box, padding-box.
So, per compat spec -webkit-background-clip should be alias to 
background-clip. But since the keywords are different, in order to 
handle round trip better (e.g. setting -webkit-background-clip to 
content would read back content-box, as it's an alias to 
background-clip), we want to drop support of old keywords without 
-box for -webkit-background-clip. To see how bad that would we've set 
up use counters.
The biggest one is 0.08%. I've manually checked 80% of the websites 
reported by that use counter, but found that all of them use *-box 
keywords, and only one uses -webkit-background-clip: content.

So I think it's safe to remove support for old keywords.
Hope it's more clear now.
On Wednesday, September 27, 2023 at 4:55:53 PM UTC+2 Daniel Bratell 
wrote:



It allows to use the unprefixed version for background-clip:
text and makes -webkit-background-clip an alias for
background-clip. Also, it drops support for non-suffixed
keywords (content, padding and border) for better round-trip
with alias.


Can you clarify exactly what this means? I'm perfectly fine with
lgtm-ing unprefixing and adding a (temporary?) alias for the old
keyword, but if we start removing support for keywords we need to
be more careful and I want to be sure I understand.

/Daniel

On 2023-09-27 09:53, Daniil Sakhapov wrote:


Also forgot to mention: the highest use counter for unsuffixed
keyword is 0.08 - and among those I've analyzed 80% of websites
and all of them use suffixed *-box version, so it's safe to remove.

On Wednesday, September 27, 2023 at 9:49:35 AM UTC+2 Yoav Weiss
wrote:

LGTM1

On Wed, Sep 27, 2023 at 2:38 AM 一丝  wrote:

I think the correct specification address would be
https://drafts.csswg.org/css-backgrounds-4/#typedef-bg-clip


In css-backgrounds-4 also added `border` value, should
we support it when removing the prefix? Maybe this needs
to be discussed further by the CSSWG.

在2023年9月27日星期三 UTC+8 06:04:54
写道：

Is there any interest in doing the same for
-webkit-text-fill-color? The two get typically used
in combination for gradient effects:

https://github.com/tomayac/blogccasion/blob/6ee3722011661db7a0c95c4379d7905bd8e95404/css/main.css#L100-L113

.
(See any of the headings on
https://blog.tomayac.com/ for an example.)

On Tue, Sep 26, 2023, 16:33 Daniil Sakhapov
 wrote:


Contact emails

sakh...@chromium.org


Specification

https://drafts.csswg.org/css-backgrounds/#background-clip



Summary

It allows to use the unprefixed version for
background-clip: text and makes
-webkit-background-clip an alias for
background-clip. Also, it drops support for
non-suffixed keywords (content, padding and
border) for better round-trip with alias.


Blink component

Blink>CSS




Risks


Interoperability and Compatibility

None


/Gecko/: Shipped/Shipping Firefox doesn't
support keywords with no suffix for prefixed version

/WebKit/: Shipped/Shipping Safari supports
keywords with no suffix (border, content,
padding), but only for prefixed version


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

Re: [blink-dev] Intent to Ship: Protected Audiences Negative Targeting

[Chris Harrelson]

LGTM3, same.

On Wed, Oct 4, 2023 at 8:50 AM Yoav Weiss  wrote:

> LGTM2 with the same conditions
>
> On Monday, October 2, 2023 at 11:00:07 PM UTC+2 Mike Taylor wrote:
>
>> LGTM1 % landing https://github.com/WICG/turtledove/pull/796. Please
>> follow up with the WPTs as well.
>> On 9/27/23 11:56 AM, Chris Harrelson wrote:
>>
>> Please fill out the other chromestatus review categories (privacy,
>> security, etc); we'll re-review once those are done.
>>
>> On Wed, Sep 20, 2023 at 2:42 PM 'Orr Bernstein' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> o...@google.com, pauljen...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/turtledove/pull/780
>>>
>>> Specification
>>>
>>> https://github.com/WICG/turtledove/pull/796
>>>
>>> Summary
>>>
>>> In online ad auctions for ad space, it’s sometimes useful to prevent
>>> showing an ad to certain audiences, a concept known as negative targeting.
>>> For example, you might not want to show a new customer advertisement to
>>> existing customers. New customer acquisition campaigns most often have this
>>> as a critical requirement. Protected Audience currently enables ads to
>>> target users that have been joined to a given interest group through some
>>> past activity on the web. This feature extends Protected Audience to enable
>>> negative targeting by allowing new ads to target only those users who have
>>> not been joined to a given interest group. In this way, we're enabling
>>> advertisers to target new groups of users using the existing
>>> privacy-preserving concepts of the Protected Audience API.
>>>
>>>
>>> Blink component
>>>
>>> Blink>InterestGroups
>>> 
>>>
>>> TAG review
>>>
>>> The parent proposal, Protected Audience, is still pending:
>>> https://github.com/w3ctag/design-reviews/issues/723
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> None. This is an optional new feature of the Protected Audience API. Ad
>>> techs can use this new feature by specifying values for new fields in the
>>> auction config. Without explicit values for those new fields, there's no
>>> functional behavioral change as a result of this feature.
>>>
>>> Gecko & WebKit: No signal on parent proposal, Protected Audience.
>>> Asked in the Mozilla forum here
>>> , and in the
>>> Webkit forum here
>>> .
>>>
>>> Web developers: Adtech asked for this via Protected Audience Github
>>> issue #319 .
>>>
>>>
>>> Debuggability
>>>
>>> Additional bids sent into the auction are visible in their response
>>> headers via DevTools. You can determine if the additional bid was sent for
>>> scoring by adding a breakpoint in the scoring script in DevTools. Error
>>> scenarios, e.g. signature verification errors and joining origin mismatch
>>> on negative interest groups - are written to the console. We're considering
>>> additional DevTools enhancements to aid additional bids debugging.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> It will be supported on all platforms that support Protected Audience,
>>> so all but WebView.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> We plan to add WPTs to cover this API in the next month.
>>>
>>> Flag name on chrome://flags
>>>
>>> None
>>>
>>> Finch feature name
>>>
>>> FledgeNegativeTargeting
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Estimated milestones
>>>
>>> Shipping on desktop and Android in M118.
>>>
>>> Anticipated spec changes
>>>
>>> None related to this feature.
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5021508157571072
>>>
>>> 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/5ebd44f6-57b2-448f-b32c-87d63acfa471n%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

Re: [blink-dev] Intent to Ship: Protected Audiences Negative Targeting

[Yoav Weiss]

LGTM2 with the same conditions

On Monday, October 2, 2023 at 11:00:07 PM UTC+2 Mike Taylor wrote:

> LGTM1 % landing https://github.com/WICG/turtledove/pull/796. Please 
> follow up with the WPTs as well.
> On 9/27/23 11:56 AM, Chris Harrelson wrote:
>
> Please fill out the other chromestatus review categories (privacy, 
> security, etc); we'll re-review once those are done.
>
> On Wed, Sep 20, 2023 at 2:42 PM 'Orr Bernstein' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails 
>>
>> o...@google.com, pauljen...@chromium.org
>>
>> Explainer 
>>
>> https://github.com/WICG/turtledove/pull/780
>>
>> Specification 
>>
>> https://github.com/WICG/turtledove/pull/796
>>
>> Summary 
>>
>> In online ad auctions for ad space, it’s sometimes useful to prevent 
>> showing an ad to certain audiences, a concept known as negative targeting. 
>> For example, you might not want to show a new customer advertisement to 
>> existing customers. New customer acquisition campaigns most often have this 
>> as a critical requirement. Protected Audience currently enables ads to 
>> target users that have been joined to a given interest group through some 
>> past activity on the web. This feature extends Protected Audience to enable 
>> negative targeting by allowing new ads to target only those users who have 
>> not been joined to a given interest group. In this way, we're enabling 
>> advertisers to target new groups of users using the existing 
>> privacy-preserving concepts of the Protected Audience API.
>>
>>
>> Blink component 
>>
>> Blink>InterestGroups 
>> 
>>
>> TAG review 
>>
>> The parent proposal, Protected Audience, is still pending: 
>> https://github.com/w3ctag/design-reviews/issues/723
>>
>> TAG review status 
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility 
>>
>> None. This is an optional new feature of the Protected Audience API. Ad 
>> techs can use this new feature by specifying values for new fields in the 
>> auction config. Without explicit values for those new fields, there's no 
>> functional behavioral change as a result of this feature.
>>
>> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked 
>> in the Mozilla forum here 
>> , and in the 
>> Webkit forum here 
>> .
>>
>> Web developers: Adtech asked for this via Protected Audience Github 
>> issue #319 .
>>
>>
>> Debuggability 
>>
>> Additional bids sent into the auction are visible in their response 
>> headers via DevTools. You can determine if the additional bid was sent for 
>> scoring by adding a breakpoint in the scoring script in DevTools. Error 
>> scenarios, e.g. signature verification errors and joining origin mismatch 
>> on negative interest groups - are written to the console. We're considering 
>> additional DevTools enhancements to aid additional bids debugging.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)? 
>>
>> It will be supported on all platforms that support Protected Audience, so 
>> all but WebView.
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? 
>>
>> We plan to add WPTs to cover this API in the next month.
>>
>> Flag name on chrome://flags 
>>
>> None
>>
>> Finch feature name 
>>
>> FledgeNegativeTargeting
>>
>> Requires code in //chrome? 
>>
>> False
>>
>> Estimated milestones 
>>
>> Shipping on desktop and Android in M118.
>>
>> Anticipated spec changes 
>>
>> None related to this feature.
>>
>> Link to entry on the Chrome Platform Status 
>>
>> https://chromestatus.com/feature/5021508157571072
>>
>> 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/5ebd44f6-57b2-448f-b32c-87d63acfa471n%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/CAOMQ%2Bw_AJmJko%2BzZZLxD%2BN4db5aZzaJ3T%3D7OH0NFLjALxeQm1A%40mail.

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

[Mason Freed]

On Tuesday, October 3, 2023 at 9:47:02 AM UTC-7 Luke wrote:

That makes perfect sense. For now I've removed the target milestones all 
together (they were rather arbitrary). But targeting 120 or 121 seems like 
a good idea. As for merging the spec change I think it should be ready to 
go assuming my response on the PR satisfies the question you had?


Thanks! I think it'd be good to explicitly target a milestone - perhaps 
121? And yes, thanks for your reply on the spec. It sounds like there is 
only a focus question remaining.

Thanks,
Mason

 

Thanks,
Luke

On Tuesday, 3 October 2023 at 17:34:15 UTC+1 mas...@chromium.org wrote:

I'm generally supportive of adding showPicker to select elements - it's a 
handy API for developers and it avoids some JS hacks. I do think we should 
a) land the spec changes , and b) 
allow some developer test time, before we ship this API. There were some 
bugs that got discovered while testing input.showPicker, so I'd like to 
leave some time for those to be found for select. Your chromestatus 
 lists M119 as the 
target shipping milestone, but the addition of the code 
 landed 
Sept 29, after the feature freeze for M119. Maybe we should instead target 
M120 or M121 to ship, at the earliest?

Thanks,
Mason  

On Tuesday, October 3, 2023 at 6:53:59 AM UTC-7 Luke wrote:



On Tuesday, 3 October 2023 at 14:43:23 UTC+1 yoav...@chromium.org wrote:

On Mon, Oct 2, 2023 at 4:40 AM Luke  wrote:

Contact emails
lukewa...@gmail.com, lu...@warlow.dev

Explainer
https://github.com/whatwg/html/pull/9754


Thanks for the explainer! :)

What's preventing us from landing the PR?

+Chris Harrelson - Can we mark Chromium as positive for WHATWG purposes?

I think it's just the needing two supporters, we have Gecko now and I was 
told Chrome would require this intent process. WebKit also don't seem 
opposed. 



Specification
https://whatpr.org/html/9754/input.html#dom-select-showpicker

Summary
Developers have been asking for a way to programmatically open the option 
picker of a select element. See https://www.google.com/search?
q=programmatically+open+select+site%3Astackoverflow.com

This is currently impossible in almost every browser. Providing 
showPicker() gives developers a supported way to do this. Following the 
pattern of input.showPicker().



Blink component
Blink>Forms

Search tags
showPicker

TAG review
https://github.com/w3ctag/design-reviews/issues/900


+Aaron Leventhal - Can you take a look at the a11y questions and see that 
a) the implementation behavior makes sense from your perspective b) that we 
have testing in place to make sure it stays that way.

Yeah it'd be great if the accessibility aspect could be reviewed (possibly 
in the wider context of input.showPicker too?) as for any missing tests I'm 
happy to add any that are needed. I think right now it's just the WPT 
tests. Wasn't sure how or if it was even possible to test further than 
that. 


TAG review status
Pending

Risks


Interoperability and Compatibility
For interoperability: This feature could end up not being implemented by 
all browsers, to mitigate this it's been filed as a HTML spec change with 
positions requested early to get everyone on board.

For compatibility: this feature is specified and designed to give browsers 
flexibility in whether they display a picker, or how they display it. 
Developers cannot observe either of these. Having said that all browsers 
implement pickers for select.



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


They closed it as "positive" :)


Updated the status dashboard entry. 

 


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/258)


Am I correct to read Anne's comment as slightly positive, but with some 
details left to flesh out?

Yeah my interpretation is "we're happy to implement provided the spec 
allows for iOS's system behaviour" (allowing optional focus of the 
input/select when showPicker is called). 

  


Web developers: No signals


You say above that "developers have been asking" for this. Anything we can 
point at?
Maybe Chrome devrel folks can help? +Thomas Steiner ?

https://github.com/whatwg/html/issues/7957 - the original issue that raised 
this provides some signal that this would be desired?  But if devrel could 
get something more concrete that'd be great. https://twitter.com/
quicksave2k/status/1420320560345661440 was used as the signal for 
input.showPicker() 


Other signals:

Ergonomics
There should be no ergonomic risks with this API.



Activation
This is as simple an API as possible so should be easy for developers to 
make use of. It also follows the existing pattern from the HTMLInputElement.



Security
This API can only be used with activation inside of top level or 
same-origin frames. This should avoid any potential sec

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

[Domenic Denicola]

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
> wrote:
>
> Contact emailsjap...@chromium.org, dome...@chromium.org, jarhar@chromium.
> org
>
> Explainerhttps://github.com/WICG/close-watcher/blob/main/README.md
>
> Specificationhttps://github.com/whatwg/html/pull/9462
>
> Summary
>
> "Close requests" are a new concept that encompasses user requests to close
> something currently open, using the Esc key on desktop or the back
> gesture/button on Android. Integrating them into Chromium comes with two
> changes: * CloseWatcher, a new API for directly listening and responding to
> close requests. * Upgrades to  and popover="" to use the new close
> request framework, so that they respond to the Android back butt

[blink-dev] Unstanding StyleSheet

[kalyani Shinde]

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/9e340326-77a6-4812-9d50-a99e1406d863n%40chromium.org.

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

[Illia Kyselov]

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

 We will roll-out to 100% of Stable users on approximately Sept. 
 20th, 2023.

 Thanks,
 Kyra

 On Thu, Aug 24, 2023 at 3:48 PM Mike Taylor  
 wrote:

> I've filed 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1475667 - 
> it would be great if you both could give more context about your 
> embedded 
> application, and how you deal with Safari and Firefox as comments in 
> the 
> bug (same goes for anyone else facing this issue).
>
> thanks,
> Mike
> On 8/24/23 8:45 AM, Tim Williams wrote:
>
> 

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

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

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

Contact emailsjap...@chromium.org, dome...@chromium.org, jar...@chromium.org

Explainerhttps://github.com/WICG/close-watcher/blob/main/README.md

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

Summary

"Close requests" are a new concept that encompasses user requests to close 
something currently open, using the Esc key on desktop or the back 
gesture/button on Android. Integrating them into Chromium comes with two 
changes: * CloseWatcher, a new API for directly listening and responding to 
close requests. * Upgrades to  and popover="" to use the new close 
request framework, so that they respond to the Android back button.


Blink componentBlink 


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

This API is designed to have an interoperable surface for web developers, 
to help them avoid platform-specific code. So, if it were implemented 
across browsers, it would be a positive for interoperability. Otherwise, it 
has the usual risks of not getting adopted by other vendors. Compatibility: 
To avoid allowing CloseWatchers, dialogs, and popovers ("close watchers") 
to prevent the Android back gesture/butto

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

[Yoav Weiss]

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 
*Sent:* Wednesday, September 20, 2023 8:58 AM
*To:* Anupam Snigdha 
*Cc:* Sangwhan Moon ; blink-dev@chromium.org <
blink-dev@chromium.org>; Sanket Joshi (EDGE) ; Evan 
Stade ; 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 <
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 
*Sent:* Monday, September 18, 2023 11:10 PM
*To:* Anupam Snigdha 
*Cc:* blink-dev@chromium.org ; Sanket Joshi (EDGE) <
sa...@microsoft.com>; Evan Stade ; jsb...@google.com <
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 <
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 by a particular browser.


Blink component 
Blink>DataTransfer 


Search tags 
asyncclipboard 

TAG review 
None


TAG review status 
Not applicable


Why is it not applicable? 



WebFeature UseCounter name 
kAsyncClipboardAPISupportsTypes

Risks 


Interoperability and Compatibility 

None


*Gecko*: Positive (https://github.com/w3c/clipboard-apis/issues/170#
issuecomment-1064240391)

*WebKit*: Positive (https://github.com/w3c/clipboard-apis/issues/170#
issuecomment-1064240391)

*Web developers*: Strongly positive (https://github.com/w3c/
clipboard-apis/issues/165#issuecomment-1197976360) Multiple Github issues 
were filed for this feature: https://github.com/w3c/
clipboard-apis/issues/165#issuecomment-1197976360 https:
//github.com/w3c/clipboard-apis/issues/67#issuecomment-650439507 
https://github.com/w3c/clipboard-apis/issues/

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

[Manuel Rego Casasnovas]

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 



Summary

Allows nested style rules
 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

.


Blink component

Blink>CSS




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

. 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 
[@chromium.org
 ]).

 2.

A style rule prelude (i.e. the selector list) can no
longer start with --ident:. Again, this is in a
sense already “invalid”, since HTML elements never
start with -- (including custom elements, which must
start with a letter), so such rules can never match
anything. This intent makes the situation a parse
error instead. Estimated impact: ~0.0007% (Web
  

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

[Yoav Weiss]

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

 Risks 


 Interoperability and Compatibility 


- Null report fixes: Increases the number of reports sent to 
reporting endpoints, reporting endpoints using plaintext debug payloads 
will need to handle the null report case. 

 Do you know if current reporting endpoints are ready to handle this 
>>> change? 
>>>

- Debug mode eligibility changes: Backwards incompatible for 
callers using enableDebugMode() without third-party cookie eligibility. 

 Were callers already ready to have the enableDebugMode() call fail? 
>>> Does it throw, or silently fails? 
>>>

- Padding report payloads: Compatible with existing aggregation 
service versions. Reporting endpoints will see larger payloads and null 
contributions added to the plaintext debug payloads (if used). 
- Reducing delay: Should not require any reporting endpoint 
changes, reports will simply arrive earlier. 


 *Gecko*: No signal (
 https://github.com/mozilla/sta

[blink-dev] Re: Intent to Ship: Intersection Observer Scroll Margin

[Yoav Weiss]

On Tuesday, September 26, 2023 at 1:10:34 AM UTC+2 Traian Captan wrote:

Contact emailstcap...@chromium.org

ExplainerNone

Specificationhttps://w3c.github.io/IntersectionObserver/#dom-
intersectionobserver-scrollmargin

Summary

Intersection Observer scrollMargin allows developers to observe targets 
inside nested scroll containers that are currently clipped away by the 
scroll containers. This is achieved by expanding the container's clipping 
rect by the scrollMargin when calculating the intersection. 


Blink componentBlink 


Search tagsIntersection Observer 
, 
scrollMargin 

TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None


*Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)

*WebKit*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)


Do you know of Gecko and WebKit's implementation plans for this?


*Web developers*: Positive (https://github.com/w3c/
IntersectionObserver/issues/431)

*Other signals*:

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?

None


Debuggability

N/A


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

Finch feature nameNone

Non-finch justification

This feature is behind an enabled-by-default flag that can be disabled if 
needed.


Requires code in //chrome?False

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

Estimated milestonesShipping on desktop119DevTrial on desktop119Shipping on 
Android119DevTrial on Android119Shipping on WebView119

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 Statushttps://chromestatus.com/
feature/5091020593430528

Links to previous Intent discussionsIntent to prototype: https://groups.
google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsWGzF5au6c5%
2BfVrh1hOCq_Y0rY0VF_bsmO8VVysg3QTg%40mail.gmail.com

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/0d1c17f5-86c7-430c-b64d-c97d4a04b777n%40chromium.org.

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

[Yoav Weiss]

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 this alternative fullscreen entrypoint.

 Ongoing technical constraints

 None

 Debuggability

 This feature utilizes the existing `windowFeatures` string parameter in 
 `window.open()` and does not modify any structured (i.e. WebIDL) API 
 surface. This feature will utilize existing fullscreen APIs which 
 developers can use for debugging (`document.fullscreenElement`, 
 `fullscreenchange`, and `fullscreenerror`, etc.), in the absence of an 
 `Element.requestFullscreen()` promise.

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

 No. This feature initially only applies to desktop platforms. Support 
 for mobile platforms may be considered in the future.

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

 Mostly. Automated web platform tests are limited to single displ

[blink-dev] Re: Intent to Deprecate and Remove: Same-origin blanket enforcement in CSPEE

[Yoav Weiss]

LGTM1

Usage seems low enough to make this safe still.

On Friday, September 29, 2023 at 2:24:11 AM UTC+2 Jun Kokatsu wrote:

> Contact emails
>
> jkoka...@google.com
>
> Explainer
>
> None
>
> Specification
>
> https://github.com/w3c/webappsec-cspee/pull/28/files
>
> Summary
>
> Removes a special treatment for same-origin iframes from CSP Embedded 
> Enforcement. This aligns the behavior of enforcing CSP Embedded Enforcement 
> for cross-origin iframes and same-origin iframes.
>
>
> Blink component
>
> Blink>SecurityFeature>ContentSecurityPolicy 
> 
>
> Motivation
>
> The same-origin blanket enforcement logic specific to same-origin iframes 
> exposes a new way to block certain resources from loading in the iframe. 
> This allowed an attack which was not possible before (example 
> ).
>  
>
>
>
> Additionally, this caused a bug 
>  where CSP nonce value 
> enforced by CSPEE from a top frame had to exactly match nonce value served 
> in grand-child frame, if the top frame and child frame are cross-origin, 
> but child frame and grand-child frame are same-origin. 
>
>
> Given this part of blanket enforcement is rarely used (~0.17% 
> ), 
> let's remove this logic.
>
>
> Initial public proposal
>
> None
>
> TAG review
>
> None
>
> TAG review status
>
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> None
>
>
> Gecko: Positive 
> 
>
> 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
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> Yes 
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> None
>
> Non-finch justification
>
> None
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1263288
>
> Estimated milestones
>
> M120
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5098158594195456
>
>

-- 
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/d968fa5a-7c9f-4c2e-9a42-8dd3e468fa63n%40chromium.org.

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

[Yoav Weiss]

On Friday, September 29, 2023 at 9:32:16 PM UTC+2 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?


We should definitely discuss this broader subject!
 


Adding others who I know are interested in this topic.

On Friday, September 29, 2023 at 9:16:13 AM UTC-7 Joey Arhar wrote:

The spec for the new syntax hasn't been merged yet, I haven't finished 
implementing it in chromium yet, and I don't have estimated milestones yet, 
but I'd like to get the API owners thoughts on whether this deprecation 
would be acceptable to help guide the spec discussion.

I did some analysis of the top 8 websites on the chromestatus entry to see 
what the breakage would be like: https://docs.google.com/docume
nt/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing
I found that most of them had the affected custom elements behind 
display:none rules that I had to manually remove in order to use them. 
There was only one website where there was actual breakage by default, in 
which case the carousel buttons didn't work on firefox and safari. 


Have Firefox and Safari implemented the new syntax?
 

If the new syntax is just for the CSS property and we keep CustomStateSet 
the same, then the affected website's buttons would continue to work but 
whatever custom styles they have (which I couldn't trigger) wouldn't apply 
anymore.

Personally, I think that this breakage would not be bad especially if we 
keep CustomStateSet the same, and I kind of like :state(foo) more than 
:--foo. However, I might have not made it clear in the spec discussions yet 
that we have already shipped :--foo by default for several years.


0.03% is not nothing. 1/8 ratio of breakage there is encouraging, but we'd 
probably need slightly broader sampling approach to get a sense of 
real-life breakage. (e.g. ~20 random sites)
 


On Fri, Sep 29, 2023 at 9:15 AM Joey Arhar  wrote:

Contact emailsjar...@chromium.org

ExplainerNone

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

Summary

CSS custom state, which allows custom elements to expose their own 
pseudo-classes, was shipped here: https://groups.google.com/a/ch
romium.org/g/blink-dev/c/dJibhmzE73o/m/VT-NceIhAAAJ

This feature has not been implemented in gecko or webkit yet. I recently 
made an effort to spec this feature in CSSWG and WHATWG, but there was 
pushback to change the syntax back from :--foo to :state(foo), and the 
CSSWG has resolved to do this as well: https://github.com/w3c/csswg-d
rafts/issues/4805

The UseCounter is currently at 0.03% https://chromestatus.com/metri
cs/feature/timeline/popularity/3796

This deprecation will have a window where we support both the old syntax 
and the new syntax so websites can switch to the new one.


Blink componentBlink>HTML>CustomElements 


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Websites which are currently using the old syntax and don't migrate to the 
new syntax will have CSS selectors which become invalid which would impact 
the styling of their custom elements.


*Gecko*: No signal

*WebKit*: No signal (https://github.com/whatwg/htm
l/pull/8467#issuecomment-1381645661)

*Web developers*: No signals

*Other signals*:

Activation

Switching to the new syntax should be quite easy.


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 justificationNone

Requires code in //chrome?False

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 Statushttps://chromestatus.com/featu
re/5140610730426368

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/

Re: [blink-dev] Intent to Ship: Accordion pattern using name attribute on elements

[Yoav Weiss]

On Fri, Sep 29, 2023 at 11:04 PM David Baron  wrote:

> Contact emailsdba...@chromium.org
>
> Explainerhttps://open-ui.org/components/accordion.explainer
>
> Specificationhttps://github.com/whatwg/html/pull/9400
>
> Summary
>
> This feature adds the ability to construct exclusive accordions using a
> sequence of HTML  elements. It adds a name attribute to the
>  element. When this attribute is used, multiple  elements
> that have the same name form a group. At most one element in the group can
> be open at once.
>

This looks great!!
The only tiny concern I have is the question of compatibility: Is it
possible that existing  elements share a name attribute?
Would it be possible for you to run a quick HTTPArchive scan and see this
is not a semi-common pattern?


>
> Blink componentBlink>HTML>Details
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/866 (design
> review)
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/831)
>
> *WebKit*: In development (
> https://github.com/WebKit/standards-positions/issues/209) positive
> standards position and code landed (although a little behind the most
> recent changes to the proposal)
>
> *Web developers*: No signals Got significant feedback from web developers
> in https://github.com/openui/open-ui/issues/812 . See examples of use on
> live sites in
> https://open-ui.org/components/accordion.explainer/#developer-demand-for-exclusive-accordion
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> no
>
>
> Debuggability
>
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name on chrome://flags
>
> Finch feature namekAccordionPattern
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1444057
>
> Availability expectationHoping to get cross-browser adoption relatively
> quickly (<12 months) given that it's a small feature that seems to be
> widely supported.
>
> Adoption expectationWider adoption may depend on also doing other
> changes, like improved stylability of  and  elements.
>
> Non-OSS dependencies
>
> Does the feature depend on any code or APIs outside the Chromium open
> source repository and its open-source dependencies to function?
> no
>
> Estimated milestones
> Shipping on desktop 120
> Shipping on Android 120
> Shipping on WebView 120
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> There may still be some small changes as part of the process of getting
> https://github.com/whatwg/html/pull/9400 finished, but I hope to
> implement those before shipping (at least those that happen soon).
>

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


>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6710427028815872
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/Q1OX6ZA_aaE/m/ALwkAOfHAwAJ
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3jdK2cMo8_hwyEFQLWUQ9W0xa60uy4wJnAMpZMdBApDfQ%40mail.gmail.com
> 
> .
>

-- 
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/CAL5BFfUsWEu0h%2BB2fbsvSHGK584ONf2AagTprKrmATgUuNjCmA%40mail.gmail.com.

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

[Anders Hartvoll Ruud]

On Mon, Oct 2, 2023 at 1:29 PM Anders Hartvoll Ruud 
wrote:

> Contact emails
>
> andr...@chromium.org
>
> Specification
>
> https://drafts.csswg.org/css-syntax/#consume-block-contents
>
> Summary
>
> Allows nested style rules
>  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 span selector 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
> .
>
> Blink component
>
> Blink>CSS
> 
>
> 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 when it becomes
>invalid. With this intent, e.g. color: var(--x) {}; becomes invalid
>parse-time instead of at computed-value time
>.
>This is an 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
>
> 
>[@chromium.org]).
>2.
>
>A style rule prelude (i.e. the selector list) can no longer start with
>--ident:. Again, this is in a sense already “invalid”, since HTML
>elements never start with -- (including custom elements, which must start
>with a letter), so such rules can never match anything. This intent makes
>the situation a parse error instead. Estimated impact: ~0.0007% (Web
>Compat Analysis: Relaxed Nesting
>
> 
>[@chromium.org]).
>
>
> Gecko: Shipped/Shipping (
> https://www.mozilla.org/en-US/firefox/117.0/releasenotes)
>
> WebKit: In development (https://github.com/WebKit/WebKit/pull/17189)
>

Also from WebKit (Jen Simmons):
https://webkit.org/blog/14571/css-nesting-and-the-cascade/


>
> 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
>
> Nested style rules that start with identifiers appear in the inspector
> like other nested style rules.
>
>
> 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
>
> The tests exist in wpt_internal/css/css-nesting/ident at the time of
> writing, but will be upstreamed when the feature is turned on.
>
> Flag name on chrome://flags
>
> CSSNestingIdent
>
> Finch feature name
>
> I’m not sure what a “Finch feature name” is. There have been no Finch
> trials related to this, but the feature is guarded by the Blink runtime
> flag “CSSNestingIdent” with “base_feature” unset, which automatically
> generates a corresponding base::Feature.
>
> Non-finch justification
>
> None
>
> Requires code in //chrome?
>
> False
>
> Estimated milestones
>
> Shipping on desktop
>
> 120
>
> Shipping on Android
>
> 120
>
> Shipping on WebView
>
> 120
>
>
>
> Anticipated spec changes
>
> These issues need to be resolved and/or edited into the spec before
> shipping.
>
>
>-
>
>https://github.com/w3c/csswg-drafts/issues/9317
>The behavior that braces are invalid in standard properties (unless
>it’s the whole value) was resolved at TPAC 2023, but css-syntax has not
>been updated yet.
>-
>
>https://github.com/w3c/csswg-drafts/issues/9336
>This is a tweak to the error recovery of the --ident: case. This needs
>a resolution, and an edit.
>
>
> There are no anticipated spec changes after shipping.
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5070369895743488
>
> This intent message was generated by Chrome Platform Status
> 

[blink-dev] Re: Intent to Ship: CSS Syntax for registered Custom Properties

[Rune Lillesveen]

On Wed, Oct 4, 2023 at 11:08 AM Rune Lillesveen 
wrote:

> Contact emailsfuth...@chromium.org, andr...@chromium.org
>
> ExplainerNone
>
> Specification
> https://drafts.css-houdini.org/css-properties-values-api-1/#syntax-strings
>
> Summary
>
> Supports using the  syntax for custom properties registered with
> @property or registerProperty(). The  syntax can be used to restrict
> values of the custom property to url() values and generated images like
> gradients.
>
>
> This syntax was initially excluded from the valid syntaxes mainly because
> images were not interpolable and that it would add to the usefulness of the
> syntax to be able to interpolate directly on the custom property. The other
> engines have shipped the image syntax without supporting interpolation.
> There are two interpolation methods in css-image-4, cross-fade() and per
> stop interpolation for gradients. The gradient interpolation is not shipped
> by any browser (even for standard properties). Safari ships a non-standard
> compliant cross-fade() interpolation for standard properties (at least for
> background-image), but not for the registered custom properties.
>
>
> We have an OKR to look into cross-fade() for Q4. If we end up shipping
> that, it will work for both registered custom properties and standard
> properties.
>
>
> The  syntax for registered custom properties is part of Interop
> 2023.
>
>
> Blink componentBlink>CSS
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Shipped/Shipping Does not support interpolation
>

Sorry, this is not correct. It's implemented behind a flag, not shipping
yet.

*WebKit*: Shipped/Shipping Does not support interpolation
>
> *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
>
> No additional devtools support necessary compared to existing syntaxes.
>
>
> 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/css/css-properties-values-api/at-property.html
> https://wpt.fyi/css/css-properties-values-api/register-property-syntax-parsing.html
> https://wpt.fyi/css/css-properties-values-api/typedom.html
>
>
> Flag name on chrome://flags#enable-experimental-web-platform-features
>
> Finch feature nameCSSVariables2ImageValues
>
> Requires code in //chrome?False
>
> Estimated milestones
> Shipping on desktop 120
> DevTrial on desktop 115
> Shipping on Android 120
> DevTrial on Android 115
>
> 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/5142205606133760
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> Rune Lillesveen
>
>

-- 
Rune Lillesveen

-- 
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/CACuPfeRpL_rGG0%2BuaCiozmx6PoShU4H4SY8HaZwCKs8aReKnUg%40mail.gmail.com.

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

[Yoav Weiss]

Thanks for clarifying and verifying! :) My LGTM still stands.

On Wed, Oct 4, 2023 at 11:48 AM Anders Hartvoll Ruud 
wrote:

>
>
> On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud 
> wrote:
>
>> On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss  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 <
>>> andr...@chromium.org> wrote:
>>>
 Contact emails

 andr...@chromium.org

 Specification

 https://drafts.csswg.org/css-syntax/#consume-block-contents

 Summary

 Allows nested style rules
  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 span selector 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
 .

 Blink component

 Blink>CSS
 

 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 when it
becomes invalid. With this intent, e.g. color: var(--x) {}; becomes
invalid parse-time instead of at computed-value time

 .
This is an 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

 
[@chromium.org]).
2.

A style rule prelude (i.e. the selector list) can no longer start
with --ident:. Again, this is in a sense already “invalid”, since
HTML elements never start with -- (including custom elements, which must
start with a letter), so such rules can never match anything. This 
 intent
makes the situation a parse error instead. Estimated impact: ~0.0007% 
 (Web
Compat Analysis: Relaxed Nesting

 
[@chromium.org]).


 Gecko: Shipped/Shipping (
 https://www.mozilla.org/en-US/firefox/117.0/releasenotes)

 WebKit: In development (https://github.com/WebKit/WebKit/pull/17189)

 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

 Nested style rules that start with identifiers appear in the inspector
 like other nested style rules.


 Will this feature be supported on all six Blink platform

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

[Anders Hartvoll Ruud]

On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud 
wrote:

> On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss  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 
>> wrote:
>>
>>> Contact emails
>>>
>>> andr...@chromium.org
>>>
>>> Specification
>>>
>>> https://drafts.csswg.org/css-syntax/#consume-block-contents
>>>
>>> Summary
>>>
>>> Allows nested style rules
>>>  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 span selector 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
>>> .
>>>
>>> Blink component
>>>
>>> Blink>CSS
>>> 
>>>
>>> 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 when it
>>>becomes invalid. With this intent, e.g. color: var(--x) {}; becomes
>>>invalid parse-time instead of at computed-value time
>>>.
>>>This is an 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
>>>
>>> 
>>>[@chromium.org]).
>>>2.
>>>
>>>A style rule prelude (i.e. the selector list) can no longer start
>>>with --ident:. Again, this is in a sense already “invalid”, since
>>>HTML elements never start with -- (including custom elements, which must
>>>start with a letter), so such rules can never match anything. This intent
>>>makes the situation a parse error instead. Estimated impact: ~0.0007% 
>>> (Web
>>>Compat Analysis: Relaxed Nesting
>>>
>>> 
>>>[@chromium.org]).
>>>
>>>
>>> Gecko: Shipped/Shipping (
>>> https://www.mozilla.org/en-US/firefox/117.0/releasenotes)
>>>
>>> WebKit: In development (https://github.com/WebKit/WebKit/pull/17189)
>>>
>>> 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
>>>
>>> Nested style rules that start with identifiers appear in the inspector
>>> like other nested style rules.
>>>
>>>
>>> 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
>>>
>>> The tests exist in wpt_internal/css/css-nesting/ident at 

Re: [blink-dev] Intent to Ship: CSS :dir() pseudo-class selector

[Manuel Rego Casasnovas]

LGTM1

Just for context, this was already approved 3 years ago:
https://groups.google.com/a/chromium.org/g/blink-dev/c/p0Wc66rbVOc/m/khHJ0dSsAwAJ

But then we realized the spec text was not ready, there were some 
misunderstandings and things got blocked on that.


Big thanks to push this to the finish line!

Cheers,
  Rego

On 03/10/2023 20:37, David Baron wrote:


Contact emails

dba...@chromium.org , dizha...@chromium.org 
, myid.s...@igalia.com 




Explainer

None


Specification

https://www.w3.org/TR/selectors-4/#the-dir-pseudo 




Summary

The :dir() CSS pseudo-class selector matches elements based on 
directionality, which is determined based on the HTML dir attribute. 
:dir(ltr) matches left-to-right text directionality, and :dir(rtl) 
matches elements with right-to-left text directionality. It is not 
equivalent to [dir] attribute selectors because it matches against 
directions inherited from an ancestor with the dir attribute, and 
because it matches against the direction computed from use of dir=auto 
(which determines directionality from the first character in the text 
with strong directionality).




Blink component

Blink>CSS 




TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

This is largely an additive feature. However, as part of the process of 
preparing to ship the feature, we worked on more clearly specifying 
exactly how directionality in HTML works, and particularly how it 
interacts with shadow DOM. This work is occurring in 
https://github.com/whatwg/html/issues/3699 
 
https://github.com/whatwg/html/pull/9554 
 and 
https://github.com/whatwg/html/pull/9796 
 . Since these changes to HTML 
directionality also affect the dirname attribute (which is a form 
submission feature), they have been implemented behind the same flag as 
the pseudo-class. However, they are likely to be low risk because the 
recommended way of using the dirname attribute is to use dir=auto on the 
same element as the dirname attribute, and that usage pattern should not 
be affected. This feature is part of Interop2023's focus area on CSS 
Pseudo-classes: https://wpt.fyi/interop-2023 




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


/WebKit/: Shipped/Shipping 
(https://bugs.webkit.org/show_bug.cgi?id=64861 
) Supported as of Safari 
16.4 according to https://caniuse.com/css-dir-pseudo 



/Web developers/: No signals

/Other signals/: CSSWG consensus to ship documented in 
https://www.w3.org/TR/css-2017/#experimental 
 (CSSWG includes reps from 
all major browser vendors)



WebView application risks

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


no



Debuggability

Same as other pseudo-classes



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

No


Is this feature fully tested by web-platform-tests

?

Yes

WPT test plan (somewhat out of date, since recent CLs have added many 
tests) at https://github.com/web-platform-tests/wpt/issues/25569 
 Existing tests 
have names starting with "dir" in https://wpt.fyi/results/css/selectors 
 and 
https://wpt.fyi/results/html/dom/elements/global-attributes 
 PR for 
testing shadow DOM interaction at 
https://github.com/web-platform-tests/wpt/pull/29820 
 which will add 
additional tests




Flag name on chrome://flags



Finch feature name

kCSSPseudoDir


Requires code in //chrome?

False


Tracking bug

https://code.google.com/p/chromium/issues/detail?id=576815 




Availability expectation

Available in all major browsers once we ship.


Sample links


https://jsfiddle.net/fxc9a8uc/1 


Estimated milestones

Shipping on desktop 120

Shipping on Android 120

Shipping on WebView 120



An

[blink-dev] Intent to Ship: CSS Syntax for registered Custom Properties

[Rune Lillesveen]

Contact emailsfuth...@chromium.org, andr...@chromium.org

ExplainerNone

Specification
https://drafts.css-houdini.org/css-properties-values-api-1/#syntax-strings

Summary

Supports using the  syntax for custom properties registered with
@property or registerProperty(). The  syntax can be used to restrict
values of the custom property to url() values and generated images like
gradients.


This syntax was initially excluded from the valid syntaxes mainly because
images were not interpolable and that it would add to the usefulness of the
syntax to be able to interpolate directly on the custom property. The other
engines have shipped the image syntax without supporting interpolation.
There are two interpolation methods in css-image-4, cross-fade() and per
stop interpolation for gradients. The gradient interpolation is not shipped
by any browser (even for standard properties). Safari ships a non-standard
compliant cross-fade() interpolation for standard properties (at least for
background-image), but not for the registered custom properties.


We have an OKR to look into cross-fade() for Q4. If we end up shipping
that, it will work for both registered custom properties and standard
properties.


The  syntax for registered custom properties is part of Interop 2023.


Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None


*Gecko*: Shipped/Shipping Does not support interpolation

*WebKit*: Shipped/Shipping Does not support interpolation

*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

No additional devtools support necessary compared to existing syntaxes.


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/css/css-properties-values-api/at-property.html
https://wpt.fyi/css/css-properties-values-api/register-property-syntax-parsing.html
https://wpt.fyi/css/css-properties-values-api/typedom.html


Flag name on chrome://flags#enable-experimental-web-platform-features

Finch feature nameCSSVariables2ImageValues

Requires code in //chrome?False

Estimated milestones
Shipping on desktop 120
DevTrial on desktop 115
Shipping on Android 120
DevTrial on Android 115

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

This intent message was generated by Chrome Platform Status
.

-- 
Rune Lillesveen

-- 
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/CACuPfeRmvmaqY%3DR8fx1%3Dr_ezTjevZR%3DyAg82E9Z3w8YXBB%2Bo_A%40mail.gmail.com.