[blink-dev] Intent to Ship: Expose TransformStreamDefaultController

['Domenic Denicola' via blink-dev]

Contact emailsdome...@chromium.org

ExplainerNone (below "Summary" and "Motivation" should be enough).

Specificationhttps://streams.spec.whatwg.org/#ts-default-controller-class

Summary

This exposes the TransformStreamDefaultController class on the global
scope. This class already exists and can be accessed using code such as let
TransformStreamDefaultController; new TransformStream({ start(c) {
TransformStreamDefaultController = c.constructor; } }); This change makes
such code unnecessary as now TransformStreamDefaultController just exists
on the global scope.


*Motivation*

Possible uses for the exposed class include monkeypatching properties onto
TransformStreamDefaultController.prototype, or feature-testing existing
properties of it more easily. (Note that the class is not constructible,
i.e. new TransformStreamDefaultController() always throws, so that is not a
potential use.)

However, these uses are fairly esoteric. In practice this is mostly a
spec-conformance fix motivated by consistency.

Blink componentBlink>Network>StreamsAPI


TAG review statusNot applicable

Risks


Interoperability and Compatibility

No interop risk. This is already implemented in all other browsers. Compat
risk is minimal. It would be hard for any existing code to take a
dependency on this class not being exposed. Other related classes (e.g.
TransformStream itself) are already exposed. And we expose lots of classes
all the time without issue whenever shipping new features.


*Gecko*: Shipped/Shipping (
https://wpt.fyi/results/streams/idlharness.any.html?label=experimental&label=master&aligned
)

*WebKit*: Shipped/Shipping (
https://wpt.fyi/results/streams/idlharness.any.html?label=experimental&label=master&aligned
)

*Web developers*: No signals

Activation

This feature can be polyfilled with the single line of code: new
TransformStream({ start(c) { self.TransformStreamDefaultController =
c.constructor; } });

WebView application risks

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



Debuggability

No special DevTools support needed.


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


Requires code in //chrome?
False

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

Estimated milestones

M105


Anticipated spec changes

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

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

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/CAM0wra9GC6CsrapMO8CHdk7YQZnsJpv4MxV98u%2BKuM_N8z-8yw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Expose ReadableStreamDefaultController interface

[Domenic Denicola]

Thanks Alex! I'll work on the Intent now. A response to Joe's question
below.

On Thu, Jul 14, 2022 at 1:10 AM Joe Medley  wrote:

> Gang,
>
> I want to make sure I understand. It seems like this is just a bug fix or
> something like it. I want to understand before I agree that it doesn't need
> a mention in the blog post.
>
> Here's what I think it sounds like. The functionality shipped in Chrome 89
> as shown on the status entry, but it didn't actually work. Is that correct?
>

Not quite. What shipped in Chrome 89 was exposing
ReadableStreamDefaultController. What I am proposing to ship in Chrome 105
is the analogous exposure of TransformStreamDefaultController. They are two
separate changes, just very similar to each other.

They are both very small bug fixes that IMO are not really that interesting
to developers, since they are mostly about spec-conformance in an area
developers won't notice directly. So IMO they don't need a mention in the
blog post. But, that is not my determination to make, so feel free to judge
for yourself when you see the upcoming Intent. It won't hurt anything if
it's included.


>
> Joe
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Wed, Jul 13, 2022 at 8:44 AM Alex Russell 
> wrote:
>
>> Hey Domenic,
>>
>> Discussed at today's API OWNERS and we decided that:
>>
>>- It makes sense for this to be an intent
>>- We're happy to see this skipped for TAG review as it is covered by
>>previous reviews
>>- You should expect the intent to be fast-tracked once filed, and
>>please just link to this discussion as you file it
>>
>> Thanks in advance, and sorry for the overhead.
>>
>
>> Best,
>>
>> Alex
>>
>> On Tuesday, July 12, 2022 at 7:20:44 AM UTC+1 Domenic Denicola wrote:
>>
>>> While I'm happy to do it, I think I may not have explained the situation
>>> well enough, so let me ask a clarifying question...
>>>
>>> On Tue, Jul 12, 2022 at 3:00 PM Yoav Weiss 
>>> wrote:
>>>
 Hey Domenic!

 While I agree it's a very similar case, it's not identical.

>>> I agree that a TAG review is not needed here, nor getting positions from
 other vendors, but there's still some risk in exposing the interface where
 it wasn't exposed before. (e.g. sites using the lack of exposure for some
 weird feature detection)

 And while I don't think the risk here is high, it's non-zero. E.g.
 quickly scanning
 
 through the HTTPArchive [1], I see ~15K response bodies that contain the
 string "ReadableStreamDefaultController".

 So, I think it'd be good to send out a new intent and discuss the risks
 and whether we need to do something to counter them (e.g. sampled analysis
 of HTTPArchive data, ClusterTelemetry run with tighter counters, or maybe
 nothing at all).

 I know it'd create some extra overhead, but would enable us to keep
 track of this specific change and its current risks.

>>>
>>> What risk would you be imagining? It seems like a high burden to ask
>>> people to do HTTPArchive analysis just to fix an exposure bug like this,
>>> especially one where all other browsers already expose the global. Like, we
>>> don't ask people to do HTTP archive analysis when exposing entire new
>>> features which come with multiple new globals, where Chrome is shipping
>>> first, so I don't see why this case would need such analysis. Indeed, many
>>> Intent to Ships have sailed through the API Owners with "No compat
>>> concerns; this is a new feature".
>>>
>>> To be clear, I'm willing (if not excited) to spend 2x the time I spent
>>> on the CL doing all the ChromeStatus rigamarole and sending an email, if
>>> the result is going to be a quick 3 LGTMs because it's trivial and we're
>>> just checking some process boxes. I'm not really willing to spend more time
>>> than that on this bugfix, though...
>>>
>>>

 Cheers,
 Yoav

 [1]
 SELECT page, url
 FROM `httparchive.response_bodies.2022_07_01_desktop`
 #FROM `httparchive.sample_data.response_bodies_desktop_10k`
 WHERE body like "%TransformStreamDefaultController%"


 On Tue, Jul 12, 2022 at 5:56 AM TAMURA, Kent 
 wrote:

> IMO, it's a bug fix and we don't need a dedicated I2S.
>
> On Tue, Jul 12, 2022 at 11:37 AM Domenic Denicola <
> dome...@chromium.org> wrote:
>
>> Hey all,
>>
>> Today I was browsing
>> https://wpt.fyi/results/streams?label=experimental&label=master&aligned
>> and noticed that we were failing tests because of an analogous 
>> non-exposure
>> of TransformStreamDefaultController. I have a CL to fix this at
>> https://chromium-review.googlesource.com/c/chromium/src/+/3757032
>> and was thinking it should be OK to just ping this

Re: [blink-dev] Intent to Deprecate and Remove: CSS default keyword is disallowed in custom identifiers

[David Baron]

On Mon, Jul 11, 2022 at 12:10 PM Joe Medley  wrote:

> In which milestone will this be removed?
>

Assuming nothing changes, Chrome 105.  I've updated chromestatus.

On Thu, Jul 7, 2022 at 10:36 AM David Baron  wrote:

> As far as what the breakage might look like:  it would look different for
> the different uses of custom idents in CSS.  The possible cases are the CSS
> features that (a) use custom idents and (b) are shipping (no flag or a flag
> with "status: stable") and (c) don't already separately forbid default.
> That list is the following:
>
>- CSS animation names (the @keyframes rule and the value of
>animation-name).  In this case, the breakage would most likely be the
>absence of a CSS animation that was supposed to happen.  It could also lead
>to a *different* set of CSS animations running, if one (now broken) CSS
>declaration of animation or animation-name was previously overriding
>another (still working) one.
>- CSS counter names in the counter-reset, counter-increment, and
>counter-set properties and the counter() and counters() values of the
>content property.  This failure would likely lead to incorrect
>numbering of list-items, footnotes, headings, or something else numbered
>via CSS.
>- The CSS Paint API accepts custom idents as names of the paint
>functions.  Failure here would lead to a custom paint use not working.
>- A property defined with the @property at-rule's syntax descriptor to
>take a  value would also no longer accept default as a
>value where the  was used.
>- The CSS page property accepts custom idents for named pages.  This
>could lead to printing on an incorrectly sized or oriented page or with
>incorrect margins.
>- The CSS @counter-style rule's symbol descriptor accepts custom
>idents in place of strings.  Use of "default" here seems very unlikely in
>valid usage since it is unlikely that the string "default" is used as a
>list marker.
>- The values of CSS transition-property accept custom-idents as a
>forward-compatibility mechanism, to avoid having parse errors when current
>and future CSS properties are mixed.  This means that if a developer
>attempted to specify a transition on a list of CSS properties that included
>default, behavior could change, because that list would now be ignored
>(either leaving no transitions or fallback to another declaration).
>- Likewise, the CSS color-scheme property accepts custom-idents as a
>forward-compatibility mechanism.
>
>
In the process of writing the change, I found that there were some
additional cases (that I could remove in the change) that separately
forbade default.  This means that, for my 8 item list above, I should
actually have removed the fourth and eighth items:

   - the @property at-rule's syntax descriptor
   - the color-scheme property

