[blink-dev] Intent to Prototype: baseline-source

[Ian Kilpatrick]

Contact emailsikilpatr...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/css-inline-3/#baseline-source

Summary

The "baseline-source" properties allows web developers to specify if an
inline-level box should use the "first" or "last" baseline for alignment
within an linebox. Today the default behaviour is confusing for web
developers. Consider: test line1line2 test line1line2 The "inline-block" will align to the
last baseline, and the "inline-flex" will align to the first baseline.
"baseline-source: auto" is the existing (confusing) behaviour. Web
developers can specify "baseline-source: first" or "baseline-source: last"
to directly determine how they want these boxes to align within a line-box.


Blink componentBlink>Layout>Inline


Motivation

>From changes to last/first baseline features we've received requests from
web developers to have more precise control over which baseline to use for
alignment within a line-box.

Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Positive - see motivation above.

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



Debuggability



Is this feature fully tested by web-platform-tests

?Not yet we'll be adding a full suite of tests in
css/css-inline/baseline-source

Flag nameCSSBaselineSource

Requires code in //chrome?False

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

Estimated milestones

No milestones specified


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

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/CAJL3UpRe9mDOH4EV_-mo_-7NQL1cTZksivfs8X2oRHJ89YX82g%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: *Streaming* declarative shadow DOM

[Alex Russell]

On Friday, December 9, 2022 at 9:31:22 AM UTC-8 Mason Freed wrote:

> On Thu, Dec 8, 2022 at 11:28 PM Alex Russell  
> wrote:
>
>> In general, we should not agree to changes that are purely cosmetic after 
>> shipping, and spec PR conversations aren't a substitute for developer 
>> feedback.
>>
>> I'm disinclined to suggest we ship a renamed feature for purely editorial 
>> reasons. Can we proceed to test under the old names to detect possible 
>> breakage?
>>
>
> I do see your point, and I wish we'd had these conversations (about naming 
> and behavior) 2+ years ago when I tried very hard to engage with the other 
> implementers. Having said that, one nice thing about the new name is that 
> it gives a compat-guaranteed path to streaming. And of the two changes 
> (streaming, and a new name), I think there is ample evidence that 
> developers care a lot about streaming, and likely don't care what the 
> attribute is called, other than typing 4 more characters. There will be 
> some migration pain, for sure, but it's probably worth it for an 
> interoperable standard and no compat risk.
>

So is the concrete proposal that Blink support attributes in perpetuity? 
With different behaviour? Or the same behaviour? And/or that we do a 
deprecation/removal for the old attribute name?

In general, when the API OWNERs give the go-ahead for something to ship out 
ahead of other vendors, particularly when we have worked diligently (as you 
have) to engage folks with no response, we're staking your claim to the 
shipped system. Not only did you reach out, but you ran public OTs, 
discussed at TPAC (among other venues), and did everything I can think of 
to ground this design in data and developer needs.

It's traumatic for the ecosystem for us to flip-flop (see my mistake w/ WC 
v0 vs v1 incompatibility), and so we shouldn't do this if there's not an 
overwhelming reason to do so. Generally, the best stance in this situation 
is "*ok, we tried, you didn't show up, compatible additions only from here 
on out*". Renaming in response to multi-year delays in engagement, after 
years of developer enthusiasm for a feature, only rewards hostage taking 
behaviour from trailing projects

Best,

Alex
 

> Side-note: there is also an ongoing conversation 
>  (also 
> here ) over 
> the developer need for a synchronous parsing entry point for DSD. I'm 
> hopeful we'll reach consensus to *keep* this feature, interoperably. But 
> if folks on this thread have compelling use cases for the ability to use 
> DOMParser to parse DSD content, please comment here 
> .
>
> Thanks for the comments!
>
> Mason
>
>  
>
>> Thanks,
>>
>> Alex
>>
>> On Wednesday, December 7, 2022 at 5:46:20 PM UTC-8 Mason Freed wrote:
>>
>>> On Wed, Dec 7, 2022 at 5:33 PM Alex Russell  
>>> wrote:
>>>
 +1; great news on the streaming front.

 On the potential attribute name change, is it not possible to introduce 
 streaming behaviour under the old name?

>>>
>>> Thanks! Yes, it's totally possible to introduce streaming without 
>>> changing the attribute name. But in the spec PR conversations, keeping the 
>>> old name seems to be a non-starter. The issue is that the IDL reflection, 
>>> `shadowRoot`, shadows (ha!) the Element.shadowRoot attribute, and causes 
>>> some ambiguity. It's not a practical problem for developers, since 
>>> HTMLTemplateElement.shadowRoot is always null and is relatively useless. 
>>> But for consistency, the editors wanted a name change, to something that 
>>> can just reflect the string values ("open" and "closed") directly.
>>>
>>> Thanks,
>>> Mason
>>>
>>>
>>>  
>>>
 Best,

 Alex

 On Tuesday, December 6, 2022 at 10:24:20 PM UTC-8 yoav...@chromium.org 
 wrote:

