Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

['Mathias Bynens' via blink-dev]

Thank you for the update, Ethan! This clarifies a lot.

On Fri, Jan 21, 2022 at 6:07 AM 'Ethan Jimenez' via blink-dev <
blink-dev@chromium.org> wrote:

> Thanks for the response Mike!
>
>
>
> I edited the “Debuggability” section below and will update the Chrome
> status entry soon.
>
>
>
> Best regards,
>
> Ethan
>
>
>
> *From:* Mike Taylor 
> *Sent:* Thursday, January 20, 2022 1:03 PM
> *To:* Ethan Jimenez 
> *Cc:* blink-dev@chromium.org; Philip Jägenstedt ;
> Mathias Bynens 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid
>
>
>
> (I'm not Mathias, but...)
>
>
>
> You can just respond to this thread with the debug info, and update the
> Chromestatus entry as well - thanks!
>
>
>
> On 1/20/22 3:57 PM, 'Ethan Jimenez' via blink-dev wrote:
>
> Hi everyone!
>
>
>
> Philip, thanks for the encouragement, I’m super excited to deliver subgrid
> knowing that it’s going to make so many devs happy.
>
>
>
> @Mathias Bynens  quick question, should I re-send
> the intent to prototype or just edit it here?
>
>
>
> Thanks in advance,
>
> Ethan
>
>
>
> *From:* Philip Jägenstedt  
> *Sent:* Wednesday, January 19, 2022 9:03 AM
> *To:* Mathias Bynens  
> *Cc:* Ethan Jimenez  ;
> blink-dev@chromium.org
> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid
>
>
>
> Hi Ethan,
>
>
>
> It's great to see this Intent to Prototype. Subgrid tends to come up as
> important in web developer surveys, the latest being State of CSS 2021:
>
>
> https://2021.stateofcss.com/en-US/opinions/#browser_interoperability_features
> 
>
> https://2021.stateofcss.com/en-US/opinions/#currently_missing_from_css_wins
> 
>
>
>
> It's a part of Interop 2022
> 
> for this reason
>
>
>
> So I hope this all goes well :D
>
>
>
> Best regards,
>
> Philip
>
>
>
> On Wed, Jan 19, 2022 at 8:09 AM Mathias Bynens 
> wrote:
>
> The required “Debuggability” section was left empty. Please follow
> https://goo.gle/devtools-checklist
> 
> and elaborate on how developers would inspect & debug this new feature. Per
> the guide, we need to ensure DevTools supports basic editing of the new CSS
> properties and values — which would likely work out-of-the-box anyhow.
> Please elaborate.
>
>
>
> On Tue, Jan 18, 2022 at 6:42 PM 'Ethan Jimenez' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> *Contact emails*
>
> etha...@microsoft.com
>
> *Explainer*
>
> None
>
> *Specification*
>
> https://drafts.csswg.org/css-grid-2
> 
>
> *Design docs*
>
> https://docs.google.com/document/d/1cpsCmzdDlXUKtMxOUKIoJFyLH54mLVhZnam_z0PriO0/edit?usp=sharing
> 

Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

[Alex Russell]

I'm incredibly excited about this feature. Thanks for driving it in
Chromium, Ethan.

Regarding the templates, it's also not clear to me that TAG review is
optional in this case. At a minimum, you should be filing a request for
review with a heavy suggestion that it should be treated as an FYI. It'll
be upt to the TAG to decide how to dispose of that review, but we trust
them to inform us of risks to platform coherence, so it'll be good to get
their eyes on it regardless.

/cc Rossen

On Thu, Jan 20, 2022 at 9:07 PM 'Ethan Jimenez' via blink-dev <
blink-dev@chromium.org> wrote:

> Thanks for the response Mike!
>
>
>
> I edited the “Debuggability” section below and will update the Chrome
> status entry soon.
>
>
>
> Best regards,
>
> Ethan
>
>
>
> *From:* Mike Taylor 
> *Sent:* Thursday, January 20, 2022 1:03 PM
> *To:* Ethan Jimenez 
> *Cc:* blink-dev@chromium.org; Philip Jägenstedt ;
> Mathias Bynens 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid
>
>
>
> (I'm not Mathias, but...)
>
>
>
> You can just respond to this thread with the debug info, and update the
> Chromestatus entry as well - thanks!
>
>
>
> On 1/20/22 3:57 PM, 'Ethan Jimenez' via blink-dev wrote:
>
> Hi everyone!
>
>
>
> Philip, thanks for the encouragement, I’m super excited to deliver subgrid
> knowing that it’s going to make so many devs happy.
>
>
>
> @Mathias Bynens  quick question, should I re-send
> the intent to prototype or just edit it here?
>
>
>
> Thanks in advance,
>
> Ethan
>
>
>
> *From:* Philip Jägenstedt  
> *Sent:* Wednesday, January 19, 2022 9:03 AM
> *To:* Mathias Bynens  
> *Cc:* Ethan Jimenez  ;
> blink-dev@chromium.org
> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid
>
>
>
> Hi Ethan,
>
>
>
> It's great to see this Intent to Prototype. Subgrid tends to come up as
> important in web developer surveys, the latest being State of CSS 2021:
>
>
> https://2021.stateofcss.com/en-US/opinions/#browser_interoperability_features
> 
>
> https://2021.stateofcss.com/en-US/opinions/#currently_missing_from_css_wins
> 
>
>
>
> It's a part of Interop 2022
> 
> for this reason
>
>
>
> So I hope this all goes well :D
>
>
>
> Best regards,
>
> Philip
>
>
>
> On Wed, Jan 19, 2022 at 8:09 AM Mathias Bynens 
> wrote:
>
> The required “Debuggability” section was left empty. Please follow
> https://goo.gle/devtools-checklist
> 
> and elaborate on how developers would inspect & debug this new feature. Per
> the guide, we need to ensure DevTools supports basic editing of the new CSS
> properties and values — which would likely work out-of-the-box anyhow.
> Please elaborate.
>
>
>
> On Tue, Jan 18, 2022 at 6:42 PM 'Ethan Jimenez' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> *Contact emails*
>
> etha...@microsoft.com
>
> *Explainer*
>
> None
>
> *Specification*
>
> https://drafts.csswg.org/css-grid-2
> 
>
> *Design docs*
>
> 

RE: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

['Ethan Jimenez' via blink-dev]

Thanks for the response Mike!

I edited the "Debuggability" section below and will update the Chrome status 
entry soon.

Best regards,
Ethan


From: Mike Taylor 
Sent: Thursday, January 20, 2022 1:03 PM
To: Ethan Jimenez 
Cc: blink-dev@chromium.org; Philip Jägenstedt ; Mathias 
Bynens 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

(I'm not Mathias, but...)

You can just respond to this thread with the debug info, and update the 
Chromestatus entry as well - thanks!

On 1/20/22 3:57 PM, 'Ethan Jimenez' via blink-dev wrote:
Hi everyone!

Philip, thanks for the encouragement, I'm super excited to deliver subgrid 
knowing that it's going to make so many devs happy.

@Mathias Bynens quick question, should I re-send 
the intent to prototype or just edit it here?

Thanks in advance,
Ethan

From: Philip Jägenstedt 
Sent: Wednesday, January 19, 2022 9:03 AM
To: Mathias Bynens 
Cc: Ethan Jimenez ; 
blink-dev@chromium.org
Subject: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

Hi Ethan,

It's great to see this Intent to Prototype. Subgrid tends to come up as 
important in web developer surveys, the latest being State of CSS 2021:
https://2021.stateofcss.com/en-US/opinions/#browser_interoperability_features
https://2021.stateofcss.com/en-US/opinions/#currently_missing_from_css_wins

It's a part of Interop 
2022
 for this reason

So I hope this all goes well :D

Best regards,
Philip

On Wed, Jan 19, 2022 at 8:09 AM Mathias Bynens 
mailto:math...@chromium.org>> wrote:
The required "Debuggability" section was left empty. Please follow 
https://goo.gle/devtools-checklist
 and elaborate on how developers would inspect & debug this new feature. Per 
the guide, we need to ensure DevTools supports basic editing of the new CSS 
properties and values - which would likely work out-of-the-box anyhow. Please 
elaborate.

On Tue, Jan 18, 2022 at 6:42 PM 'Ethan Jimenez' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Contact emails
etha...@microsoft.com
Explainer
None
Specification
https://drafts.csswg.org/css-grid-2
Design docs
https://docs.google.com/document/d/1cpsCmzdDlXUKtMxOUKIoJFyLH54mLVhZnam_z0PriO0/edit?usp=sharing
Summary
Implements the CSS Grid Layout Module Level 2 specification, which introduces 
the concept of a "subgrid" to nested grid containers.
Blink component

Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

[Mike Taylor]

(I'm not Mathias, but...)

You can just respond to this thread with the debug info, and update the 
Chromestatus entry as well - thanks!


On 1/20/22 3:57 PM, 'Ethan Jimenez' via blink-dev wrote:


Hi everyone!

Philip, thanks for the encouragement, I’m super excited to deliver 
subgrid knowing that it’s going to make so many devs happy.


@Mathias Bynens  quick question, should I 
re-send the intent to prototype or just edit it here?


Thanks in advance,

Ethan

*From:* Philip Jägenstedt 
*Sent:* Wednesday, January 19, 2022 9:03 AM
*To:* Mathias Bynens 
*Cc:* Ethan Jimenez ; blink-dev@chromium.org
*Subject:* [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

Hi Ethan,

It's great to see this Intent to Prototype. Subgrid tends to come up 
as important in web developer surveys, the latest being State of CSS 2021:


https://2021.stateofcss.com/en-US/opinions/#browser_interoperability_features 



https://2021.stateofcss.com/en-US/opinions/#currently_missing_from_css_wins 



It's a part of Interop 2022 
 
for this reason


So I hope this all goes well :D

Best regards,

Philip

On Wed, Jan 19, 2022 at 8:09 AM Mathias Bynens  
wrote:


The required “Debuggability” section was left empty. Please follow
https://goo.gle/devtools-checklist


and elaborate on how developers would inspect & debug this new
feature. Per the guide, we need to ensure DevTools supports basic
editing of the new CSS properties and values — which would likely
work out-of-the-box anyhow. Please elaborate.

On Tue, Jan 18, 2022 at 6:42 PM 'Ethan Jimenez' via blink-dev
 wrote:

*Contact emails*

etha...@microsoft.com 

*Explainer*

None

*Specification*

https://drafts.csswg.org/css-grid-2



*Design docs*

https://docs.google.com/document/d/1cpsCmzdDlXUKtMxOUKIoJFyLH54mLVhZnam_z0PriO0/edit?usp=sharing



*Summary*

Implements the CSS Grid Layout Module Level 2 specification,
which introduces the concept of a "subgrid" to nested grid
containers.

*Blink component*

Blink>CSS

RE: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

['Ethan Jimenez' via blink-dev]

Hi everyone!

Philip, thanks for the encouragement, I'm super excited to deliver subgrid 
knowing that it's going to make so many devs happy.

@Mathias Bynens quick question, should I re-send 
the intent to prototype or just edit it here?

Thanks in advance,
Ethan

From: Philip Jägenstedt 
Sent: Wednesday, January 19, 2022 9:03 AM
To: Mathias Bynens 
Cc: Ethan Jimenez ; blink-dev@chromium.org
Subject: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

Hi Ethan,

It's great to see this Intent to Prototype. Subgrid tends to come up as 
important in web developer surveys, the latest being State of CSS 2021:
https://2021.stateofcss.com/en-US/opinions/#browser_interoperability_features
https://2021.stateofcss.com/en-US/opinions/#currently_missing_from_css_wins

It's a part of Interop 
2022
 for this reason

So I hope this all goes well :D

Best regards,
Philip

On Wed, Jan 19, 2022 at 8:09 AM Mathias Bynens 
mailto:math...@chromium.org>> wrote:
The required "Debuggability" section was left empty. Please follow 
https://goo.gle/devtools-checklist
 and elaborate on how developers would inspect & debug this new feature. Per 
the guide, we need to ensure DevTools supports basic editing of the new CSS 
properties and values - which would likely work out-of-the-box anyhow. Please 
elaborate.

On Tue, Jan 18, 2022 at 6:42 PM 'Ethan Jimenez' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Contact emails
etha...@microsoft.com
Explainer
None
Specification
https://drafts.csswg.org/css-grid-2
Design docs
https://docs.google.com/document/d/1cpsCmzdDlXUKtMxOUKIoJFyLH54mLVhZnam_z0PriO0/edit?usp=sharing
Summary
Implements the CSS Grid Layout Module Level 2 specification, which introduces 
the concept of a "subgrid" to nested grid containers.
Blink component
Blink>CSS
Motivation
The problem CSS Subgrid solves is inheritance within nested grid containers: 
only direct children of a grid container are aware of its parent's grid 
properties, e.g., the size of its tracks, the names of each grid line. Whenever 

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

[Noah Lemen]

At Meta (formerly known as Facebook) we have a fair amount of dependencies 
on domain lowering via document.domain. We've discussed this internally, 
and feel that the most difficult aspect of this for us currently is 
identifying where we depend on domain lowering. We feel that something that 
may be helpful for us would be a reporting API not on document.domain, but 
rather on any cross-origin accesses that are only working because of domain 
lowering. Would a reporting API like this be possible to add to help us 
along the deprecation process?

On Tuesday, January 18, 2022 at 12:41:22 PM UTC-5 T K wrote:

> Hi,
> Do you know if there is  a way to get a Chrome version with those changes 
> to see how those changes impact my site?
> Thanks
>
> On Friday, January 14, 2022 at 8:06:58 PM UTC+2 sligh...@chromium.org 
> wrote:
>
>> Daniel: 
>>
>> Salesforce use is concentrated in enterprises, and the enterprise opt-in 
>> rates for metrics and crash reporting are very, very, very low. As a 
>> result, I'm not sure we should trust UKM here. 
>>
>> Greg: 
>>
>> Thanks so much for looking into your code. I know it might take time for 
>> your larger ecosystem to start sending y'all deprecation reports. How long 
>> after the deprecation API starts reporting do you think it'll be before we 
>> can get solid information from your service?
>>
>> Thanks.
>>
>> On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim wrote:
>>
>>> On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth  
>>> wrote:
>>>
 Hey folks,

 I'll be spinning up a thread with some internal folks here at 
 Salesforce to start doing some scans of code to determine utilization. Has 
 this been added to the reporting API for deprecation to possibly capture 
 live hits that way as well?

>>>
>>> Not yet. That'd be the first step once this intent is approved. 
>>>

 I'll follow up on what I find and that will influence my opinion on 
 removal timeline.

>>>
>>> Thank you, this would be very helpful.
>>> If it helps: salesforce.com (or other Salesforce country domains) do 
>>> not show up in our telemetry, so with some likelihood you're among the >99% 
>>> sites that do not even use this mis-feature. :-)
>>> (Caveat: You might use other domains as well; or maybe your customers 
>>> dis-proportionally disable reporting.)
>>>
>>> If you have a staging environment, you can simulate the deprecation by 
>>> adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables 
>>> clustering by origin. document.domain setting will have no effect, and a 
>>> console message will be printed. (In other words: This is behaviour we'd 
>>> like to be the default.)
>>> If you do find usage that you cannot easily replace, adding 
>>> "Origin-Agent-Cluster: ?0" will disable this.
>>>
>>>
 ~Greg

 On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:

> Note that Daniel has already landed the enterprise policy for this in 
> https://chromium-review.googlesource.com/c/chromium/src/+/3317349 
> (99.0.4759.0).
>
> Charlie
>
> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  
> wrote:
>
>> > This probably requires an Enterprise Policy, to reduce the risk for 
>> managed installs. +bheenan@ for opinions on that front.
>>
>> I agree, this looks like a breaking change according to 
>> go/chrome-enterprise-friendly and therefore needs a policy. 
>> Instructions for implementing a policy are here: 
>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>  
>> if you haven't done it before, and the enterprise team is happy to help 
>> if 
>> anything seems confusing. Having this implemented as a "soft removal" 
>> with 
>> a temporary policy escape hatch significantly reduces enterprise risk, 
>> since even if we are surprised by a use case hiding behind many 
>> enterprises' tendency to turn off metrics, those users can 
>> break-fix themselves immediately while staying on the latest version.
>>
>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss  
>> wrote:
>>
>>> Hey Daniel!
>>>
>>> While searching for this intent review, I stumbled upon 
>>> https://developer.chrome.com/blog/immutable-document-domain/ 
>>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>>
>>> This intent was just discussed at the API owner meeting (where 
>>> Chris, Rego, Daniel, Philip, Alex, MikeT and myself were present).
>>> This change seems risky in terms of potential breakage when looking 
>>> at our stats, and that's even before talking about enterprises, where a 
>>> lot 
>>> of the API owners feel the risk is even higher.
>>>
>>> Given that, here's a few potential next steps to try and reduce that 
>>> risk:
>>>
>>>- UKM and outreach to specific large users of the API can maybe 

[blink-dev] Re: Intent to Extend Origin Trial: Origin Private File System extension: AccessHandle

['Austin Sullivan' via blink-dev]

DISREGARD. This is a duplicate of 
https://groups.google.com/a/chromium.org/g/blink-dev/c/yNslidDtNho/m/IEPD25X_AAAJ

On Thursday, January 20, 2022 at 9:42:39 AM UTC-8 Austin Sullivan wrote:

> Contact emailsasu...@chromium.org, five...@chromium.org, m...@chromium.org
> , rs...@chromium.org
>
> Explainer
> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md
>
> Specification
>
> Summary
>
> The Origin Private File System (OPFS, part of the File System Access API) 
> is augmented with a new surface that brings very performant access to data. 
> This new surface differs from existing ones by offering in-place and 
> exclusive write access to a file’s content. This change, along with the 
> ability to consistently read unflushed modifications and the availability 
> of a synchronous variant on dedicated workers, significantly improves 
> performance and unblocks new use cases.
>
>
> Included in this origin trial is also a version of the 
> FileSystemHandle::move() method, currently limited to files in the OPFS 
> only. The move() method will be shipped separately with its own intent (
> https://chromestatus.com/feature/5640802622504960), but this limited 
> subset is included in this origin trial because it significantly improves 
> the performance and ease of use of the OPFS.
>
> Blink componentBlink>Storage>FileSystem 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/664
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> The feature has to be compatible with existing ways to access data on OPFS 
> i.e., createWritable() and getFile(). The use of write locks and care for 
> backwards compatibility should mean that the risk here is low. In order to 
> ease compatibility concerns in the future, we've added an optional 'mode' 
> parameter to createAccessHandle()/createSyncAccessHandle(). This allows us 
> to eventually extend AccessHandle functionality to non-OPFS file systems 
> without necessarily taking the OPFS behaviour as default (more details 
> here: 
> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#exposing-accesshandles-on-all-filesystems).
>  
> There is a risk of interoperability between vendors, pending the position 
> on implementing this surface. This design is the result of feedback from 
> Gecko and WebKit, who reviewed previous iterations of this functionality 
> and gave feedback that it should integrate more strongly with OPFS. We 
> believe that the new design, when paired with a separate streams-based 
> extension to OPFS, meets these goals. However, we have not yet received 
> work back as to whether they agree with our assessment.
>
>
> Gecko: No signal on official Request for Position (
> https://github.com/mozilla/standards-positions/issues/562), but 
> supportive of migrating the spec to whatwg (
> https://github.com/whatwg/sg/issues/176).
>
> WebKit: In development (
> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031934.html) 
> Request for position was not answered, but the feature is being implemented 
> and is available in TP. See reference bug: 
> https://bugs.webkit.org/show_bug.cgi?id=231185
>
> Web developers: No signals
>
> Other signals:
>
>
> Goals for experimentation
>
> In general, we want to validate the new surface against "real world" use 
> cases from our partners and developers at large. In particular, we are 
> interested in the relative usage between the sync and async methods, since 
> this could have an impact on performance when using Asyncify. We also would 
> like to receive qualitative feedback on the ease of use of the API from 
> within Wasm.
>
>
> Reason this experiment is being extended
>
> We're working with a partner, but they need more time to test and give 
> feedback on the API.
>
> Ongoing technical constraints
>
> None
>
> Debuggability
>
> Basic tooling: Autocomplete works as described in "New WebIDL/DOM 
> interfaces and attributes". Extended tooling: we'll eventually want to be 
> able to explore files stored in OPFS. There are two tracking bugs related 
> to this: crbug.com/256067 and crbug.com/735618. This API doesn't really 
> add new storage backends, just new ways to interact with files, so we'd be 
> covered by those as well. 
>
>
> 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
>
> DevTrial instructions
> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#trying-it-out
>
> Flag nameFileSystemAccessAccessHandle
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218431
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1232436
>

Re: [blink-dev] Intent to Extend Experiment: Storage Foundation API

[Chris Harrelson]

Hi Emanuel,

A question inline below.

On Thu, Jan 20, 2022 at 7:02 AM Emanuel Krivoy 
wrote:

> Hello blink-dev,
>
>
>
> We’d like to ask for an extension to our Origin Trial, from M99 to M101.
> As mentioned in our previous I2E
> ,
> our partner intended to run a final series of tests that would allow us to
> measure the impact of the changes between Storage Foundation and its
> successor Access Handles. The tests were postponed but should happen in the
> near future, therefore we’d like to continue having concurrent Access
> Handle/Storage Foundation trials.
>

Is it accurate to say then that there hasn't been substantial use on sites
recently? Or are they using it generally but just haven't run the set of
tests yet?

Also, could you summarize the feedback from partners so far on this origin
trial?


>
>
> Please find the Chrome Status template below:
>
>
>
> Contact emails
>
> fived...@chromium.org, r...@chromium.org
>
> Explainer
>
> https://github.com/WICG/storage-foundation-api-explainer
>
> Specification
>
> N/A
>
> Summary
>
> Storage Foundation API is a storage API that resembles a very basic
> filesystem, with direct access to stored data through buffers and offsets.
> Our goal is to give developers flexibility by providing generic, simple,
> and performant primitives upon which they can build higher-level
> components. It's particularly well suited for Wasm-based libraries and
> applications that want to use custom storage algorithms to fine-tune
> execution speed and memory usage.
>
>
> Blink component
>
> Blink>Storage
> 
>
> Search tags
>
> storage , nativeio
> , performance
> , low-level
> , generic
> , foundation
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/566
>
> TAG review status
>
> Closed
>
> Risks
>
> Interoperability and Compatibility
>
> This new feature has some potential interoperability risks due to its
> nature as a novel and low-level API. Currently, there are no web features
> that expose such a generic interface and that focus on WebAssembly ports as
> one of it's main consumers.
>
> We've also received feedback from other vendors that the functionality
> added in Storage Foundation API seems duplicative of File System Access
> API. We are exploring a merged design (details here:
> https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec)
> while collecting feedback and validating design choices with this
> independent API.
>
>
> Gecko: Negative (https://github.com/mozilla/standards-positions/issues/481)
> Supportive of a low-level storage API, opposed to minting a new API instead
> of taking a holistic approach to file access
>
> WebKit: Negative (
> https://lists.webkit.org/pipermail/webkit-dev/2021-February/031687.html)
> No opposition to offering efficient access to files, strongly opposed to
> minting a new API instead of augmenting an existing one.
>
> Web developers: No signals
>
>
> Goals for experimentation
>
> In general, we would like to validate the whole surface of our API against
> developer expectations and more diverse use cases. In particular, we are
> interested in confirming that we provide the required performance to allow
> new uses, and to shed light on developer preference between a synchronous
> and asynchronous surface.
>
> Reason this experiment is being extended
>
> We added a new surface on OPFS (Access Handles:
> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md)
> that replaces Storage Foundation. Having concurrent trials would help us
> validate the surface by comparing and contrasting it with the previous one.
> Our partner will run a final series of tests with beta users, and this
> provides a chance for us to measure the impact of some of the design
> decisions we’ve made. In particular we’d like to see the effect of
> providing a mixed sync/async surface on SyncAccessHandles and of all
> filesystem operations being async. Concurrent trials would also make it
> easier to measure any unexpected performance differences.
>
>
> 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
>
> NativeIO
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=914488
>
> Launch bug
>
> 

[blink-dev] Intent to Extend Origin Trial: Origin Private File System extension: AccessHandle

[Austin Sullivan]

Contact emailsasu...@chromium.org, fived...@chromium.org, m...@chromium.org,
r...@chromium.org

Explainer
https://github.com/WICG/file-system-access/blob/main/AccessHandle.md

Specification

Summary

The Origin Private File System (OPFS, part of the File System Access API)
is augmented with a new surface that brings very performant access to data.
This new surface differs from existing ones by offering in-place and
exclusive write access to a file’s content. This change, along with the
ability to consistently read unflushed modifications and the availability
of a synchronous variant on dedicated workers, significantly improves
performance and unblocks new use cases.


Included in this origin trial is also a version of the
FileSystemHandle::move() method, currently limited to files in the OPFS
only. The move() method will be shipped separately with its own intent (
https://chromestatus.com/feature/5640802622504960), but this limited subset
is included in this origin trial because it significantly improves the
performance and ease of use of the OPFS.

Blink componentBlink>Storage>FileSystem


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

TAG review statusPending

Risks


Interoperability and Compatibility

The feature has to be compatible with existing ways to access data on OPFS
i.e., createWritable() and getFile(). The use of write locks and care for
backwards compatibility should mean that the risk here is low. In order to
ease compatibility concerns in the future, we've added an optional 'mode'
parameter to createAccessHandle()/createSyncAccessHandle(). This allows us
to eventually extend AccessHandle functionality to non-OPFS file systems
without necessarily taking the OPFS behaviour as default (more details
here:
https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#exposing-accesshandles-on-all-filesystems).
There is a risk of interoperability between vendors, pending the position
on implementing this surface. This design is the result of feedback from
Gecko and WebKit, who reviewed previous iterations of this functionality
and gave feedback that it should integrate more strongly with OPFS. We
believe that the new design, when paired with a separate streams-based
extension to OPFS, meets these goals. However, we have not yet received
work back as to whether they agree with our assessment.


Gecko: No signal on official Request for Position (
https://github.com/mozilla/standards-positions/issues/562), but supportive
of migrating the spec to whatwg (https://github.com/whatwg/sg/issues/176).

WebKit: In development (
https://lists.webkit.org/pipermail/webkit-dev/2021-August/031934.html)
Request for position was not answered, but the feature is being implemented
and is available in TP. See reference bug:
https://bugs.webkit.org/show_bug.cgi?id=231185

Web developers: No signals

Other signals:


Goals for experimentation

In general, we want to validate the new surface against "real world" use
cases from our partners and developers at large. In particular, we are
interested in the relative usage between the sync and async methods, since
this could have an impact on performance when using Asyncify. We also would
like to receive qualitative feedback on the ease of use of the API from
within Wasm.


Reason this experiment is being extended

We're working with a partner, but they need more time to test and give
feedback on the API.

Ongoing technical constraints

None

Debuggability

Basic tooling: Autocomplete works as described in "New WebIDL/DOM
interfaces and attributes". Extended tooling: we'll eventually want to be
able to explore files stored in OPFS. There are two tracking bugs related
to this: crbug.com/256067 and crbug.com/735618. This API doesn't really add
new storage backends, just new ways to interact with files, so we'd be
covered by those as well.


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

DevTrial instructions
https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#trying-it-out

Flag nameFileSystemAccessAccessHandle

Requires code in //chrome?False

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

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1232436

Estimated milestones
OriginTrial desktop last 102
OriginTrial desktop first 95
DevTrial on desktop 94

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/33T36N6VBKI
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/_nB5VfgXW_I
Intent to Experiment:

Re: [blink-dev] Re: Intent to extend the origin trial: WebTransport over HTTP/3

[kk as]

Hi
  Can you please let me know  what transport protocol  do the Streams API 
use in WebTransport over http3/quic.  
I am assuming the datagram API uses the UDP protocol for transport .   Can 
you also please let me know what is the difference in latency
when you send data using Streams API vs Datagram API ?


thanks

On Wednesday, October 27, 2021 at 10:34:56 PM UTC-7 Yutaka Hirano wrote:

> On Thu, Oct 28, 2021 at 2:38 AM Joe Medley  wrote:
>
>> Hi,
>>
>> Can I get some clarification?
>>
>> So this extends the origin trial through 96, but you don't know yet 
>> whether it will ship in 97? Is this correct?
>>
> We're shipping WebTransport over HTTP/3 in 97.
>
>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Oct 25, 2021 at 1:00 AM Mike West  wrote:
>>
>>> LGTM3.
>>>
>>> -mike
>>>
>>>
>>> On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell  
>>> wrote:
>>>
 For a gapless origin trial->shipping it is important to be sure we 
 don't overlook any feedback in the race to shipping. The normal process 
 has 
 gaps built in which form natural points to do that final polish based on 
 received feedback and that will be missing here.

 It does sound like the feedback has been positive though and that there 
 are no known problems that can't be fixed after shipping, and with that in 
 mind:

 LGTM2
 On 2021-10-21 21:53, Yoav Weiss wrote:

 Discussing amongst the API owners (Alex, Daniel, Rego and myself), this 
 is essentially a request for a gapless OT, only that the would-be-gap is 
 slightly longer than usual. Given the evidence 
 
  of 
 developer feedback presented in the I2S, that seems like a reasonable 
 request. 

 LGTM1 (as gapless OT requests require 3 LGTMs)

 On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:

> Contact emails
>
> yhi...@chromium.org,vas...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Design docs/spec
>
> Specification: https://w3c.github.io/webtransport/#web-transport
>
>
> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/669
>
>
> Summary
>
> WebTransport is an interface representing a set of reliable/unreliable 
> streams to a server. The interface potentially supports multiple 
> protocols, 
> but based on discussions on the IETF webtrans working group, we are 
> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying 
> protocol.
>
> Note that we were developing QuicTransport a.k.a. WebTransport over 
> QUIC and we ran an origin trial M84 through M90. It uses the same 
> interface 
> WebTransport, but because of the protocol difference ("quic-transport" 
> vs. 
> "https") it is difficult for web developers to be confused by them.
>
> new WebTransport("quic-transport://example.com:9922")
>
> represents a WebTransport over QUIC connection, and
>
> new WebTransport("https://example.com:9922;)
>
> represents a WebTransport over HTTP/3 connection.
>
> Goals for experimentation
>
> We're shipping the API in M97 
> .
>  
> Twitch, one of our partners, wants to continue their experiment until the 
> API is fully shipped. I think this is a reasonable request given we 
> originally aimed to ship the feature in M96 but we missed the branch 
> point.
>
> The original goals follow:
>
> To see whether the API (and the implementation) is useful in various 
> circumstances.
>
> Our partners want to evaluate this API on various network 
> circumstances (i.e., lab environments are not enough) to see its 
> effectiveness.
>
> We also expect feedback for performance.
>
> Experimental timeline
>
> M95 and M96
>
> Ongoing technical constraints
>
> None
>
> Debuggability
>
> The devtools support is under development.
>
> Just like with regular HTTP/3 traffic, the detailed information about 
> the connection can be obtained via chrome://net-export interface.
>
> 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: TLS ALPN extension in wss-schemed WebSockets connections

[Mike West]

I see. Thanks for the additional detail!

This still LGTM2, though. As you note, this brings us closer to what other
vendors are doing, and a better solution is going to require some new
agreement between folks about how to handle the set of servers you're
pointing at. Implementing that sounds like it would reasonably be
considered a separate intent.

-mike


On Thu, Jan 20, 2022 at 4:58 PM David Benjamin 
wrote:

> Well, there is, alas, still a difference because HTTP/2 + WebSockets is
> complicated.  But less of one at least. :-)
>
> (WebSockets support wasn't part of HTTP/2, and HTTP/3 for that matter,
> from the beginning. That means we can't be sure an HTTP/2-supporting server
> doesn't also support WebSockets, yet predate RFC 8441, and thus expect us
> to drop HTTP/2 for wss requests. So while we implement RFC 8441, it only
> kicks in if we happen to already have a suitable HTTP/2 connection on-hand.
> If we have to make a new connection, we drop HTTP/2 and only offer
> HTTP/1.1. Possibly something fancier ought to be done here, be it
> out-of-band signaling, defining an "h2+wss" ALPN, some kind of fallback
> like Firefox does, racing two connections, or whatever else. This Intent
> would be a prerequisite to doing that, but leaves the question for later.)
>
> On Thu, Jan 20, 2022 at 5:49 AM Mike West  wrote:
>
>> LGTM2. From a Fetch perspective, there shouldn't be a difference between
>> the way we establish a Web Socket connection and regular ol' HTTP requests.
>> Aligning our behavior with other vendors in this respect is appreciated!
>>
>> -mike
>>
>>
>> On Thu, Jan 20, 2022 at 12:22 AM Mike Taylor 
>> wrote:
>>
>>> LGTM1, thanks for improving interop here.
>>>
>>> On 1/19/22 3:22 PM, David Benjamin wrote:
>>>
>>> Contact emails david...@chromium.org
>>>
>>> Specification https://datatracker.ietf.org/doc/html/rfc7301
>>>
>>> Summary
>>>
>>> This is a PSA about a small tweak to an existing feature. The change is
>>> to include the TLS ALPN extension when initiating a new connection for
>>> wss-schemed WebSockets, offering just the default "http/1.1" protocol.
>>> Currently, unlike HTTPS connections, such connections do not offer ALPN in
>>> Chrome at all. Changing this aligns with Firefox and Safari, hardens
>>> against cross-protocol attacks (see ALPACA), and makes wss eligible for the
>>> False Start optimization. It also simplifies work on the HTTPS DNS record.
>>>
>>>
>>> Blink component Internals>Network>SSL
>>> 
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk is low. Firefox and Safari are already both
>>> offering ALPN for WebSockets requests, as does Chrome for HTTPS requests.
>>> This change does not impact the HTTP version we use for WebSockets itself,
>>> nor does it require servers to implement ALPN. Whether the server accepts
>>> ALPN or not, we will continue to speak WebSockets over HTTP/1.1.
>>>
>>>
>>> Gecko: Shipped/Shipping (Firefox appears to actually initially offer
>>> both "h2" and "http/1.1". Then, if it finds an HTTP/2 server without RFC
>>> 8441 support, it retries, only offering "http/1.1". Either way, it always
>>> offers ALPN.)
>>>
>>> WebKit: Shipped/Shipping (Confirmed via Wireshark)
>>>
>>> Web developers: No signals
>>>
>>> Other signals:
>>>
>>>
>>> Debuggability
>>>
>>> Existing DevTools support for networking and WebSockets applies
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>> n/a
>>>
>>> Requires code in //chrome? False
>>>
>>> Estimated milestones
>>>
>>> Chrome 100, as 99 is just about to branch
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5687059162333184
>>>
>>> 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/CAF8qwaA1Y_GZDk0qNc_%3DhVLhye%3DScEtxjPSdEPD-mM4zpVp50Q%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
>>> 

Re: [blink-dev] Intent to Ship: TLS ALPN extension in wss-schemed WebSockets connections

[David Benjamin]

Well, there is, alas, still a difference because HTTP/2 + WebSockets is
complicated.  But less of one at least. :-)

(WebSockets support wasn't part of HTTP/2, and HTTP/3 for that matter, from
the beginning. That means we can't be sure an HTTP/2-supporting server
doesn't also support WebSockets, yet predate RFC 8441, and thus expect us
to drop HTTP/2 for wss requests. So while we implement RFC 8441, it only
kicks in if we happen to already have a suitable HTTP/2 connection on-hand.
If we have to make a new connection, we drop HTTP/2 and only offer
HTTP/1.1. Possibly something fancier ought to be done here, be it
out-of-band signaling, defining an "h2+wss" ALPN, some kind of fallback
like Firefox does, racing two connections, or whatever else. This Intent
would be a prerequisite to doing that, but leaves the question for later.)

On Thu, Jan 20, 2022 at 5:49 AM Mike West  wrote:

> LGTM2. From a Fetch perspective, there shouldn't be a difference between
> the way we establish a Web Socket connection and regular ol' HTTP requests.
> Aligning our behavior with other vendors in this respect is appreciated!
>
> -mike
>
>
> On Thu, Jan 20, 2022 at 12:22 AM Mike Taylor 
> wrote:
>
>> LGTM1, thanks for improving interop here.
>>
>> On 1/19/22 3:22 PM, David Benjamin wrote:
>>
>> Contact emails david...@chromium.org
>>
>> Specification https://datatracker.ietf.org/doc/html/rfc7301
>>
>> Summary
>>
>> This is a PSA about a small tweak to an existing feature. The change is
>> to include the TLS ALPN extension when initiating a new connection for
>> wss-schemed WebSockets, offering just the default "http/1.1" protocol.
>> Currently, unlike HTTPS connections, such connections do not offer ALPN in
>> Chrome at all. Changing this aligns with Firefox and Safari, hardens
>> against cross-protocol attacks (see ALPACA), and makes wss eligible for the
>> False Start optimization. It also simplifies work on the HTTPS DNS record.
>>
>>
>> Blink component Internals>Network>SSL
>> 
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Interoperability risk is low. Firefox and Safari are already both
>> offering ALPN for WebSockets requests, as does Chrome for HTTPS requests.
>> This change does not impact the HTTP version we use for WebSockets itself,
>> nor does it require servers to implement ALPN. Whether the server accepts
>> ALPN or not, we will continue to speak WebSockets over HTTP/1.1.
>>
>>
>> Gecko: Shipped/Shipping (Firefox appears to actually initially offer
>> both "h2" and "http/1.1". Then, if it finds an HTTP/2 server without RFC
>> 8441 support, it retries, only offering "http/1.1". Either way, it always
>> offers ALPN.)
>>
>> WebKit: Shipped/Shipping (Confirmed via Wireshark)
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>>
>> Debuggability
>>
>> Existing DevTools support for networking and WebSockets applies
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>> n/a
>>
>> Requires code in //chrome? False
>>
>> Estimated milestones
>>
>> Chrome 100, as 99 is just about to branch
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5687059162333184
>>
>> 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/CAF8qwaA1Y_GZDk0qNc_%3DhVLhye%3DScEtxjPSdEPD-mM4zpVp50Q%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/26bac4d2-1d15-5ef5-d917-6ce7411ef6d3%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 

[blink-dev] Intent to Extend Experiment: Origin Private File System extension: AccessHandle

[Emanuel Krivoy]

We’d like to ask for an extension to our Origin Trial, from M99 to M101. As
mentioned in the Storage Foundation I2E
,
our partner intended to run a final series of tests with the new surface,
giving us a chance for to measure the impact of some of the design
decisions (the effect of a mixed sync/async surface and of all filesystem
operations being async). The tests were postponed and should happen in the
near future, and so we’d like to extend the trial to be able to gather
feedback from them.

Please find the Chrome Status template below:

Contact emails

fived...@chromium.org, r...@chromium.org

Explainer

https://github.com/WICG/file-system-access/blob/main/AccessHandle.md

Specification

WIP Draft: https://github.com/WICG/file-system-access/pull/344

Summary

The Origin Private File System (OPFS, part of the File System Access API)
is augmented with a new surface that brings very performant access to data.
This new surface differs from existing ones by offering in-place and
exclusive write access to a file’s content. This change, along with the
ability to consistently read unflushed modifications and the availability
of a synchronous variant on dedicated workers, significantly improves
performance and unblocks new use cases (especially for porting existing
IO-heavy applications to WebAssembly).

This Intent-to-Experiment is only in reference to the sync variant of the
API i.e., the createSyncAccessHandle() method and the SyncAccessHandle
object (only exposed in worker contexts):

const handle = await file.createSyncAccessHandle();

var writtenBytes = handle.write(buffer);

var readBytes = handle.read(buffer {at: 1});

The sync variant is meant to be consumed by low-level entities like
toolchains. We expect application developers to prefer the async API with
its streaming interface which will be shipped later.

AccessHandles is the new API shape for what was previously called Storage
Foundation API (Intent-to-Experiment:
http://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY.


Blink component

Blink>Storage>FileSystem


TAG review

https://github.com/w3ctag/design-reviews/issues/664

TAG review status

Closed, positive feedback.

Risks
Interoperability and Compatibility

The feature has to be compatible with existing ways to access data on OPFS
i.e., createWritable() and getFile(). The use of write locks and care for
backwards compatibility should mean that the risk here is low. In order to
ease compatibility concerns in the future, we've added an optional 'mode'
parameter to createAccessHandle()/createSyncAccessHandle(). This allows us
to eventually extend AccessHandle functionality to non-OPFS file systems
without necessarily taking the OPFS behaviour as default (more details here:
https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#exposing-accesshandles-on-all-filesystems
).

There is a risk of interoperability between vendors, pending the position
on implementing this surface. This design is the result of feedback from
Gecko and WebKit, who reviewed previous iterations of this functionality
and gave feedback that it should integrate more strongly with OPFS. We
directly shared documents outlining alternatives considered
,
and later our recommendation

towards this particular API shape.



We believe that the new design, when paired with a separate streams-based
extension to OPFS, meets the goal of more strongly integrating with the
existing surface. However, we have not yet received replies to the position
requests below.

Gecko: No formal signal, but generally positive reception with questions
about supporting existing surfaces (
https://github.com/mozilla/standards-positions/issues/562)

WebKit: In development (
https://lists.webkit.org/pipermail/webkit-dev/2021-August/031934.html)
Request for position was not answered, but the feature is being implemented
and is available in TP. See reference bug:
https://bugs.webkit.org/show_bug.cgi?id=231185

Web developers: Positive

>From our Storage Foundation OT, we received very positive feedback on the
need for high performance storage, as well as on the general shape of the
API:


   -

   Adobe’s support statement (about the need for the capability)
   
   -

   absurd-sql’s mention
   

   -

   Reception on Twitter after DevRel announcement
   


SyncAccessHandles have a very similar shape to the surface that was exposed
in Storage Foundation’s Origin Trial. The current implementation 

[blink-dev] Intent to Extend Experiment: Storage Foundation API

[Emanuel Krivoy]

Hello blink-dev,



We’d like to ask for an extension to our Origin Trial, from M99 to M101. As
mentioned in our previous I2E
,
our partner intended to run a final series of tests that would allow us to
measure the impact of the changes between Storage Foundation and its
successor Access Handles. The tests were postponed but should happen in the
near future, therefore we’d like to continue having concurrent Access
Handle/Storage Foundation trials.



Please find the Chrome Status template below:



Contact emails

fived...@chromium.org, r...@chromium.org

Explainer

https://github.com/WICG/storage-foundation-api-explainer

Specification

N/A

Summary

Storage Foundation API is a storage API that resembles a very basic
filesystem, with direct access to stored data through buffers and offsets.
Our goal is to give developers flexibility by providing generic, simple,
and performant primitives upon which they can build higher-level
components. It's particularly well suited for Wasm-based libraries and
applications that want to use custom storage algorithms to fine-tune
execution speed and memory usage.


Blink component

Blink>Storage


Search tags

storage , nativeio
, performance
, low-level
, generic
, foundation


TAG review

https://github.com/w3ctag/design-reviews/issues/566

TAG review status

Closed

Risks

Interoperability and Compatibility

This new feature has some potential interoperability risks due to its
nature as a novel and low-level API. Currently, there are no web features
that expose such a generic interface and that focus on WebAssembly ports as
one of it's main consumers.

We've also received feedback from other vendors that the functionality
added in Storage Foundation API seems duplicative of File System Access
API. We are exploring a merged design (details here:
https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec)
while collecting feedback and validating design choices with this
independent API.


Gecko: Negative (https://github.com/mozilla/standards-positions/issues/481)
Supportive of a low-level storage API, opposed to minting a new API instead
of taking a holistic approach to file access

WebKit: Negative (
https://lists.webkit.org/pipermail/webkit-dev/2021-February/031687.html) No
opposition to offering efficient access to files, strongly opposed to
minting a new API instead of augmenting an existing one.

Web developers: No signals


Goals for experimentation

In general, we would like to validate the whole surface of our API against
developer expectations and more diverse use cases. In particular, we are
interested in confirming that we provide the required performance to allow
new uses, and to shed light on developer preference between a synchronous
and asynchronous surface.

Reason this experiment is being extended

We added a new surface on OPFS (Access Handles:
https://github.com/WICG/file-system-access/blob/main/AccessHandle.md)  that
replaces Storage Foundation. Having concurrent trials would help us
validate the surface by comparing and contrasting it with the previous one.
Our partner will run a final series of tests with beta users, and this
provides a chance for us to measure the impact of some of the design
decisions we’ve made. In particular we’d like to see the effect of
providing a mixed sync/async surface on SyncAccessHandles and of all
filesystem operations being async. Concurrent trials would also make it
easier to measure any unexpected performance differences.


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

NativeIO

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=914488

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1143306

Estimated milestones

OriginTrial desktop last

98

OriginTrial desktop first

90

OriginTrial android last

98

OriginTrial android first

90


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5670244905385984

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/gh0gTHO18YQ

Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" 

Re: [blink-dev] Intent to Experiment: Conditional Focus

['Elad Alon' via blink-dev]

The partner I had for this feature had a change of scheduling, and will 
only be set to deploy their test use of it in about a month. I would 
therefore like to reset this experiment, stopping it for 3 weeks and then 
starting it afresh in m99-m102 (inclusive). Wdys?
Relevant: Discussions about standardizing this feature are proceeding and 
there seems to be interest from Mozilla and Apple. See here 
.

On Thursday, September 23, 2021 at 4:16:42 PM UTC+2 yoav...@chromium.org 
wrote:

> LGTM to experiment M96-M99 inclusive
>
> On Thu, Sep 23, 2021 at 4:04 PM Elad Alon  wrote:
>
>> m99, inclusive. So four milestones in total.
>>
>> On Thu, Sep 23, 2021 at 3:53 PM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Thu, Sep 23, 2021 at 3:00 PM Elad Alon  wrote:
>>>
 Might be good to move this to WICG to facilitate contributions (given 
> support 
> ).
>

 WICG issue #37  asked for 
 this to be adopted by the WICG. (The same partner supported it there too, 
 btw.)

>>>
>  Ping me and we'll move it over! :) 
>   
>
>>  

> https://github.com/WICG/proposals/issues/37#issuecomment-920673070 
> seems like a positive signal (even if from a single partner).
>

 Yes. And Mozilla and Apple also seemed interested in the use-case 
 during the WebRTC Working Group interim meeting of September 2021, 
 although 
 we're still discussing the specific details.
  

> What are the goals for the experiment?
>

 Validate that the proposed API solves developers' issues in a 
 satisfactory manner.
  

> What are the timeframes for the experimentation? Do you have partners 
> lined up?
>

 Two internal (Google), one external (Tella).

>>>
>>> What's the end milestone you're targeting? 
>>>
>>

-- 
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/f62597f2-5605-448c-8225-2283acf8a68an%40chromium.org.

Re: [blink-dev] Intent to Ship: TLS ALPN extension in wss-schemed WebSockets connections

[Mike West]

LGTM2. From a Fetch perspective, there shouldn't be a difference between
the way we establish a Web Socket connection and regular ol' HTTP requests.
Aligning our behavior with other vendors in this respect is appreciated!

-mike


On Thu, Jan 20, 2022 at 12:22 AM Mike Taylor  wrote:

> LGTM1, thanks for improving interop here.
>
> On 1/19/22 3:22 PM, David Benjamin wrote:
>
> Contact emails david...@chromium.org
>
> Specification https://datatracker.ietf.org/doc/html/rfc7301
>
> Summary
>
> This is a PSA about a small tweak to an existing feature. The change is to
> include the TLS ALPN extension when initiating a new connection for
> wss-schemed WebSockets, offering just the default "http/1.1" protocol.
> Currently, unlike HTTPS connections, such connections do not offer ALPN in
> Chrome at all. Changing this aligns with Firefox and Safari, hardens
> against cross-protocol attacks (see ALPACA), and makes wss eligible for the
> False Start optimization. It also simplifies work on the HTTPS DNS record.
>
>
> Blink component Internals>Network>SSL
> 
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk is low. Firefox and Safari are already both offering
> ALPN for WebSockets requests, as does Chrome for HTTPS requests. This
> change does not impact the HTTP version we use for WebSockets itself, nor
> does it require servers to implement ALPN. Whether the server accepts ALPN
> or not, we will continue to speak WebSockets over HTTP/1.1.
>
>
> Gecko: Shipped/Shipping (Firefox appears to actually initially offer both
> "h2" and "http/1.1". Then, if it finds an HTTP/2 server without RFC 8441
> support, it retries, only offering "http/1.1". Either way, it always offers
> ALPN.)
>
> WebKit: Shipped/Shipping (Confirmed via Wireshark)
>
> Web developers: No signals
>
> Other signals:
>
>
> Debuggability
>
> Existing DevTools support for networking and WebSockets applies
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> n/a
>
> Requires code in //chrome? False
>
> Estimated milestones
>
> Chrome 100, as 99 is just about to branch
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5687059162333184
>
> 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/CAF8qwaA1Y_GZDk0qNc_%3DhVLhye%3DScEtxjPSdEPD-mM4zpVp50Q%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/26bac4d2-1d15-5ef5-d917-6ce7411ef6d3%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/CAKXHy%3DdEBq79FSq_%2BAHAj8%3DFp1wYUiFRG9vZJegUKrjY1mNYPQ%40mail.gmail.com.