and thus there are only 6 cases where I believe the behavior changes.

-David


> On Wed, Jul 6, 2022 at 9:50 PM David Baron  wrote:
>>
>>> Contact emailsdba...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://www.w3.org/TR/css-values-3/#custom-idents
>>>
>>> Summary
>>>
>>> The CSS keyword 'default' is not allowed within CSS custom identifiers,
>>> which are used for many types of user-defined names in CSS (for example,
>>> names created by @keyframes rules, counters, @container names, custom
>>> layout or paint names). This adds 'default' to the list of names that are
>>> reserved from being used in custom identifiers, which already reserve
>>> 'inherit', 'initial', 'unset', 'revert', and 'revert-layer'.
>>>
>>>
>>> Note that some existing CSS features that accept custom identifiers
>>> check specifically for 'default' to avoid the risk of worsening the
>>> potential compatibility problem in this deprecation. This means that fixing
>>> the general code for custom identifiers will fix the remaining cases,
>>> though some cases are already fixed.
>>>
>>> Blink componentBlink>CSS
>>> 
>>>
>>> Motivation
>>>
>>> Keywords that CSS uses (or is likely to use in the future) as values
>>> accepted by any CSS property should not be allowed in custom identifiers
>>> because many custom identifiers are also values of CSS properties. If they
>>> can be custom identifiers, then developers could create content that would
>>> be broken by the addition of these keywords as property values either to
>>> all CSS properties, or to a particular CSS property that already accepts
>>> custom identifiers.
>>>
>>>
>>> Initial public proposal
>>>
>>> TAG review
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> There is some compatibility risk if pages are using default as a custom
>>> identifier (for example, as the name of an @keyframes rule that is
>>> referenced in animation-name). This risk is lessened by the fact that Gecko
>>> a

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

[Khushal Sagar]

On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor  wrote:

> On 7/13/22 3:04 PM, Khushal Sagar wrote:
>
>
>
> On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss  wrote:
>
>>
>>
>> On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:
>>
>>> On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss 
>>> wrote:
>>>


 On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar 
 wrote:

> Contact emails khushalsa...@chromium.org, vmp...@chromium.org
>
> Explainer
> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
> https://github.com/w3c/csswg-drafts/issues/7058
>
> Specification
> https://drafts.csswg.org/css-overflow/#overflow-properties
>
> Summary
>
> This change allows developers to use the existing `overflow` property
> with replaced elements that paint outside the content-box. Paired with
> `object-view-box` this can be used to create an image with a custom glow 
> or
> shadow applied, with proper ink-overflow behavior like a CSS shadow would
> have.
>
> Blink component Blink>CSS
> 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/750
>
> TAG review status Pending
>
> Risks
> Interoperability and Compatibility
>
> This feature changes the behaviour of the existing overflow property
> on replaced elements (img, video, canvas). Currently `overflow:visible` in
> a developer stylesheet on such elements is ignored during paint and the
> content is clipped to the element's content-box. With this feature,
> `overflow:visible` will result in content outside the element's 
> content-box
> to paint as ink overflow. We've collected use counter data to measure the
> number of sites which could be affected by this. The use counter data
> collected over 1 week of a stable release (M102) is as follows. We
> collected 2 different counters explained below. * The first measures any
> instance where overflow is explicitly set from developer styles to 
> visible.
> The percentage of page loads with this is 2.16%. * The second measures the
> above instances but only includes the cases with object-fit set to cover 
> or
> none or object-position set to any value other than the default (50% 50%).
> The rationale behind this counter is to exclude cases which can not cause
> overflow (such as object-fit:contain), even if overflow is set to visible.
> The percentage of page loads with this is 0.017%.
>

 That's not nothing. Any idea what breakage may look like?
 Can we maybe collect histograms on *how much* overflow would occur in
 those cases? (maybe with ClusterTelemetry initially, to get a rough idea in
 the lab)

>>>
>>> I ran an analysis on CT using top 100k sites for desktop and top 10k
>>> sites on mobile. The raw numbers are here: desktop
>>> 
>>> and mobile
>>> ,
>>> and the rough patch
>>>  to
>>> collect this data. The highlights from the analysis are below:
>>>
>>>- The number of sites which override the default CSS to allow
>>>overflow *and* also had overflow during painting was 13 out of 10k on
>>>mobile and 39 out of 63k on desktop (only 63k sites yielded results out 
>>> of
>>>100k).
>>>
>>>- I measured the percentage of area painted outside the content box
>>>out of the total painted area. The highest was 88% on desktop and 70% on
>>>mobile.
>>>
>>>
>> I'm not sure what that means in practice. Can you elaborate? Have you
>> looked at extreme cases to see the impact there?
>>
>
> Sorry, I should've added more details. :) I was looking for breakages with
> 2 numbers: sites with the largest number of overflowing pixels (such that
> other content could be occluded); sites with the largest percentage of
> image content outside the content box. But I realize the former is probably
> better to identify breakages.
>
> Looking at the top 10 sites, the worst affected is liveops.com. This has
> cases which use object-fit:cover so the image scales to a size bigger than
> its content rect and developer CSS overrides overflow to visible.
> Unfortunately, interacting more with this site, I did see images which are
> drawing above other content (screenshot attached) as you scroll down. This
> pattern showed up on the rest of the sites with high overflow numbers too
> (another example with screenshot attached).
>
> This kind of breakage is expected with this change. I'm not sure where to
> put the cutoff to identify sites with significant breakage, but there are
> at least 30 sites (out of 63k) that have images

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

[Mike Taylor]

On 7/13/22 3:04 PM, Khushal Sagar wrote:



On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss  wrote:



On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:

On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss
 wrote:



On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar
 wrote:


Contact emails

khushalsa...@chromium.org, vmp...@chromium.org


Explainer


https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
https://github.com/w3c/csswg-drafts/issues/7058


Specification

https://drafts.csswg.org/css-overflow/#overflow-properties


Summary

This change allows developers to use the existing
`overflow` property with replaced elements that paint
outside the content-box. Paired with `object-view-box`
this can be used to create an image with a custom glow
or shadow applied, with proper ink-overflow behavior
like a CSS shadow would have.


Blink component

Blink>CSS




TAG review

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


TAG review status

Pending


Risks


Interoperability and Compatibility

This feature changes the behaviour of the existing
overflow property on replaced elements (img, video,
canvas). Currently `overflow:visible` in a developer
stylesheet on such elements is ignored during paint
and the content is clipped to the element's
content-box. With this feature, `overflow:visible`
will result in content outside the element's
content-box to paint as ink overflow. We've collected
use counter data to measure the number of sites which
could be affected by this. The use counter data
collected over 1 week of a stable release (M102) is as
follows. We collected 2 different counters explained
below. * The first measures any instance where
overflow is explicitly set from developer styles to
visible. The percentage of page loads with this is
2.16%. * The second measures the above instances but
only includes the cases with object-fit set to cover
or none or object-position set to any value other than
the default (50% 50%). The rationale behind this
counter is to exclude cases which can not cause
overflow (such as object-fit:contain), even if
overflow is set to visible. The percentage of page
loads with this is 0.017%.


That's not nothing. Any idea what breakage may look like?
Can we maybe collect histograms on *how much* overflow
would occur in those cases? (maybe with ClusterTelemetry
initially, to get a rough idea in the lab)


I ran an analysis on CT using top 100k sites for desktop and
top 10k sites on mobile. The raw numbers are here: desktop


and mobile

,
and the rough patch
 to
collect this data. The highlights from the analysis are below:

  * The number of sites which override the default CSS to
allow overflow *and* also had overflow during painting was
13 out of 10k on mobile and 39 out of 63k on desktop (only
63k sites yielded results out of 100k).

  * I measured the percentage of area painted outside the
content box out of the total painted area. The highest was
88% on desktop and 70% on mobile.


I'm not sure what that means in practice. Can you elaborate? Have
you looked at extreme cases to see the impact there?


Sorry, I should've added more details. :) I was looking for breakages 
with 2 numbers: sites with the largest number of overflowing pixels 
(such that other content could be occluded); sites with the largest 
percentage of image content outside the content box. But I realize the 
former is probably better to identify breakages.


Looking at the top 10 sites, the worst affected is liveops.com 
. This has cases which use object-fit:cover so the 
image scales to a s