> Great news!! :)
>
> On Tue, Dec 6, 2022 at 7:05 PM Mason Freed  
> wrote:
>
>> Contact emailsmason...@google.com
>>
>> Explainerhttps://github.com/whatwg/html/pull/5465
>> https://github.com/whatwg/dom/pull/892
>>
>> Specificationhttps://github.com/whatwg/html/pull/5465
>>
>> Summary
>>
>> Chromium has shipped [1] a version of declarative shadow DOM in M90 
>> which currently has 0.002% usage [2]. Mostly, that low usage is due to 
>> the 
>> spec PR being stalled with no input from other implementers. Recently, 
>> there has been renewed interest in the feature, and discussions have 
>> resumed. As part of those discussions, two changes are being requested: 
>> 1. 
>> Rename the `` attribute from `shadowroot` to `shadowrootmode`. 
>> 2. 
>> Support streaming, by attaching the shadow root on the opening, rather 
>> than 
>> the closing, template tag. Chromium would like to prototype these 
>> changes. 
>> [1] https://chromes

Re: [blink-dev] Intent to Prototype: *Streaming* declarative shadow DOM

[Mason Freed]

On Thu, Dec 8, 2022 at 11:28 PM Alex Russell 
wrote:

> In general, we should not agree to changes that are purely cosmetic after
> shipping, and spec PR conversations aren't a substitute for developer
> feedback.
>
> I'm disinclined to suggest we ship a renamed feature for purely editorial
> reasons. Can we proceed to test under the old names to detect possible
> breakage?
>

I do see your point, and I wish we'd had these conversations (about naming
and behavior) 2+ years ago when I tried very hard to engage with the other
implementers. Having said that, one nice thing about the new name is that
it gives a compat-guaranteed path to streaming. And of the two changes
(streaming, and a new name), I think there is ample evidence that
developers care a lot about streaming, and likely don't care what the
attribute is called, other than typing 4 more characters. There will be
some migration pain, for sure, but it's probably worth it for an
interoperable standard and no compat risk.

Side-note: there is also an ongoing conversation
 (also here
) over the
developer need for a synchronous parsing entry point for DSD. I'm hopeful
we'll reach consensus to *keep* this feature, interoperably. But if folks
on this thread have compelling use cases for the ability to use DOMParser
to parse DSD content, please comment here
.

Thanks for the comments!

Mason



> Thanks,
>
> Alex
>
> On Wednesday, December 7, 2022 at 5:46:20 PM UTC-8 Mason Freed wrote:
>
>> On Wed, Dec 7, 2022 at 5:33 PM Alex Russell 
>> wrote:
>>
>>> +1; great news on the streaming front.
>>>
>>> On the potential attribute name change, is it not possible to introduce
>>> streaming behaviour under the old name?
>>>
>>
>> Thanks! Yes, it's totally possible to introduce streaming without
>> changing the attribute name. But in the spec PR conversations, keeping the
>> old name seems to be a non-starter. The issue is that the IDL reflection,
>> `shadowRoot`, shadows (ha!) the Element.shadowRoot attribute, and causes
>> some ambiguity. It's not a practical problem for developers, since
>> HTMLTemplateElement.shadowRoot is always null and is relatively useless.
>> But for consistency, the editors wanted a name change, to something that
>> can just reflect the string values ("open" and "closed") directly.
>>
>> Thanks,
>> Mason
>>
>>
>>
>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Tuesday, December 6, 2022 at 10:24:20 PM UTC-8 yoav...@chromium.org
>>> wrote:
>>>
 Great news!! :)

 On Tue, Dec 6, 2022 at 7:05 PM Mason Freed  wrote:

> Contact emailsmason...@google.com
>
> Explainerhttps://github.com/whatwg/html/pull/5465
> https://github.com/whatwg/dom/pull/892
>
> Specificationhttps://github.com/whatwg/html/pull/5465
>
> Summary
>
> Chromium has shipped [1] a version of declarative shadow DOM in M90
> which currently has 0.002% usage [2]. Mostly, that low usage is due to the
> spec PR being stalled with no input from other implementers. Recently,
> there has been renewed interest in the feature, and discussions have
> resumed. As part of those discussions, two changes are being requested: 1.
> Rename the `` attribute from `shadowroot` to `shadowrootmode`. 
> 2.
> Support streaming, by attaching the shadow root on the opening, rather 
> than
> the closing, template tag. Chromium would like to prototype these changes.
> [1] https://chromestatus.com/feature/5191745052606464 [2]
> https://chromestatus.com/metrics/feature/timeline/popularity/3196
>
>
> Blink componentBlink>DOM>ShadowDOM
> 
>
> Motivation
>
> Developers have always wanted declarative shadow DOM to support
> streaming, but other implementers were always opposed to making the
> required changes to the HTML parser. Recently, those concerns were 
> changed,
> and other implementations proceeded with a streaming prototype.
>
>
> Initial public proposal
>
> Search tagsdeclarative
> , shadow
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> The new version of declarative shadow DOM has observable differences
> in behavior. The plan for prototyping the new approach while keeping the
> functionality of the old approach is to trigger the new streaming behavior
> based on the presence of the new attribute `shadowrootmode`. If the (old)
> `shadowroot` attribute is used, the old non-streaming behavior will be
> used. This should ensure there are no compat ri