RE: [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async API read/write HTML format with DataTransfer API

['Anupam Snigdha' via blink-dev]

The unsanitized option being proposed here is only for the well-known HTML 
format. It could be extended to other well-known formats, but for now we are 
focusing on the HTML format. Web custom format is unsanitized by design, so 
this option doesn’t affect the existing web custom formats.

From: Thomas Steiner 
Sent: Wednesday, July 13, 2022 9:56 AM
To: Anupam Snigdha 
Cc: Ana Sollano Kim ; Bo Cupp ; 
Thomas Steiner ; blink-dev@chromium.org
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async API 
read/write HTML format with DataTransfer API

Just to clarify on my end, I was referring to the “Web Custom formats for Async 
Clipboard API” explainer 
(https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md).
 I was under the impression that this would replace the previous `unsanitized: 
true` flag (
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#alternative-considered-unsanitizedtrue).

On Wed 13. Jul 2022 at 18:41 Anupam Snigdha 
mailto:sni...@microsoft.com>> wrote:
Just to clarify some of the points in the explainer. This proposal introduces 
an `unsanitized` option only in the navigator.clipboard.read() method. For 
write() we will always write unsanitized HTML content to the clipboard. This 
will align the behavior of async APIs with the DataTransfer APIs and also be 
backward compatible with the native apps on certain platforms like Windows that 
rely on this behavior. With the current sanitization in async API, copy pasting 
HTML content in Office native apps is broken because we remove custom styles 
from the HTML markup, inline styles into the fragment that increases the size 
of the copy payload etc when we write the HTML format to the system clipboard.

This proposal is a Chromium specific change because Firefox and Safari opposed 
to having an unsanitized option in the read() method, but they agreed to align 
the behavior of async APIs with DataTransfer 
APIs. 
We shipped the sanitization behavior first, so changing that would be a 
breaking change for us. Safari has the sanitization behavior for cross-origin 
copy-paste, but for same origin, they allow access to unsanitized HTML content. 
Safari’s async APIs behavior is aligned with the DataTransfer APIs so they 
don’t want to add an unsanitized option to read() method and cause backward 
compatibility issues. Firefox behaves the same as Chromium, but we didn’t see 
any support from them for adding an unsanitized option in read() method to 
allow web authors to access unsanitized HTML content.
Even though the usage of async 
read/write
 is low, we got feedback from 
security
 and other 
stakeholders
 that changing the behavior of the API would break the existing sites that rely 
on the sanitization behavior and also make the API “less secure”. Adding an 
option to switch between sanitized and unsanitized HTML content during read, 
and always writing unsanitized HTML content to the system clipboard would 
address both backward compatibility and security concerns.
Please let us know if you have any questions/concerns.

-Anupam

From: Thomas Steiner mailto:to...@google.com>>
Sent: Tuesday, July 12, 2022 9:57 PM
To: Ana Sollano Kim 
mailto:ana.soll...@microsoft.com>>
Cc: Anupam Snigdha mailto:sni...@microsoft.com>>; Bo Cupp 
mailto:pc...@microsoft.com>>; 
blink-dev@chromium.org
Subject: [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async API 
read/write HTML format with DataTransfer API

With the Pickling 
API
 proposal, we will be introducing a new `unsanitized` parameter in the read 
method so the content is round trippable i.e. read would return the content 
without any sanitization.

This last part is no longer true as far as I know: the `unsanitized` parameter 
was replaced with prepending `'web '` to the MIME type. It doesn’t change the 
described round-trip behavior, just needs updating in the Explainer.

On Wed 13. Jul 2022 at 06:24 'Ana Sollano Kim' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:

Contact emails

ansol...@microsoft.com, 
sni...@microsoft.com, 
pc...@microsoft.com

Explainer

https://docs.google.com/document/d/1rTEg2I-hMPXGiLrEMqKJz2Ycu6GRjlM3uvakOe84m8Q/edit?usp=sharing

Specification

None

Summary

This proposal aligns the HTML format read/write async API with the 
setData/getData DataTransfer APIs. Currently, when we read

Re: [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async API read/write HTML format with DataTransfer API

['Thomas Steiner' via blink-dev]

Just to clarify on my end, I was referring to the “Web Custom formats for
Async Clipboard API” explainer (
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md).
I was under the impression that this would replace the previous
`unsanitized: true` flag (
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#alternative-considered-unsanitizedtrue
).

On Wed 13. Jul 2022 at 18:41 Anupam Snigdha  wrote:

> Just to clarify some of the points in the explainer. This proposal
> introduces an `unsanitized` option only in the navigator.clipboard.read()
> method. For write() we will always write unsanitized HTML content to the
> clipboard. This will align the behavior of async APIs with the DataTransfer
> APIs and also be backward compatible with the native apps on certain
> platforms like Windows that rely on this behavior. With the current
> sanitization in async API, copy pasting HTML content in Office native apps
> is broken because we remove custom styles from the HTML markup, inline
> styles into the fragment that increases the size of the copy payload etc
> when we write the HTML format to the system clipboard.
>
>
>
> This proposal is a Chromium specific change because Firefox and Safari
> opposed to having an unsanitized option in the read() method, but they agreed
> to align the behavior of async APIs with DataTransfer APIs
> .
> We shipped the sanitization behavior first, so changing that would be a
> breaking change for us. Safari has the sanitization behavior for
> cross-origin copy-paste, but for same origin, they allow access to
> unsanitized HTML content. Safari’s async APIs behavior is aligned with the
> DataTransfer APIs so they don’t want to add an unsanitized option to read()
> method and cause backward compatibility issues. Firefox behaves the same as
> Chromium, but we didn’t see any support from them for adding an unsanitized
> option in read() method to allow web authors to access unsanitized HTML
> content.
>
> Even though the usage of async read
> 
> /write
> 
> is low, we got feedback from security
> 
> and other stakeholders
> 
> that changing the behavior of the API would break the existing sites that
> rely on the sanitization behavior and also make the API “less secure”.
> Adding an option to switch between sanitized and unsanitized HTML content
> during read, and always writing unsanitized HTML content to the system
> clipboard would address both backward compatibility and security concerns.
>
> Please let us know if you have any questions/concerns.
>
>
>
> -Anupam
>
>
>
> *From:* Thomas Steiner 
> *Sent:* Tuesday, July 12, 2022 9:57 PM
> *To:* Ana Sollano Kim 
> *Cc:* Anupam Snigdha ; Bo Cupp ;
> blink-dev@chromium.org
> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async
> API read/write HTML format with DataTransfer API
>
>
>
> *With the **Pickling API*
> *
> proposal, we will be introducing a new `unsanitized` parameter in the read
> method so the content is round trippable i.e. read would return the content
> without any sanitization.*
>
>
>
> This last part is no longer true as far as I know: the `unsanitized`
> parameter was replaced with prepending `'web '` to the MIME type. It
> doesn’t change the described round-trip behavior, just needs updating in
> the Explainer.
>
>
>
> On Wed 13. Jul 2022 at 06:24 'Ana Sollano Kim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> *Contact emails*
>
> ansol...@microsoft.com, sni...@microsoft.com, pc...@microsoft.com
>
> *Explainer*
>
>
> https://docs.google.com/document/d/1rTEg2I-hMPXGiLrEMqKJz2Ycu6GRjlM3uvakOe84m8Q/edit?usp=sharing
>
> *Specification*
>
> None
>
> *Summary*
>
> This proposal aligns the HTML format read/write async API with the
> setData/getData DataTransfer APIs. Currently, when we read/write text/html
> MIME types using the async API, the sanitizer is invoked to strip out
> contents from the HTML markup due to security concerns, and styles are
> inlined in the HTML. This leads to loss of fidelity of HTML content when
> read by web authors or native apps.
>
> *Motivation*
>
> Using DataTransfer object’s setData and async clipboard write method, we
> are seeing interop differences in how the HTML content is sanitized and
> written to the clipboard. In Chromium, async clipboard write method clears
> the clipboard content first and then writes the payload which results in
> overwriting the previous HTML content that was inserted by authors using
> DataTran

RE: [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async API read/write HTML format with DataTransfer API

['Anupam Snigdha' via blink-dev]

Just to clarify some of the points in the explainer. This proposal introduces 
an `unsanitized` option only in the navigator.clipboard.read() method. For 
write() we will always write unsanitized HTML content to the clipboard. This 
will align the behavior of async APIs with the DataTransfer APIs and also be 
backward compatible with the native apps on certain platforms like Windows that 
rely on this behavior. With the current sanitization in async API, copy pasting 
HTML content in Office native apps is broken because we remove custom styles 
from the HTML markup, inline styles into the fragment that increases the size 
of the copy payload etc when we write the HTML format to the system clipboard.

This proposal is a Chromium specific change because Firefox and Safari opposed 
to having an unsanitized option in the read() method, but they agreed to align 
the behavior of async APIs with DataTransfer 
APIs. 
We shipped the sanitization behavior first, so changing that would be a 
breaking change for us. Safari has the sanitization behavior for cross-origin 
copy-paste, but for same origin, they allow access to unsanitized HTML content. 
Safari’s async APIs behavior is aligned with the DataTransfer APIs so they 
don’t want to add an unsanitized option to read() method and cause backward 
compatibility issues. Firefox behaves the same as Chromium, but we didn’t see 
any support from them for adding an unsanitized option in read() method to 
allow web authors to access unsanitized HTML content.
Even though the usage of async 
read/write
 is low, we got feedback from 
security
 and other 
stakeholders
 that changing the behavior of the API would break the existing sites that rely 
on the sanitization behavior and also make the API “less secure”. Adding an 
option to switch between sanitized and unsanitized HTML content during read, 
and always writing unsanitized HTML content to the system clipboard would 
address both backward compatibility and security concerns.
Please let us know if you have any questions/concerns.

-Anupam

From: Thomas Steiner 
Sent: Tuesday, July 12, 2022 9:57 PM
To: Ana Sollano Kim 
Cc: Anupam Snigdha ; Bo Cupp ; 
blink-dev@chromium.org
Subject: [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async API 
read/write HTML format with DataTransfer API

With the Pickling 
API
 proposal, we will be introducing a new `unsanitized` parameter in the read 
method so the content is round trippable i.e. read would return the content 
without any sanitization.

This last part is no longer true as far as I know: the `unsanitized` parameter 
was replaced with prepending `'web '` to the MIME type. It doesn’t change the 
described round-trip behavior, just needs updating in the Explainer.

On Wed 13. Jul 2022 at 06:24 'Ana Sollano Kim' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:

Contact emails

ansol...@microsoft.com, 
sni...@microsoft.com, 
pc...@microsoft.com

Explainer

https://docs.google.com/document/d/1rTEg2I-hMPXGiLrEMqKJz2Ycu6GRjlM3uvakOe84m8Q/edit?usp=sharing

Specification

None

Summary

This proposal aligns the HTML format read/write async API with the 
setData/getData DataTransfer APIs. Currently, when we read/write text/html MIME 
types using the async API, the sanitizer is invoked to strip out contents from 
the HTML markup due to security concerns, and styles are inlined in the HTML. 
This leads to loss of fidelity of HTML content when read by web authors or 
native apps.

Motivation

Using DataTransfer object’s setData and async clipboard write method, we are 
seeing interop differences in how the HTML content is sanitized and written to 
the clipboard. In Chromium, async clipboard write method clears the clipboard 
content first and then writes the payload which results in overwriting the 
previous HTML content that was inserted by authors using DataTransfer object’s 
setData API. It’d be beneficial for web authors if async clipboard and setData 
APIs provide the same HTML content during copy operation, so that round 
tripping is possible without any interop differences.

Moreover, creating a fragment and inlining the styles bloats the payload and 
strips out the custom styles inserted by sites like Excel Online that are used 
to preserve excel specific semantics.

Comments

Discussion between stakeholders: 
https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit

[blink-dev] Intent to Prototype: HTTP response status code in Resource Timing

[Abin Paul]

Contact emails

abin.pa...@gmail.com

Explainer

https://github.com/abinpaul1/resource-timing/blob/explainer-resource-response-status/Explainers/Response_Status_Code.md

Specification

Resource Timing PR : https://github.com/w3c/resource-timing/pull/335

Fetch PR : https://github.com/whatwg/fetch/pull/1468


Summary

Adds a field to PerfomanceResourceTiming to indicate the HTTP response
status when the resource was fetched.


Blink component

Blink>PerformanceAPIs>ResourceTiming


Motivation

Currently there is no straightforward way to tell if a resource failed
loading for developers using the Resource Timing API. Indications exist for
errored responses, but not for requests that got an error response.

Exposing the status would enable analysis by segregation of resources based
on the returned status.  Analysis of 4xx and 5xx responses would be easier


Initial public proposal

https://github.com/w3c/resource-timing/pull/335

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: https://github.com/mozilla/standards-positions/issues/665

WebKit: https://github.com/WebKit/standards-positions/issues/35

Web developers:  https://github.com/w3c/resource-timing/issues/90 is a good
signal showing interest in the feature.

Other signals:

WebView application risks

Does this intent deprecate or change behaviour 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

?

Yes

Flag name

ResourceTimingResponseStatusCode

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5163838794629120

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/CAM2ZH3ckNhJ%3DdQmoprkfVU%2Bt5akcUyK9f2%2Bi%3DMRis2TKx63Brg%40mail.gmail.com.

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

[Yaseen Khan]

Hi Team,

Earliar chromium browser was displaying an error message as 
*document.domain* is going to deperecated in *M106*. Now I can not see this 
message and in some blogs postpone to *M109*. Could you confirm on this - 
when does this actually would enabled and in which version. It would be 
great if you could share dates for better planning to mitigate this very 
high risk in our platform.


On Monday, 23 May 2022 at 18:06:08 UTC+5:30 Daniel Vogelheim wrote:

> Thanks all for the feedback. Update(s):
> - The warnings are live, for about two weeks now. Usage is trending down, 
> but slowly.
> - I'd like to postpone flipping the default to M109, as requested (here, 
> and offline). The existing caveats - particularly a new intent, as 
> requested by Yoav upthread - still apply.
>
> On Tue, Apr 26, 2022 at 10:13 PM 'tuvia.kaha...@gtempaccount.com' via 
> blink-dev  wrote:
>
>> We also have a fair amount of dependencies on domain lowering via 
>> document.domain, which affects millions of users. We are in the process of 
>> providing solutions for that, but we need more time than M106.
>>
>> Thanks
>>
>> On Tuesday, December 14, 2021 at 4:09:07 PM UTC+2 voge...@chromium.org 
>> wrote:
>>
>>> Contact emails
>>>
>>>
>>> *va...@chromium.org, voge...@chromium.org*Specification
>>>
>>>
>>> *Explainer: https://github.com/mikewest/deprecating-document-domain 
>>> HTML Spec draft: 
>>> https://github.com/whatwg/html/compare/main...otherdaniel:dd 
>>> *API spec
>>>
>>>
>>> *Yes*Summary
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Change the default behavior of the Origin-Agent-Cluster: header / 
>>> document.domain settability.Presently, pages within Chromium have 
>>> site-keyed agent clusters by default, unless the Origin-Agent-Cluster: 
>>> header is explicitly set to true. This accommodates pages or frames which 
>>> want to access each other's state, despite being on different origins (but 
>>> within a site). This is fine for any pages that wish to do so, but because 
>>> a page *might* set document.domain later on, Chromium currently must use 
>>> site-keyed agent clusters for *all* pages by default even though the 
>>> overwhelming majority of pages do not ever make use of this (mis-)feature. 
>>> In turn, this requires Chromium to use sites as the basis for renderer 
>>> process isolation (via Site Isolation), which exposes origins to same-site 
>>> but cross-origin attacks involving compromised renderer processes or the 
>>> "Spectre" family of side-channel attacks.This proposal changes the default 
>>> behaviour of Origin-Agent-Cluster. From a developer's point of view, the 
>>> new default matches "Origin-Agent-Cluster: ?1". The initial implementation 
>>> will use origin-keyed agent clusters for all (non-opted out) origins, 
>>> without changing how many processes Chromium creates. Over time, we can 
>>> then adapt Chromium's isolation strategy towards origin-keyed processes 
>>> without further affecting web-visible behaviour.The developer-visible 
>>> aspect of this is that for pages with origin-keyed agent clusters, 
>>> document.domain is no longer settable. Thus, we have marked this intent as 
>>> a deprecation.Note that this proposal is about the default. Both modes - 
>>> site-keyed or origin-keyed agent clusters - remain available to any site, 
>>> but origin-keyed agent clusters change from opt-in to opt-out. The current 
>>> behaviour remains available by setting "Origin-Agent-Cluster: ?0".*Blink 
>>> component
>>>
>>>
>>> *Blink>SecurityFeature*TAG review
>>>
>>>
>>> *https://github.com/w3ctag/design-reviews/issues/564 
>>> (The thread is a bit 
>>> unwieldy, but there do not seem to be open issues.)*Risks: 
>>> Interoperability and Compatibility
>>>
>>> *No interoperability risks.*
>>>
>>> Compatibility risk exists, but is fairly small as document.domain is an 
>>> already deprecated feature. We’ve detailed UKM metrics in place and are 
>>> planning to reach out to top users as soon as we’ve LGTMs for the plan. 
>>>
>>>
>>> Current usage of the document.domain: 0.05% 
>>>  of 
>>> page views rely upon document.domain to enable some cross-origin access 
>>> that wasn't otherwise possible. 0.24% 
>>>  of 
>>> page views block same-origin access because only one side sets 
>>> document.domain. Both counters can be found on 
>>> https://deprecate.it/#document-domain, too.
>>>
>>> We’ve reached out in advance to 4 of the top current users - TL;DR Most 
>>> of their use cases could be achieved already by different APIs e.g. 
>>> Audio/video autoplay in iframes by adding the ‘autoplay’ attribute, support 
>>> chat deployed across subdomains.
>>>
>>>
>>> Gecko: Standards position request 
>>> 

Re: [blink-dev] Re: Intent to Ship: Expose ReadableStreamDefaultController interface

['Joe Medley' via blink-dev]

Gang,

I want to make sure I understand. It seems like this is just a bug fix or
something like it. I want to understand before I agree that it doesn't need
a mention in the blog post.

Here's what I think it sounds like. The functionality shipped in Chrome 89
as shown on the status entry, but it didn't actually work. Is that correct?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jul 13, 2022 at 8:44 AM Alex Russell 
wrote:

> Hey Domenic,
>
> Discussed at today's API OWNERS and we decided that:
>
>- It makes sense for this to be an intent
>- We're happy to see this skipped for TAG review as it is covered by
>previous reviews
>- You should expect the intent to be fast-tracked once filed, and
>please just link to this discussion as you file it
>
> Thanks in advance, and sorry for the overhead.
>
> Best,
>
> Alex
>
> On Tuesday, July 12, 2022 at 7:20:44 AM UTC+1 Domenic Denicola wrote:
>
>> While I'm happy to do it, I think I may not have explained the situation
>> well enough, so let me ask a clarifying question...
>>
>> On Tue, Jul 12, 2022 at 3:00 PM Yoav Weiss 
>> wrote:
>>
>>> Hey Domenic!
>>>
>>> While I agree it's a very similar case, it's not identical.
>>>
>> I agree that a TAG review is not needed here, nor getting positions from
>>> other vendors, but there's still some risk in exposing the interface where
>>> it wasn't exposed before. (e.g. sites using the lack of exposure for some
>>> weird feature detection)
>>>
>>> And while I don't think the risk here is high, it's non-zero. E.g.
>>> quickly scanning
>>> 
>>> through the HTTPArchive [1], I see ~15K response bodies that contain the
>>> string "ReadableStreamDefaultController".
>>>
>>> So, I think it'd be good to send out a new intent and discuss the risks
>>> and whether we need to do something to counter them (e.g. sampled analysis
>>> of HTTPArchive data, ClusterTelemetry run with tighter counters, or maybe
>>> nothing at all).
>>>
>>> I know it'd create some extra overhead, but would enable us to keep
>>> track of this specific change and its current risks.
>>>
>>
>> What risk would you be imagining? It seems like a high burden to ask
>> people to do HTTPArchive analysis just to fix an exposure bug like this,
>> especially one where all other browsers already expose the global. Like, we
>> don't ask people to do HTTP archive analysis when exposing entire new
>> features which come with multiple new globals, where Chrome is shipping
>> first, so I don't see why this case would need such analysis. Indeed, many
>> Intent to Ships have sailed through the API Owners with "No compat
>> concerns; this is a new feature".
>>
>> To be clear, I'm willing (if not excited) to spend 2x the time I spent on
>> the CL doing all the ChromeStatus rigamarole and sending an email, if the
>> result is going to be a quick 3 LGTMs because it's trivial and we're just
>> checking some process boxes. I'm not really willing to spend more time than
>> that on this bugfix, though...
>>
>>
>>>
>>> Cheers,
>>> Yoav
>>>
>>> [1]
>>> SELECT page, url
>>> FROM `httparchive.response_bodies.2022_07_01_desktop`
>>> #FROM `httparchive.sample_data.response_bodies_desktop_10k`
>>> WHERE body like "%TransformStreamDefaultController%"
>>>
>>>
>>> On Tue, Jul 12, 2022 at 5:56 AM TAMURA, Kent  wrote:
>>>
 IMO, it's a bug fix and we don't need a dedicated I2S.

 On Tue, Jul 12, 2022 at 11:37 AM Domenic Denicola 
 wrote:

> Hey all,
>
> Today I was browsing
> https://wpt.fyi/results/streams?label=experimental&label=master&aligned
> and noticed that we were failing tests because of an analogous 
> non-exposure
> of TransformStreamDefaultController. I have a CL to fix this at
> https://chromium-review.googlesource.com/c/chromium/src/+/3757032 and
> was thinking it should be OK to just ping this thread with an FYI instead
> of doing a full Intent to Ship, because the change is basically the same
> (and in particular is extremely small/just updating to follow the
> spec/already implemented in other browsers). IMO this does not need a
> ChromeStatus entry or release blog post spot either.
>
> Does that sound OK? If so hopefully an API owner can stop by my CL and
> approve the webexposed/ changes. Otherwise we can start a new Intent to
> Ship thread if necessary.
>
> -Domenic
>
> On Tuesday, December 15, 2020 at 9:32:26 AM UTC Daniel Bratell wrote:
>
>> LGTM3
>>
>> /Daniel
>> On 2020-12-15 08:33, TAMURA, Kent wrote:
>>
>> LGTM2
>>
>>
>> On Tue, Dec 15, 2020 at 3:51 PM Yoav Weiss  wrote:
>>
>>> LGTM1
>>>
>>>
>>>
>>> On Fri, Dec 11, 2020 at 3:59 AM Nidhi Jaju 
>>> wrote:
>>>
 Hi Yoav,

>

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

['Daniel Vogelheim' via blink-dev]

Hello Yaseen,

On Wed, Jul 13, 2022 at 2:47 PM Yaseen Khan  wrote:

> Hi Team,
>
> Earliar chromium browser was displaying an error message as
> *document.domain* is going to deperecated in *M106*. Now I can not see
> this message and in some blogs postpone to *M109*. Could you confirm on
> this - when does this actually would enabled and in which version. It would
> be great if you could share dates for better planning to mitigate this very
> high risk in our platform.
>

As written earlier in this thread, the deprecation of document.domain, aka
defaulting origin-agent-cluster: to ?1, is scheduled for M109. This is
slightly postponed from the original plan at M106.
https://chromiumdash.appspot.com/schedule provides a schedule that maps
versions to planned release dates.

The warning/"issue" in the DevTools issues panel should be active. I'm
surprised the message would have disappeared. It should occur whenever
document.domain is set, as well as when an access based on a modified
document.domain is made. If you have any reproducible case that shows the
warning isn't shown even though it should be, I'll gladly investigate.

This is scheduled for M109, but note that API owners will have the final
call of whether and when to launch this.

-- 
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/CALG6KPP_1A4fYbvKQ-1%3DBQJBm0bX6xojAWNWnGV7D7fgrssdng%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Expose ReadableStreamDefaultController interface

[Alex Russell]

Hey Domenic,

Discussed at today's API OWNERS and we decided that:

   - It makes sense for this to be an intent
   - We're happy to see this skipped for TAG review as it is covered by 
   previous reviews
   - You should expect the intent to be fast-tracked once filed, and please 
   just link to this discussion as you file it

Thanks in advance, and sorry for the overhead.

Best,

Alex

On Tuesday, July 12, 2022 at 7:20:44 AM UTC+1 Domenic Denicola wrote:

> While I'm happy to do it, I think I may not have explained the situation 
> well enough, so let me ask a clarifying question...
>
> On Tue, Jul 12, 2022 at 3:00 PM Yoav Weiss  wrote:
>
>> Hey Domenic!
>>
>> While I agree it's a very similar case, it's not identical. 
>>
> I agree that a TAG review is not needed here, nor getting positions from 
>> other vendors, but there's still some risk in exposing the interface where 
>> it wasn't exposed before. (e.g. sites using the lack of exposure for some 
>> weird feature detection)
>>
>> And while I don't think the risk here is high, it's non-zero. E.g. 
>> quickly scanning 
>> 
>>  
>> through the HTTPArchive [1], I see ~15K response bodies that contain the 
>> string "ReadableStreamDefaultController".
>>
>> So, I think it'd be good to send out a new intent and discuss the risks 
>> and whether we need to do something to counter them (e.g. sampled analysis 
>> of HTTPArchive data, ClusterTelemetry run with tighter counters, or maybe 
>> nothing at all).
>>
>> I know it'd create some extra overhead, but would enable us to keep track 
>> of this specific change and its current risks.
>>
>
> What risk would you be imagining? It seems like a high burden to ask 
> people to do HTTPArchive analysis just to fix an exposure bug like this, 
> especially one where all other browsers already expose the global. Like, we 
> don't ask people to do HTTP archive analysis when exposing entire new 
> features which come with multiple new globals, where Chrome is shipping 
> first, so I don't see why this case would need such analysis. Indeed, many 
> Intent to Ships have sailed through the API Owners with "No compat 
> concerns; this is a new feature".
>
> To be clear, I'm willing (if not excited) to spend 2x the time I spent on 
> the CL doing all the ChromeStatus rigamarole and sending an email, if the 
> result is going to be a quick 3 LGTMs because it's trivial and we're just 
> checking some process boxes. I'm not really willing to spend more time than 
> that on this bugfix, though...
>  
>
>>
>> Cheers,
>> Yoav
>>
>> [1]
>> SELECT page, url
>> FROM `httparchive.response_bodies.2022_07_01_desktop`
>> #FROM `httparchive.sample_data.response_bodies_desktop_10k`
>> WHERE body like "%TransformStreamDefaultController%"
>>
>>
>> On Tue, Jul 12, 2022 at 5:56 AM TAMURA, Kent  wrote:
>>
>>> IMO, it's a bug fix and we don't need a dedicated I2S.
>>>
>>> On Tue, Jul 12, 2022 at 11:37 AM Domenic Denicola  
>>> wrote:
>>>
 Hey all,

 Today I was browsing 
 https://wpt.fyi/results/streams?label=experimental&label=master&aligned 
 and noticed that we were failing tests because of an analogous 
 non-exposure 
 of TransformStreamDefaultController. I have a CL to fix this at 
 https://chromium-review.googlesource.com/c/chromium/src/+/3757032 and 
 was thinking it should be OK to just ping this thread with an FYI instead 
 of doing a full Intent to Ship, because the change is basically the same 
 (and in particular is extremely small/just updating to follow the 
 spec/already implemented in other browsers). IMO this does not need a 
 ChromeStatus entry or release blog post spot either.

 Does that sound OK? If so hopefully an API owner can stop by my CL and 
 approve the webexposed/ changes. Otherwise we can start a new Intent to 
 Ship thread if necessary.

 -Domenic

 On Tuesday, December 15, 2020 at 9:32:26 AM UTC Daniel Bratell wrote:

> LGTM3
>
> /Daniel
> On 2020-12-15 08:33, TAMURA, Kent wrote:
>
> LGTM2 
>
>
> On Tue, Dec 15, 2020 at 3:51 PM Yoav Weiss  wrote:
>
>> LGTM1 
>>
>>
>>
>> On Fri, Dec 11, 2020 at 3:59 AM Nidhi Jaju  
>> wrote:
>>
>>> Hi Yoav, 
>>>
>>> The feature is essentially just exposing the 
>>> ReadableStreamDefaultController on the global object. This means that 
>>> evaluating 'ReadableStreamDefaultController' in window goes from false 
>>> to 
>>> true. Exposing it does not expose any new functionality, so developers 
>>> are 
>>> not really affected in any way.
>>>
>>> Currently, developers need to write:
>>> new ReadableStream({start(controller) { 
>>> self.ReadableStreamDefaultController = controller.constructor; }});
>>> to call the ReadableStreamDefaultController constructor. 
>>>
>>> Ho

Re: [blink-dev] Intent to Ship: fetch() upload streaming

[Mike Taylor]

LGTM3

On 7/13/22 7:38 AM, Mike West wrote:
LGTM2, also assuming you handle Mozilla's concerns reasonably. I'm 
happy to see y'all have thought through the CORS implications, and 
requiring `cors` or `same-origin` requests alleviates my minor 
concerns about leaking a server's support for HTTP/1 vs HTTP/2+.


-mike


On Wed, Jul 13, 2022 at 1:16 PM Yoav Weiss  wrote:

LGTM1

This seems like a useful addition, web developer signals look
great, and it's great to have Mozilla on board with this. Please
make sure to answer their questions on the position issue.

On Wed, Jul 13, 2022 at 12:27 PM Yutaka Hirano
 wrote:



On Wed, Jul 13, 2022 at 7:23 PM Yoav Weiss
 wrote:



On Monday, July 11, 2022 at 12:50:11 PM UTC+2 Yutaka
Hirano wrote:

On Mon, Jul 11, 2022 at 7:41 PM Yutaka Hirano
 wrote:



On Mon, Jul 11, 2022 at 5:41 PM Yoav Weiss
 wrote:



On Mon, Jul 11, 2022 at 10:17 AM Yutaka Hirano
 wrote:


Contact emails

yhir...@chromium.org


Explainer

https://bit.ly/2SVvKbR


The explainer seems focused on the H1 Origin Trial use
case, which IIUC we decided against.
Is there a more up-to-date explainer on what y'all are
actually planning to ship?


Oops, sorry again, I thought I updated the URL but apparently
I failed to do so...
Here it is.

https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload.md


Thanks! :)



Specification

https://fetch.spec.whatwg.org/#concept-body-stream


Design docs


http://bit.ly/3asqra2


Summary

Fetch upload streaming lets web developers
make a fetch with a ReadableStream body.
Fetch provides a generic definition of
Request and Response objects (and other
things involved with network requests).



Blink component

Blink>Network>FetchAPI




TAG review

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


Actual review never really happened :/ Seems
worthwhile to at least communicate that to the
TAG.


Oh sorry I somehow chose a wrong URL.
https://github.com/w3ctag/design-reviews/issues/754
is the correct one.



TAG review status

Issues open


Risks



Interoperability and Compatibility

TBD



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/207)



This seems like a position request for a
different feature. I think you meant

https://github.com/mozilla/standards-positions/issues/663


Seems like Mozilla are positive on this! (% some questions)


You're right, thank you.

No signals on the standards-position
ticket. Annevk has been active on the
standards discussions. Positive at TPAC
2019 [1].

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/24)
No signals on the standards-position
ticket. Positive at TPAC 2019 [1]. [1]

https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.85gziabhajhg

/Web developers/:

Positivehttps://github.com/whatwg/fetch/issues/1438#issuecomment-1150755587

https://github.com/whatwg/fetch/issues/1438#issuecomment-1167984830



/Other signals/:


Security

- Only 'cors' and 'same-origin' requests
allow streaming upload.

Re: [blink-dev] Intent to Ship: fetch() upload streaming

[Mike West]

LGTM2, also assuming you handle Mozilla's concerns reasonably. I'm happy to
see y'all have thought through the CORS implications, and requiring `cors`
or `same-origin` requests alleviates my minor concerns about leaking a
server's support for HTTP/1 vs HTTP/2+.

-mike


On Wed, Jul 13, 2022 at 1:16 PM Yoav Weiss  wrote:

> LGTM1
>
> This seems like a useful addition, web developer signals look great, and
> it's great to have Mozilla on board with this. Please make sure to answer
> their questions on the position issue.
>
> On Wed, Jul 13, 2022 at 12:27 PM Yutaka Hirano 
> wrote:
>
>>
>>
>> On Wed, Jul 13, 2022 at 7:23 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Monday, July 11, 2022 at 12:50:11 PM UTC+2 Yutaka Hirano wrote:
>>>
 On Mon, Jul 11, 2022 at 7:41 PM Yutaka Hirano 
 wrote:

>
>
> On Mon, Jul 11, 2022 at 5:41 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Mon, Jul 11, 2022 at 10:17 AM Yutaka Hirano 
>> wrote:
>>
>>> Contact emailsyhir...@chromium.org
>>>
>>> Explainerhttps://bit.ly/2SVvKbR
>>>
>>
>>> The explainer seems focused on the H1 Origin Trial use case, which IIUC
>>> we decided against.
>>> Is there a more up-to-date explainer on what y'all are actually planning
>>> to ship?
>>>
>>
>> Oops, sorry again, I thought I updated the URL but apparently I failed to
>> do so...
>> Here it is.
>> https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload.md
>>
>
> Thanks! :)
>
>>
>>
>>>
>>>

>>>
>>> Specificationhttps://fetch.spec.whatwg.org/#concept-body-stream
>>>
>>> Design docs
>>> http://bit.ly/3asqra2
>>>
>>> Summary
>>>
>>> Fetch upload streaming lets web developers make a fetch with a
>>> ReadableStream body. Fetch provides a generic definition of Request and
>>> Response objects (and other things involved with network requests).
>>>
>>>
>>> Blink componentBlink>Network>FetchAPI
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/434
>>>
>>
>> Actual review never really happened :/ Seems worthwhile to at least
>> communicate that to the TAG.
>>
>
> Oh sorry I somehow chose a wrong URL.
> https://github.com/w3ctag/design-reviews/issues/754 is the correct
> one.
>
>
>>
>>
>>>
>>>
>>> TAG review statusIssues open
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> TBD
>>>
>>>
>>> *Gecko*: No signal (
>>> https://github.com/mozilla/standards-positions/issues/207)
>>>
>>
>> This seems like a position request for a different feature. I think
>> you meant https://github.com/mozilla/standards-positions/issues/663
>>
>
>>> Seems like Mozilla are positive on this! (% some questions)
>>>
>>>

 You're right, thank you.


>
>>
>>> No signals on the standards-position ticket. Annevk has been active
>>> on the standards discussions. Positive at TPAC 2019 [1].
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/24) No signals
>>> on the standards-position ticket. Positive at TPAC 2019 [1]. [1]
>>> https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.85gziabhajhg
>>>
>>> *Web developers*: Positive
>>> https://github.com/whatwg/fetch/issues/1438#issuecomment-1150755587
>>> https://github.com/whatwg/fetch/issues/1438#issuecomment-1167984830
>>>
>>> *Other signals*:
>>>
>>> Security
>>>
>>> - Only 'cors' and 'same-origin' requests allow streaming upload. You
>>> can't use streaming upload with 'navigate' and 'no-cors' requests. - 
>>> This
>>> feature cannot be used with HTTP/1.x. If the server doesn't support 
>>> HTTP/2
>>> or HTTP/3, the request fails. This is for some compatibility concerns. 
>>> See
>>> whatwg/fetch#966 for the past discussions.
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based 
>>> applications?
>>>
>>> No
>>>
>>>
>>> Debuggability
>>>
>>> Same as usual fetch()
>>>
>>>
>>> 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
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=688906
>>>
>>> Non-OSS dependencies
>>>
>>