[blink-dev] Re: Intent to Deprecate and Remove: WebSQL in non-secure contexts

[Carl Turechek]

I'd rather websql wasn't removed. I use it for a few non-web applications 
making it possible to have a one click app with a database without too much 
hassle. Having to roll your own with web assembly sounds like it wouldn't 
be worth the trouble.

On Thursday, May 26, 2022 at 8:18:38 PM UTC-4 ay...@chromium.org wrote:

>
> *Contact emails*ay...@chromium.org, jsb...@chromium.org, 
> ajayra...@google.com  
>
>
> *Specification*https://www.w3.org/TR/webdatabase/
>
>
> *Summary*We intend to deprecate and remove usage of WebSQL in non-secure 
> contexts. Deprecation is targeted for M105 and removal is targeted for M107.
>
>
> *Blink component*Blink>Storage>WebSQL 
> 
>
>
> *Motivation*The Web SQL Database standard was first proposed in April 
> 2009 and abandoned in November 2010. Gecko never implemented this feature 
> and WebKit deprecated this feature in 2019 
> .
>  
> The W3C encouraged those needing web databases to adopt Web Storage 
>  or Indexed Database 
> .
>
> WebSQL has been deprecated and removed 
>  for 
> third-party contexts in M97.
>
> We hope to entirely deprecate and remove WebSQL at some future point when 
> usage is low enough.
>
>
> *TAG review*N/A
>
> Risks
> Based on usage measurements 
>  
> rolled out in M97, 0.005% of page loads use WebSQL in a non-secure 
> context.  Less than 0.01% of top sites have adopted this feature.
>
> Out of the 20 top sites listed for the month of April 2022, 11 of the 
> sites use a feature detection library Modernizr 1.5 
> , on a version released in 2010. 
> This would create a test database to check feature availability. I was 
> unable to reproduce the creation of other WebSQL databases outside of the 
> one created by Modernizr on these sites. 4 sites that seem to use an outdated 
> private mode detection script  
> which was intended for older versions of iOS. All the scripts I have found 
> checked if window.openDatabase existed before usage, likely due to the lack 
> of support in Gecko and WebKit. 
>
> Interoperability and Compatibility
>
> Gecko: Never implemented
>
> WebKit: Deprecation shipped in iOS 13 and Safari 13 
>   
>
> Web developers: No signals
>
>
> *Debuggability*N/A
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
> Not fully, one test 
> 
>  
> checks the availability of the feature.
>
>
> *Tracking bug*https://crbug.com/1212492
>
> Link to related intents
> Intent to Deprecate and Remove: WebSQL in third-party contexts 
> 
>
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5175124599767040
>
>
>

-- 
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/7f5ce439-914f-4aa0-8a2a-776a08addd1dn%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

[Carl Turechek]

You'll break an app I developed to be passed around as a single html file. 
Hope you'll provide us plebs some guidance on finding a replacement 
solution.

On Wednesday, November 16, 2022 at 1:22:34 PM UTC-5 mo...@google.com wrote:

> I've done a more thorough search for examples of webkitStorageInfo and of 
> WebSQL in insecure contexts on the web. Among the top 10K sites, the only 
> usage I found was from standard libraries - and, in these cases, removal 
> wouldn't cause an error or affect any functionality.
>
> No one in Enterprise at Google, Microsoft, or Salesforce has uncovered 
> usage among their partners either.
>
>
> On Mon, Nov 14, 2022 at 11:51 AM 'Thomas Steiner' via blink-dev <
> blin...@chromium.org> wrote:
>
>> The developer-facing documentation is being updated in 
>> https://github.com/GoogleChrome/developer.chrome.com/pull/4299.
>>
>> On Sat, Nov 12, 2022 at 12:26 AM Ayu Ishii  wrote:
>>
>>> We've done some extra communications with enterprise partners and have 
>>> come up with a new target milestone.
>>> The new target milestone for this removal is M110, with enterprise 
>>> policy available for 2 milestones (M110-111).
>>>
>>> Thanks!
>>> Ayu
>>>
>>> On Wednesday, June 1, 2022 at 7:49:00 PM UTC-7 Ayu Ishii wrote:
>>>
 Thank you all for the approvals!
 And thank you miketaylr@ for the HTTPArchive analysis!

 On Wednesday, June 1, 2022 at 1:12:55 PM UTC-7 Mike Taylor wrote:

> On 6/1/22 3:52 PM, Yoav Weiss wrote:
>
> LGTM3
>
> On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor  
> wrote:
>
>> On 6/1/22 1:34 PM, Chris Harrelson wrote:
>>
>>
>> On Tue, May 31, 2022 at 8:26 PM Ayu Ishii  wrote:
>>
>>> Hi Mike!
>>>
>>> With the current usage measurements we see, we hadn't considered any 
>>> enterprise policy for opt-out.
>>> But certainly can follow the process to do so if you feel that there 
>>> may be risk of undercounting. 
>>> Deprecation of WebSQL in third-party contexts added a policy that 
>>> lasted 3 milestones after deprecation before full removal as an example.
>>> Although the usages were quite different from that deprecation, we 
>>> can follow the same process if this sounds reasonable.
>>>
>>
>> I think this plan sounds good. LGTM1 once you have an enterprise 
>> opt-out in place that will remain for 3 milestones. Also please make 
>> sure 
>> to communicate this change in the enterprise notes and other 
>> communication 
>> channels.
>>
>> A couple of notes I took last Friday and forgot to post:
>>
>> I dumped the list of sites from HTTPArchive (query below) and after 
>> de-duping them, ended up with 835 sites.
>>
>> I then ran a script which naively looks at response codes, and got 
>> the following results:
>>
>> 2XX count: 685/835
>> 3XX to HTTP endpoint count: 74/835
>> 4XX count: 3/835
>> 5XX count: 2/835
>>
>> So, from this dataset, roughly 9% of those redirect to an HTTP 
>> endpoint.
>>
> This should say HTTPS, not HTTP. I am bad at typing.
>
> That said, I think reducing risk of breakage for enterprise 
>> environments is a useful and friendly thing to do. LGTM2 w/ that done.
>>
>> SELECT
>>   rank,
>>   url,
>> FROM
>>   `httparchive.blink_features.features`
>> WHERE feature = 'OpenWebDatabaseInsecureContext'
>> ORDER BY rank ASC
>>
>>  
>>
>>>
>>> - Ayu
>>>
>>> On Monday, May 30, 2022 at 10:57:01 PM UTC-7 Mike West wrote:
>>>
 I'm happy to see this moving forward, thanks for pushing it ahead! 

 That said, this seems like the kind of thing that's likely-enough 
 to impact enterprise that we should include a temporary opt-out to 
 give 
 ourselves some wiggle room if it turns out that we're undercounting 
 usage. 
 Have y'all already put something like that together?

 -mike


 On Fri, May 27, 2022 at 2:18 AM Ayu Ishii  
 wrote:

>
> *Contact emails *ay...@chromium.org, jsb...@chromium.org, 
> ajayra...@google.com  
>
>
> *Specification *https://www.w3.org/TR/webdatabase/
>
>
> *Summary *We intend to deprecate and remove usage of WebSQL in 
> non-secure contexts. Deprecation is targeted for M105 and removal is 
> targeted for M107.
>
>
> *Blink component *Blink>Storage>WebSQL 
> 
>
>
> *Motivation *The Web SQL Database standard was first proposed in 
> April 2009 and abandoned in November 2010. Gecko never implemented 
> this 
> feature and WebKit deprecated this feature in 2019 
> 

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

[Carl Turechek]

I don't think that the increased security will have an effect on my app, 
but the removal all together is my concern. Sorry if I haven't been clear 
enough.

On Thursday, December 8, 2022 at 7:28:58 PM UTC-5 mo...@google.com wrote:

> Yes. Carl, does your app depend on Web SQL, webkitStorageInfo, or 
> something else?
>
> On Thu, Dec 8, 2022 at 6:55 PM Carl Turechek  wrote:
>
>> You'll break an app I developed to be passed around as a single html 
>> file. Hope you'll provide us plebs some guidance on finding a replacement 
>> solution.
>
>
>>
>> On Wednesday, November 16, 2022 at 1:22:34 PM UTC-5 mo...@google.com 
>> wrote:
>>
>>> I've done a more thorough search for examples of webkitStorageInfo and 
>>> of WebSQL in insecure contexts on the web. Among the top 10K sites, the 
>>> only usage I found was from standard libraries - and, in these cases, 
>>> removal wouldn't cause an error or affect any functionality.
>>>
>>> No one in Enterprise at Google, Microsoft, or Salesforce has uncovered 
>>> usage among their partners either.
>>>
>>>
>>> On Mon, Nov 14, 2022 at 11:51 AM 'Thomas Steiner' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 The developer-facing documentation is being updated in 
 https://github.com/GoogleChrome/developer.chrome.com/pull/4299.

 On Sat, Nov 12, 2022 at 12:26 AM Ayu Ishii  wrote:

> We've done some extra communications with enterprise partners and have 
> come up with a new target milestone.
> The new target milestone for this removal is M110, with enterprise 
> policy available for 2 milestones (M110-111).
>
> Thanks!
> Ayu
>
> On Wednesday, June 1, 2022 at 7:49:00 PM UTC-7 Ayu Ishii wrote:
>
>> Thank you all for the approvals!
>> And thank you miketaylr@ for the HTTPArchive analysis!
>>
>> On Wednesday, June 1, 2022 at 1:12:55 PM UTC-7 Mike Taylor wrote:
>>
>>> On 6/1/22 3:52 PM, Yoav Weiss wrote:
>>>
>>> LGTM3
>>>
>>> On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor  
>>> wrote:
>>>
 On 6/1/22 1:34 PM, Chris Harrelson wrote:


 On Tue, May 31, 2022 at 8:26 PM Ayu Ishii  
 wrote:

> Hi Mike!
>
> With the current usage measurements we see, we hadn't considered 
> any enterprise policy for opt-out.
> But certainly can follow the process to do so if you feel that 
> there may be risk of undercounting. 
> Deprecation of WebSQL in third-party contexts added a policy that 
> lasted 3 milestones after deprecation before full removal as an 
> example.
> Although the usages were quite different from that deprecation, we 
> can follow the same process if this sounds reasonable.
>

 I think this plan sounds good. LGTM1 once you have an enterprise 
 opt-out in place that will remain for 3 milestones. Also please make 
 sure 
 to communicate this change in the enterprise notes and other 
 communication 
 channels.

 A couple of notes I took last Friday and forgot to post:

 I dumped the list of sites from HTTPArchive (query below) and after 
 de-duping them, ended up with 835 sites.

 I then ran a script which naively looks at response codes, and got 
 the following results:

 2XX count: 685/835
 3XX to HTTP endpoint count: 74/835
 4XX count: 3/835
 5XX count: 2/835

 So, from this dataset, roughly 9% of those redirect to an HTTP 
 endpoint.

>>> This should say HTTPS, not HTTP. I am bad at typing.
>>>
>>> That said, I think reducing risk of breakage for enterprise 
 environments is a useful and friendly thing to do. LGTM2 w/ that done.

 SELECT
   rank,
   url,
 FROM
   `httparchive.blink_features.features`
 WHERE feature = 'OpenWebDatabaseInsecureContext'
 ORDER BY rank ASC

  

>
> - Ayu
>
> On Monday, May 30, 2022 at 10:57:01 PM UTC-7 Mike West wrote:
>
>> I'm happy to see this moving forward, thanks for pushing it 
>> ahead! 
>>
>> That said, this seems like the kind of thing that's likely-enough 
>> to impact enterprise that we should include a temporary opt-out to 
>> give 
>> ourselves some wiggle room if it turns out that we're undercounting 
>> usage. 
>> Have y'all already put something like that together?
>>
>> -mike
>>
>>
>> On Fri, May 27, 2022 at 2:18 AM Ayu Ishii  
>> wrote:
>>
>>>
>>> *Contact emails *ay...@chromium.org, jsb...@chromium.org, 
>>> ajayra...@google.com  
>>>
>>>
>>> *Specification *https://www.w3.org/T

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

[Carl Turechek]

Hi,
Thanks for taking it into account. In a nutshell, my app is a C.R.U.D. that 
exports all of the data as json into a new html file along with everything 
else required to search through the information. It is a catalogue resonee 
where it could be downloaded and searched by anyone using a chrome browser. 
So you could search for a timeframe or keyword... and see a list and view 
images etc.. Also, privacy is an aspect.

It sounds like web assembly would not make this possible without fetching 
stuff or including more files. Maybe websql could be optional or 
something.. Anyway, thanks for the question! Have a good one :)
On Thursday, December 8, 2022 at 7:28:58 PM UTC-5 mo...@google.com wrote:

> Yes. Carl, does your app depend on Web SQL, webkitStorageInfo, or 
> something else?
>
> On Thu, Dec 8, 2022 at 6:55 PM Carl Turechek  wrote:
>
>> You'll break an app I developed to be passed around as a single html 
>> file. Hope you'll provide us plebs some guidance on finding a replacement 
>> solution.
>
>
>>
>> On Wednesday, November 16, 2022 at 1:22:34 PM UTC-5 mo...@google.com 
>> wrote:
>>
>>> I've done a more thorough search for examples of webkitStorageInfo and 
>>> of WebSQL in insecure contexts on the web. Among the top 10K sites, the 
>>> only usage I found was from standard libraries - and, in these cases, 
>>> removal wouldn't cause an error or affect any functionality.
>>>
>>> No one in Enterprise at Google, Microsoft, or Salesforce has uncovered 
>>> usage among their partners either.
>>>
>>>
>>> On Mon, Nov 14, 2022 at 11:51 AM 'Thomas Steiner' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 The developer-facing documentation is being updated in 
 https://github.com/GoogleChrome/developer.chrome.com/pull/4299.

 On Sat, Nov 12, 2022 at 12:26 AM Ayu Ishii  wrote:

> We've done some extra communications with enterprise partners and have 
> come up with a new target milestone.
> The new target milestone for this removal is M110, with enterprise 
> policy available for 2 milestones (M110-111).
>
> Thanks!
> Ayu
>
> On Wednesday, June 1, 2022 at 7:49:00 PM UTC-7 Ayu Ishii wrote:
>
>> Thank you all for the approvals!
>> And thank you miketaylr@ for the HTTPArchive analysis!
>>
>> On Wednesday, June 1, 2022 at 1:12:55 PM UTC-7 Mike Taylor wrote:
>>
>>> On 6/1/22 3:52 PM, Yoav Weiss wrote:
>>>
>>> LGTM3
>>>
>>> On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor  
>>> wrote:
>>>
 On 6/1/22 1:34 PM, Chris Harrelson wrote:


 On Tue, May 31, 2022 at 8:26 PM Ayu Ishii  
 wrote:

> Hi Mike!
>
> With the current usage measurements we see, we hadn't considered 
> any enterprise policy for opt-out.
> But certainly can follow the process to do so if you feel that 
> there may be risk of undercounting. 
> Deprecation of WebSQL in third-party contexts added a policy that 
> lasted 3 milestones after deprecation before full removal as an 
> example.
> Although the usages were quite different from that deprecation, we 
> can follow the same process if this sounds reasonable.
>

 I think this plan sounds good. LGTM1 once you have an enterprise 
 opt-out in place that will remain for 3 milestones. Also please make 
 sure 
 to communicate this change in the enterprise notes and other 
 communication 
 channels.

 A couple of notes I took last Friday and forgot to post:

 I dumped the list of sites from HTTPArchive (query below) and after 
 de-duping them, ended up with 835 sites.

 I then ran a script which naively looks at response codes, and got 
 the following results:

 2XX count: 685/835
 3XX to HTTP endpoint count: 74/835
 4XX count: 3/835
 5XX count: 2/835

 So, from this dataset, roughly 9% of those redirect to an HTTP 
 endpoint.

>>> This should say HTTPS, not HTTP. I am bad at typing.
>>>
>>> That said, I think reducing risk of breakage for enterprise 
 environments is a useful and friendly thing to do. LGTM2 w/ that done.

 SELECT
   rank,
   url,
 FROM
   `httparchive.blink_features.features`
 WHERE feature = 'OpenWebDatabaseInsecureContext'
 ORDER BY rank ASC

  

>
> - Ayu
>
> On Monday, May 30, 2022 at 10:57:01 PM UTC-7 Mike West wrote:
>
>> I'm happy to see this moving forward, thanks for pushing it 
>> ahead! 
>>
>> That said, this seems like the kind of thing that's likely-enough 
>> to impact enterprise that we should include a temporary opt-out to 
>> give 
>> ou

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

Hello,

The 108 branch is shipping to stable now, but the numbers from stable 
doesn't seems to be applied to the ChromeStatus stats yet. It seems that 
the stable numbers will be applied at Jan. 1st.
- https://chromestatus.com/metrics/feature/timeline/popularity/4361

I'll reschedule the feature release to 112 so that we can revisit this 
thread when we can get the numbers from stable.

Thank you!

p.s. 1
This feature is not related to :has() anymore since :has() is now 
unforgiving:
- Issue resolution: 
https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244
- CL : https://chromium-review.googlesource.com/c/chromium/src/+/4090967
This feature only affects :is()/:where() inside @supports.