Re: [blink-dev] Intent to Prototype: Render blocking status in Resource Timing

[Yoav Weiss]

Thanks for working on this!! :)

On Wed, Jun 29, 2022 at 4:53 PM Abin Paul  wrote:

> Contact emails
>
>
> *abin.pa...@gmail.com *Explainer
>
>
> *https://github.com/abinpaul1/resource-timing/blob/render-blocking-status-explainer/Explainer/Render_Blocking_Status.md
> *
> Specification
>
>
> *Resource Timing PR : https://github.com/w3c/resource-timing/pull/327
> Fetch PR :
> https://github.com/whatwg/fetch/pull/1449
> *Summary
>
>
>
> *Adds a field to PerfomanceResourceTiming to indicate the render blocking
> status of a resource. Currently from a developer perspective, the only way
> to determine which resources were actually render blocking is to rely on
> complex heuristics. The new field would instead provide a direct signal
> regarding the same.*Blink component
>
>
> *Blink>PerformanceAPIs>ResourceTiming
> *
> Motivation
>
>
>
>
> *Currently in order to determine which resources were actually render
> blocking and which ones were not, developers have to rely on heuristics.By
> providing a web exposed field, developers can get a direct signal from the
> browser regarding the render blocking nature of each resource.*Initial
> public proposal
>
>
> *https://github.com/w3c/resource-timing/pull/327
> *TAG review
>
> TAG review status
>
>
> *Pending*Risks
>
> Interoperability and Compatibility
>
>
>
>
>
>
> *Gecko: No signalWebKit: No signalWeb developers: Reception towards a
> similar feature introduced in Chromium was very positive. The article and
> tweet linked below is a good
> indicator.https://blog.webpagetest.org/posts/new-render-blocking-indicator-in-chrome-and-webpagetest/
> 
>  https://twitter.com/tkadlec/status/1417543014705246214
> Other signals:*WebView
> application risks
>
>
>
> *Does this intent deprecate or change behaviour 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
> 
> ?
>
>
> *Yes*Flag name
>
>
> *RenderBlockingStatus*Requires code in //chrome?
>
>
> *False*Tracking bug
>
>
> *https://bugs.chromium.org/p/chromium/issues/detail?id=1337256
> *Estimated
> milestones
>
>
>
> *No milestones specified*Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5166965277589504
>
> 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/CAM2ZH3dimwFkdjtC_1O5imD9HNJ6QvNPPuPJ5Me9ushAT9CKiA%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/CAL5BFfWEKeoB5SScDY1gPU49GZBgtBNFHq-wwisFZQMfVT%3D3HA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: fetch() upload streaming

[Yoav Weiss]

LGTM1

This seems like a useful addition, web developer signals look great, and
it's great to have Mozilla on board with this. Please make sure to answer
their questions on the position issue.

On Wed, Jul 13, 2022 at 12:27 PM Yutaka Hirano  wrote:

>
>
> On Wed, Jul 13, 2022 at 7:23 PM Yoav Weiss  wrote:
>
>>
>>
>> On Monday, July 11, 2022 at 12:50:11 PM UTC+2 Yutaka Hirano wrote:
>>
>>> On Mon, Jul 11, 2022 at 7:41 PM Yutaka Hirano 
>>> wrote:
>>>


 On Mon, Jul 11, 2022 at 5:41 PM Yoav Weiss 
 wrote:

>
>
> On Mon, Jul 11, 2022 at 10:17 AM Yutaka Hirano 
> wrote:
>
>> Contact emailsyhir...@chromium.org
>>
>> Explainerhttps://bit.ly/2SVvKbR
>>
>
>> The explainer seems focused on the H1 Origin Trial use case, which IIUC
>> we decided against.
>> Is there a more up-to-date explainer on what y'all are actually planning
>> to ship?
>>
>
> Oops, sorry again, I thought I updated the URL but apparently I failed to
> do so...
> Here it is.
> https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload.md
>

Thanks! :)

>
>
>>
>>
>>>
>>
>> Specificationhttps://fetch.spec.whatwg.org/#concept-body-stream
>>
>> Design docs
>> http://bit.ly/3asqra2
>>
>> Summary
>>
>> Fetch upload streaming lets web developers make a fetch with a
>> ReadableStream body. Fetch provides a generic definition of Request and
>> Response objects (and other things involved with network requests).
>>
>>
>> Blink componentBlink>Network>FetchAPI
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/434
>>
>
> Actual review never really happened :/ Seems worthwhile to at least
> communicate that to the TAG.
>

 Oh sorry I somehow chose a wrong URL.
 https://github.com/w3ctag/design-reviews/issues/754 is the correct one.


>
>
>>
>>
>> TAG review statusIssues open
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> TBD
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/207)
>>
>
> This seems like a position request for a different feature. I think
> you meant https://github.com/mozilla/standards-positions/issues/663
>

>> Seems like Mozilla are positive on this! (% some questions)
>>
>>
>>>
>>> You're right, thank you.
>>>
>>>

>
>> No signals on the standards-position ticket. Annevk has been active
>> on the standards discussions. Positive at TPAC 2019 [1].
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/24) No signals
>> on the standards-position ticket. Positive at TPAC 2019 [1]. [1]
>> https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.85gziabhajhg
>>
>> *Web developers*: Positive
>> https://github.com/whatwg/fetch/issues/1438#issuecomment-1150755587
>> https://github.com/whatwg/fetch/issues/1438#issuecomment-1167984830
>>
>> *Other signals*:
>>
>> Security
>>
>> - Only 'cors' and 'same-origin' requests allow streaming upload. You
>> can't use streaming upload with 'navigate' and 'no-cors' requests. - This
>> feature cannot be used with HTTP/1.x. If the server doesn't support 
>> HTTP/2
>> or HTTP/3, the request fails. This is for some compatibility concerns. 
>> See
>> whatwg/fetch#966 for the past discussions.
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such
>> that it has potentially high risk for Android WebView-based applications?
>>
>> No
>>
>>
>> Debuggability
>>
>> Same as usual fetch()
>>
>>
>> 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
>>
>> Requires code in //chrome?False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=688906
>>
>> Non-OSS dependencies
>>
>> Does the feature depend on any code or APIs outside the Chromium open
>> source repository and its open-source dependencies to function?
>> No
>>
>> Estimated milestones
>> OriginTrial desktop last 94
>> OriginTrial desktop first 85
>>
>
> Any learnings from the Origin Trials?
>

>>> None. We had the origin trial to decide whether we want to allow the
>>> feature on HTTP/1.1. Here
>>>  is
>>> our intention a

Re: [blink-dev] Intent to Ship: fetch() upload streaming

[Yutaka Hirano]

On Wed, Jul 13, 2022 at 7:23 PM Yoav Weiss  wrote:

>
>
> On Monday, July 11, 2022 at 12:50:11 PM UTC+2 Yutaka Hirano wrote:
>
>> On Mon, Jul 11, 2022 at 7:41 PM Yutaka Hirano 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jul 11, 2022 at 5:41 PM Yoav Weiss 
>>> wrote:
>>>


 On Mon, Jul 11, 2022 at 10:17 AM Yutaka Hirano 
 wrote:

> Contact emailsyhir...@chromium.org
>
> Explainerhttps://bit.ly/2SVvKbR
>

> The explainer seems focused on the H1 Origin Trial use case, which IIUC we
> decided against.
> Is there a more up-to-date explainer on what y'all are actually planning
> to ship?
>

Oops, sorry again, I thought I updated the URL but apparently I failed to
do so...
Here it is.
https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload.md


>
>
>>
>
> Specificationhttps://fetch.spec.whatwg.org/#concept-body-stream
>
> Design docs
> http://bit.ly/3asqra2
>
> Summary
>
> Fetch upload streaming lets web developers make a fetch with a
> ReadableStream body. Fetch provides a generic definition of Request and
> Response objects (and other things involved with network requests).
>
>
> Blink componentBlink>Network>FetchAPI
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/434
>

 Actual review never really happened :/ Seems worthwhile to at least
 communicate that to the TAG.

>>>
>>> Oh sorry I somehow chose a wrong URL.
>>> https://github.com/w3ctag/design-reviews/issues/754 is the correct one.
>>>
>>>


>
>
> TAG review statusIssues open
>
> Risks
>
>
> Interoperability and Compatibility
>
> TBD
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/207)
>

 This seems like a position request for a different feature. I think you
 meant https://github.com/mozilla/standards-positions/issues/663

>>>
> Seems like Mozilla are positive on this! (% some questions)
>
>
>>
>> You're right, thank you.
>>
>>
>>>