p.s. 2
Once I get the stable number, I'll provide a comparison of these two 
numbers that I can get from the ChromeStatus stats:
- Percentage of page loads that drop invalid while forgiving parsing inside 
@supports selector
  (https://chromestatus.com/metrics/feature/timeline/popularity/4361)
- Percentage of page loads that use @supports rule
  (https://chromestatus.com/metrics/feature/timeline/popularity/976)

The comparison doesn't prove anything, but I think we can at least guess 
how much the @supports change affects the existing behavior:
Assuming the current numbers in the above links are from stable, about 40% 
of the loaded pages use @supports rule, but only 0.002% of the loaded pages 
hit the case of dropping invalid selector while forgiving selector parsing 
inside @supports. By simply comparing the numbers, I think we can say that 
1/2 of the @supports rule usages will be affected by the feature.

2022년 10월 10일 월요일 오후 11시 18분 41초 UTC+9에 Byungwoo Lee님이 작성:

> To continue this thread after getting the stable Chrome's use counter, I 
> changed the estimated milestone of this feature from 109 to 111.
> I'll share the use counter after the version 108 released.
>
> Thank you!
>
> 2022년 9월 29일 목요일 오전 11시 52분 43초 UTC+9에 Byungwoo Lee님이 작성:
>
>>
>> On 9/27/22 10:07, Byungwoo Lee wrote:
>>
>>
>> On 9/24/22 00:40, Yoav Weiss wrote:
>>
>>
>>
>> On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee  wrote:
>>
>>> Hello Yoav and Mike,
>>>
>>> Thanks for the feedback! I replied inline.
>>> On 9/23/22 22:18, Yoav Weiss wrote:
>>>
>>>
>>>
>>> On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor  
>>> wrote:
>>>
 Hi Byungwoo,

 On 9/23/22 4:34 AM, Byungwoo Lee wrote:

 Contact emails bl...@igalia.com

 Specification 
 https://drafts.csswg.org/css-conditional-4/#support-definition-ext

 Summary 

 Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) 
 If an argument of the functional selectors is unknown or invalid, the 
 argument is dropped but the selector itself is not invalidated. To provide 
 a way of detecting the unknown or invalid arguments in those functional 
 selectors, this feature applies the CSS Working Group issue resolution: - 
 @supports uses non-forgiving parsing for all selectors (
 https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187
 )

 Am I understanding correctly that content that now uses a functional 
>>> selector argument that's invalid may break as a result of this?
>>> If so, do we have usecounters to that effect?
>>>
>>> Yes it can change the previous behavior.
>>>
>>> This changes the selector parsing behavior only for the selectors inside 
>>> @supports selector().
>>>
>>> So if authors expected true for '@supports 
>>> selector(:is(:some-invalid-selector))', this feature will break it because 
>>> the return value will be changed to false after this feature is enabled.
>>>
>>> I'm not sure that we have the usecounters of the case: counting drop of 
>>> invalid selector inside @supports selector.
>>>
>>> If it doesn't exists but it is needed, I think we can add it. Will it be 
>>> better to add it to get use counters before ship it?
>>>
>>
>> Yeah, knowing the order of magnitude of potential breakage would be 
>> good.  
>>
>> I landed a CL to add the use counter:
>>
>> https://chromiumdash.appspot.com/commit/d060459d174c468a78d69d4e2a12925e0e7ab216
>>  
>>
>> It counts the drop of invalid selector while forgiving selector parsing 
>> inside @supports selector(). We can see the stats with 
>> CSSAtSupportsDropInvalidWhileForgivingParsing(4361):
>> https://chromestatus.com/metrics/feature/timeline/popularity/4361
>>
>> This will be in 108 version so hopefully we can get the use counter after 
>> the version is released.
>>
>>- beta (Oct 27)
>>- stable (Nov 29) 
>>
>> I'll share the stats when it released.
>>
>> Thanks!
>>
>>

 Blink component Blink 
 

 TAG review 

 TAG review status Not applicable

 Can you expand on why you think a TAG review is not needed here?

>>> I thought that we don't need TAG review and the reason was
>>>
>>> - This is already specifie

Re: [blink-dev] Intent to Implement and Ship: CSS pseudo-class ":picture-in-picture"

[Mike Taylor]

Thanks for the triage effort. LGTM3.

On 12/9/22 6:04 AM, 'François Beaufort' via blink-dev wrote:



On Wed, Dec 7, 2022 at 10:23 AM Mike West  wrote:

LGTM2, for the same reason.

That said, there are a number of open bugs against the repository.
Have you done any triage against them to see whether any might be
compatibility issues in the future?


Thanks for the reminder Mike.
I went through all of them (triage was overdue) and I'm happy to 
report there's no foreseen compatibility issue with this pseudo class.



-mike


On Wed, Dec 7, 2022 at 9:51 AM Yoav Weiss 
wrote:

I think that reviving this 3.5 years later warrants getting
LGTMs again, as the landscape may have changed.

With that said, *LGTM1*, as it seems this would now be
catching up with Safari.

On Wed, Dec 7, 2022 at 8:00 AM 'François Beaufort' via
blink-dev  wrote:

Originally planned[1] to be shipped in Chrome 76, the
":picture-in-picture" CSS pseudo-class was disabled[2] in
the same milestone as we thought we may need to revisit
the design based on new features coming into the
Picture-in-Picture API.

This is not the case anymore. For this reason we'll ship
it in Chrome 110.

Note that the ":picture-in-picture" CSS pseudo-class has
been implemented by Safari[3] since.

[1]

https://chromiumdash.appspot.com/commits?commit=eb334058998fda433c4c910bf36d665082b30434
[2]

https://chromiumdash.appspot.com/commits?commit=ac1159c89f4a93414d477fc47548afa563b0c612
[3]

https://wpt.fyi/results/picture-in-picture/css-selector.html?label=experimental&label=master&aligned



On Thursday, May 2, 2019 at 4:29:47 PM UTC+2 Chris
Harrelson wrote:

On Thu, May 2, 2019 at 12:38 AM
 wrote:

Thank you. See answer inline.

On Friday, April 26, 2019 at 10:25:10 PM UTC+2,
Daniel Bratell wrote:

LGTM3

/Daniel

On Fri, 26 Apr 2019 20:57:25 +0200, Yoav Weiss
 wrote:

LGTM2

On Fri, Apr 26, 2019 at 8:37 PM Chris
Harrelson  wrote:

Great!

LGTM1

Would be good to also have a WPT test
exercising the absence of retargeting,
if there isn't already.


I've added one.


Thanks!


On Fri, Apr 26, 2019 at 9:53 AM
'Mounir Lamouri' via blink-dev
 wrote:

The Picture-in-Picture spec has
been updated.

On Thu, 25 Apr 2019 at 07:46,
Daniel Bratell 
wrote:

Looks like nobody responded.
Maybe mlamouri can take a look?

/Daniel

On Thu, 18 Apr 2019 10:32:49
+0200, François Beaufort
 wrote:

Thank you everyone for
your feedback and answers!

I'm sending a spec PR at

https://github.com/WICG/picture-in-picture/pull/126 that
removes retargeting.
I'll also pinging
fullscreen spec owners at

https://github.com/whatwg/fullscreen/issues/149.

On Wed, Apr 17, 2019 at
7:03 PM Chris Harrelson
 wrote:

(API owner hat off in
this response)

I don't think that
:picture-in-picture
should automatically
apply to the shadow
host chain (*). I

Re: [blink-dev] Intent to Implement and Ship: CSS pseudo-class ":picture-in-picture"

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

On Wed, Dec 7, 2022 at 10:23 AM Mike West  wrote:

> LGTM2, for the same reason.
>
> That said, there are a number of open bugs against the repository. Have
> you done any triage against them to see whether any might be compatibility
> issues in the future?
>

Thanks for the reminder Mike.
I went through all of them (triage was overdue) and I'm happy to report
there's no foreseen compatibility issue with this pseudo class.


> -mike
>
>
> On Wed, Dec 7, 2022 at 9:51 AM Yoav Weiss  wrote:
>
>> I think that reviving this 3.5 years later warrants getting LGTMs again,
>> as the landscape may have changed.
>>
>> With that said, *LGTM1*, as it seems this would now be catching up with
>> Safari.
>>
>> On Wed, Dec 7, 2022 at 8:00 AM 'François Beaufort' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Originally planned[1] to be shipped in Chrome 76, the
>>> ":picture-in-picture" CSS pseudo-class was disabled[2] in the same
>>> milestone as we thought we may need to revisit the design based on new
>>> features coming into the Picture-in-Picture API.
>>>
>>> This is not the case anymore. For this reason we'll ship it in Chrome
>>> 110.
>>>
>>> Note that the ":picture-in-picture" CSS pseudo-class has been
>>> implemented by Safari[3] since.
>>>
>>> [1]
>>> https://chromiumdash.appspot.com/commits?commit=eb334058998fda433c4c910bf36d665082b30434
>>> [2]
>>> https://chromiumdash.appspot.com/commits?commit=ac1159c89f4a93414d477fc47548afa563b0c612
>>> [3]
>>> https://wpt.fyi/results/picture-in-picture/css-selector.html?label=experimental&label=master&aligned
>>>
>>> On Thursday, May 2, 2019 at 4:29:47 PM UTC+2 Chris Harrelson wrote:
>>>
 On Thu, May 2, 2019 at 12:38 AM  wrote:

> Thank you. See answer inline.
>
> On Friday, April 26, 2019 at 10:25:10 PM UTC+2, Daniel Bratell wrote:
>>
>> LGTM3
>>
>> /Daniel
>>
>> On Fri, 26 Apr 2019 20:57:25 +0200, Yoav Weiss  wrote:
>>
>> LGTM2
>>
>> On Fri, Apr 26, 2019 at 8:37 PM Chris Harrelson 
>> wrote:
>>
>>> Great!
>>>
>>> LGTM1
>>>
>>> Would be good to also have a WPT test exercising the absence of
>>> retargeting, if there isn't already.
>>>
>>
> I've added one.
>

 Thanks!


>
>
>>
>>> On Fri, Apr 26, 2019 at 9:53 AM 'Mounir Lamouri' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 The Picture-in-Picture spec has been updated.

 On Thu, 25 Apr 2019 at 07:46, Daniel Bratell 
 wrote:

> Looks like nobody responded. Maybe mlamouri can take a look?
>
> /Daniel
>
> On Thu, 18 Apr 2019 10:32:49 +0200, François Beaufort <
> beaufort...@gmail.com> wrote:
>
> Thank you everyone for your feedback and answers!
>
> I'm sending a spec PR at
> https://github.com/WICG/picture-in-picture/pull/126 that removes
> retargeting.
> I'll also pinging fullscreen spec owners at
> https://github.com/whatwg/fullscreen/issues/149.
>
> On Wed, Apr 17, 2019 at 7:03 PM Chris Harrelson <
> chri...@chromium.org> wrote:
>
>> (API owner hat off in this response)
>>
>> I don't think that :picture-in-picture should automatically apply
>> to the shadow host chain (*). I suggest removing retargeting from 
>> that spec
>> and also for the spec definition of :fullscreen.
>>
>> Rune's suggestion about using :part also makes sense to me.
>>
>> Chris
>>
>> (*) Posted some thoughts at
>> https://github.com/w3c/webcomponents/issues/804
>>
>> On Wed, Apr 17, 2019 at 2:45 AM Rune Lillesveen <
>> fut...@chromium.org> wrote:
>>
>>> On Thu, Mar 28, 2019 at 3:22 PM Emilio Cobos Álvarez <
>>> emi...@mozilla.com> wrote:
>>>
 I don't think such behavior makes sense for :fullscreen (nor for
 :picture-in-picture). For example, the fullscreen spec defines
 an
 user-agent stylesheet[1] that would break the layout of any
 shadow host
 containing the fullscreen element if such a thing was
 implemented. I
 don't think that's desirable nor makes much sense.

 Also, it doesn't seem to make much sense to me to match
 :fullscreen for
 some shadow host that has arbitrary content apart of the
 fullscreen
 element, but maybe I could be convinced otherwise?
>>>
>>>
>>> Yes, wouldn't that be targeted more naturally with ::part?
>>>
>>> E.g.:  movie-app::part(video):fullscreen {}
>>>
>>> Note: Apparently, :fullscreen doesn't work with ::part() in
>>> Blink. Reported https://crbug.com/953648
>>>
>>> --