> No signals on the standards-position ticket. Annevk has been active on
> the standards discussions. Positive at TPAC 2019 [1].
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/24) No signals
> on the standards-position ticket. Positive at TPAC 2019 [1]. [1]
> https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.85gziabhajhg
>
> *Web developers*: Positive
> https://github.com/whatwg/fetch/issues/1438#issuecomment-1150755587
> https://github.com/whatwg/fetch/issues/1438#issuecomment-1167984830
>
> *Other signals*:
>
> Security
>
> - Only 'cors' and 'same-origin' requests allow streaming upload. You
> can't use streaming upload with 'navigate' and 'no-cors' requests. - This
> feature cannot be used with HTTP/1.x. If the server doesn't support HTTP/2
> or HTTP/3, the request fails. This is for some compatibility concerns. See
> whatwg/fetch#966 for the past discussions.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based applications?
>
> No
>
>
> Debuggability
>
> Same as usual fetch()
>
>
> 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
>
> Requires code in //chrome?False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=688906
>
> Non-OSS dependencies
>
> Does the feature depend on any code or APIs outside the Chromium open
> source repository and its open-source dependencies to function?
> No
>
> Estimated milestones
> OriginTrial desktop last 94
> OriginTrial desktop first 85
>

 Any learnings from the Origin Trials?

>>>
>> None. We had the origin trial to decide whether we want to allow the
>> feature on HTTP/1.1. Here
>>  is
>> our intention at that time.
>> Because of some technical problems we failed to collect the data and the
>> partner (gRPC/web) lost their interest in the feature.
>>
>> Hence we decided to give up collecting the data. We asked web developers
>> whether they want to use the feature even if we disable the feature on
>> HTTP/1.1, and got some positive answers, as shown in
>> https://github.com/whatwg/fetch/issues/1438#issuecomment-1150755587 and
>> https://github.com/wh

Re: [blink-dev] Intent to Ship: fetch() upload streaming

[Yoav Weiss]

On Monday, July 11, 2022 at 12:50:11 PM UTC+2 Yutaka Hirano wrote:

> On Mon, Jul 11, 2022 at 7:41 PM Yutaka Hirano  
> wrote:
>
>>
>>
>> On Mon, Jul 11, 2022 at 5:41 PM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Mon, Jul 11, 2022 at 10:17 AM Yutaka Hirano  
>>> wrote:
>>>
 Contact emailsyhir...@chromium.org

 Explainerhttps://bit.ly/2SVvKbR

>>>
The explainer seems focused on the H1 Origin Trial use case, which IIUC we 
decided against.
Is there a more up-to-date explainer on what y'all are actually planning to 
ship?
  

>

 Specificationhttps://fetch.spec.whatwg.org/#concept-body-stream

 Design docs
 http://bit.ly/3asqra2

 Summary

 Fetch upload streaming lets web developers make a fetch with a 
 ReadableStream body. Fetch provides a generic definition of Request and 
 Response objects (and other things involved with network requests). 


 Blink componentBlink>Network>FetchAPI 
 

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

>>>
>>> Actual review never really happened :/ Seems worthwhile to at least 
>>> communicate that to the TAG.
>>>
>>
>> Oh sorry I somehow chose a wrong URL. 
>> https://github.com/w3ctag/design-reviews/issues/754 is the correct one.
>>  
>>
>>>  
>>>


 TAG review statusIssues open

 Risks


 Interoperability and Compatibility

 TBD


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

>>>
>>> This seems like a position request for a different feature. I think you 
>>> meant https://github.com/mozilla/standards-positions/issues/663
>>>
>>
Seems like Mozilla are positive on this! (% some questions)
 

>
> You're right, thank you.
>  
>
>>  
>>>
 No signals on the standards-position ticket. Annevk has been active on 
 the standards discussions. Positive at TPAC 2019 [1].

 *WebKit*: No signal (
 https://github.com/WebKit/standards-positions/issues/24) No signals on 
 the standards-position ticket. Positive at TPAC 2019 [1]. [1] 
 https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.85gziabhajhg

 *Web developers*: Positive 
 https://github.com/whatwg/fetch/issues/1438#issuecomment-1150755587 
 https://github.com/whatwg/fetch/issues/1438#issuecomment-1167984830

 *Other signals*:

 Security

 - Only 'cors' and 'same-origin' requests allow streaming upload. You 
 can't use streaming upload with 'navigate' and 'no-cors' requests. - This 
 feature cannot be used with HTTP/1.x. If the server doesn't support HTTP/2 
 or HTTP/3, the request fails. This is for some compatibility concerns. See 
 whatwg/fetch#966 for the past discussions. 


 WebView application risks

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

 No


 Debuggability

 Same as usual fetch()


 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

 Requires code in //chrome?False

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

 Non-OSS dependencies

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

 Estimated milestones
 OriginTrial desktop last 94
 OriginTrial desktop first 85

>>>
>>> Any learnings from the Origin Trials?
>>>
>>
> None. We had the origin trial to decide whether we want to allow the 
> feature on HTTP/1.1. Here 
>  is 
> our intention at that time.
> Because of some technical problems we failed to collect the data and the 
> partner (gRPC/web) lost their interest in the feature.
>
> Hence we decided to give up collecting the data. We asked web developers 
> whether they want to use the feature even if we disable the feature on 
> HTTP/1.1, and got some positive answers, as shown in  
> https://github.com/whatwg/fetch/issues/1438#issuecomment-1150755587 and 
> https://github.com/whatwg/fetch/issues/1438#issuecomment-1167984830.
>  
>
>>  
>>>
 OriginTrial Android last 94
 OriginTrial Android first 85

 Anticipated spec changes

 Open questions about a feature may be a source of future web compat or 
 interop issues. Please list open issues (e.g. links to known github issues 
 in the project for the f

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

[Yoav Weiss]

On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:

> On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss  
> wrote:
>
>>
>>
>> On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar  
>> wrote:
>>
>>> Contact emailskhushalsa...@chromium.org, vmp...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
>>> https://github.com/w3c/csswg-drafts/issues/7058
>>>
>>> Specificationhttps://drafts.csswg.org/css-overflow/#overflow-properties
>>>
>>> Summary
>>>
>>> This change allows developers to use the existing `overflow` property 
>>> with replaced elements that paint outside the content-box. Paired with 
>>> `object-view-box` this can be used to create an image with a custom glow or 
>>> shadow applied, with proper ink-overflow behavior like a CSS shadow would 
>>> have.
>>>
>>> Blink componentBlink>CSS 
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/750
>>>
>>> TAG review statusPending
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> This feature changes the behaviour of the existing overflow property on 
>>> replaced elements (img, video, canvas). Currently `overflow:visible` in a 
>>> developer stylesheet on such elements is ignored during paint and the 
>>> content is clipped to the element's content-box. With this feature, 
>>> `overflow:visible` will result in content outside the element's content-box 
>>> to paint as ink overflow. We've collected use counter data to measure the 
>>> number of sites which could be affected by this. The use counter data 
>>> collected over 1 week of a stable release (M102) is as follows. We 
>>> collected 2 different counters explained below. * The first measures any 
>>> instance where overflow is explicitly set from developer styles to visible. 
>>> The percentage of page loads with this is 2.16%. * The second measures the 
>>> above instances but only includes the cases with object-fit set to cover or 
>>> none or object-position set to any value other than the default (50% 50%). 
>>> The rationale behind this counter is to exclude cases which can not cause 
>>> overflow (such as object-fit:contain), even if overflow is set to visible. 
>>> The percentage of page loads with this is 0.017%.
>>>
>>
>> That's not nothing. Any idea what breakage may look like?
>> Can we maybe collect histograms on *how much* overflow would occur in 
>> those cases? (maybe with ClusterTelemetry initially, to get a rough idea in 
>> the lab)
>>
>
> I ran an analysis on CT using top 100k sites for desktop and top 10k sites 
> on mobile. The raw numbers are here: desktop 
> 
>  
> and mobile 
> ,
>  
> and the rough patch 
>  to 
> collect this data. The highlights from the analysis are below:
>
>- The number of sites which override the default CSS to allow overflow 
>*and* also had overflow during painting was 13 out of 10k on mobile and 39 
>out of 63k on desktop (only 63k sites yielded results out of 100k).
>
>- I measured the percentage of area painted outside the content box 
>out of the total painted area. The highest was 88% on desktop and 70% on 
>mobile.
>
>
I'm not sure what that means in practice. Can you elaborate? Have you 
looked at extreme cases to see the impact there?
 

> I manually went through ~10 sites on both desktop and mobile. For the ones 
> which repro-ed, the breakage was losing rounded corners because 
> border-radius doesn't clip the content if 'overflow' is 'visible'. In fact 
> a few sites had the same code, likely coming from customerly 
>  based on class names and the UX. There was 
> one case where an image (used in the background) had object-fit:cover and 
> overflowed outside the content box now. I've attached screenshots for both 
> of these.
>
> Overall I didn't see any case where the overflow occluded any other 
> content on the page.
>

That's reassuring! :)
 

>  
>
>>  
>>
>>>
>>> *Gecko*: No signal (
>>> https://github.com/mozilla/standards-positions/issues/659)
>>>
>>> *WebKit*: No signal (
>>> https://lists.webkit.org/pipermail/webkit-dev/2022-June/032317.html)
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such 
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> Debuggability
>>>
>>> This is a CSS property which can be debugged in the devtools style panel 
>>> similar to other CSS properties.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android,