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

['Yutaka Hirano' via blink-dev]

bcc: blink-dev
cc: web-transport-dev

Hi, web-transport-...@chromium.org is a better place for this kind of
discussion.

On Thu, Jan 20, 2022 at 3:47 PM kk as  wrote:

> 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 ?
>
> Reg: protocol, we use WebTransport over HTTP/3
.
We expect Datagrams is better than Streams in terms of latency, but actual
number depends on the network environment, server and client implementation.
Our client implementation is not (at all) perfect, so we'll appreciate your
performance feedback!



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

[blink-dev] Intent to Ship: WebTransport serverCertificateHashes option

['Victor Vasiliev' via blink-dev]

Contact emails

yhir...@chromium.org, vasi...@chromium.org

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

Spec

https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes

WebTransport has been already covered by a series of TAG reviews (389
, 669
).

Summary

In WebTransport, the serverCertificateHashes option allows the website to
connect to a WebTransport server by authenticating the certificate against
the expected certificate hash instead of using the Web PKI.  This feature
allows Web developers to connect to WebTransport servers that would
normally find obtaining a publicly trusted certificate challenging, such as
hosts that are not publically routable, or virtual machines that are
ephemeral in nature.

During the WebTransport Intent to Ship email thread
,
concerns were raised regarding the security considerations of this portion
of the spec being incomplete.  We believe that we have addressed those
concerns (notably, in this PR ).
In terms of the actual code behavior, the only major difference since the
previous thread is that we no longer allow RSA keys for the certificates.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/I6MS2kOKcx0/m/NAdg7Sc-CwAJ

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

Yes.

Debuggability

The certificate-related errors for WebTransport sessions are logged into
the developer console.

Measurement

The use of this feature is tracked by the
WebTransportServerCertificateHashes use counter.

Risks

Interoperability and Compatibility

There is some discussion about adding a mechanism to prevent websites from
using this feature via an HTTP header (either CSP or a new header).  Some
of the proposals could potentially break existing usage under certain
conditions (e.g. if a webpage both uses serverCertificateHashes and has a
connect-src directive, and we decide to extend connect-src); I expect for
those cases to be sufficiently niche to ultimately not be a problem, and
the question itself is of fairly low priority as there does not seem to be
a strong security reason for a website to restrict serverCertificateHashes.

Gecko: worth prototyping


WebKit: no signal


Web / Framework developers: positive (we have received indication in the
past that serverCertificateHashes is a blocker for migrating from WebRTC at
least one of them)

Ergonomics

The API is roughly modeled after a similar WebRTC API (RtcDtlsFingerprint),
with a noted improvement that the certificate hash no longer requires to be
serialized into a specific format.

Activation

Using this feature would require web developers to design their application
in a way that supports generating and distributing ephemeral certificates
on demand.

Security

Security considerations for this feature are discussed at length in PR #375

.

Is this feature fully tested by web-platform-tests
?
Link to test suite results from wpt.fyi.

WebTransport itself is tested by web-platform-tests; this specific feature
requires infra support that is currently not available (issue
).

Entry on the feature dashboard 

https://chromestatus.com/feature/5690646332440576

-- 
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/CAAZdMadAk5z-V7m8L_oVNyPGmE8An%2BcVEKsfSeOTDe9hEbKd-Q%40mail.gmail.com.

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

[Mike Taylor]

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.

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

[David Benjamin]

Contact emailsdavid...@chromium.org

Specificationhttps://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 componentInternals>Network>SSL


TAG review statusNot 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.

[blink-dev] Re: Intent to Ship: Markup based Client Hints delegation for third-party content

[chrishtr via Chromestatus]

Hi, the API owners discussed this intent today. We decided that we'd like to 
hear from the TAG about this feature (*), and so are not deciding on it this 
week. I hope a delay to M100 won't be a huge burden. (*) The TAG review was 
filed only a few weeks ago, so I think they need some more time.

-- 
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/95973c05d5f25f36%40google.com.

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

[Philip Jägenstedt]

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
>>
>> *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 web authors work with a grid spanning some area within
>> another grid, the children of the innermost grid are unaware of the
>> outermost grid structure, which could potentially be a disadvantage if
>> authors want those items to be aligned to other descendants of the
>> outermost grid. A "subgrid" is a nested grid container whose row and column
>> definitions are deferred to its parent; with such concept in mind, the
>> problem above is mitigated by inheriting the grid properties and alignment
>> from the spanned grid area in its parent grid.
>>
>> *Initial public proposal*
>>
>>
>> *Search tags*
>>
>> subgrid , css-grid-2
>> , css
>> 
>>
>> *TAG review*
>>
>>
>> *TAG review status*
>>
>> Not applicable
>>
>> *Risks*
>>
>> *Interoperability and Compatibility*
>>
>> This is a well-defined specification from the W3C, so we would be
>> addressing some interoperability gaps instead of causing them.
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: Positive
>>
>> *Web developers*: Strongly positive
>>
>> *Other signals*:
>>
>> *Debuggability*
>>
>>
>> *Is this feature fully tested by **web-platform-tests*
>> 
>> *?*
>>
>> Yes
>>
>> *Flag name*
>>
>>
>>
>> *Requires code in //chrome?*
>>
>> False
>>
>> *Tracking bug*
>>
>> https://crbug.com/618969
>>
>> *Estimated milestones*
>>
>> No milestones specified
>>
>> *Link to entry on the Chrome Platform Status*
>>
>> https://chromestatus.com/feature/5663795354533888
>>
>> 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/MN2PR00MB06691936F5BB8575F43A9704BC569%40MN2PR00MB0669.namprd00.prod.outlook.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/CADizRgahta5WoNwYezq1959cAVVAW39ky1cDg8yRsw8w_prKLw%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 Prototype: MediaRecorderErrorEvent API

[Imranur Rahman]

Great, thanks. I am waiting for the spec modification.

On Wednesday, January 19, 2022 at 10:37:55 PM UTC+6 Philip Jägenstedt wrote:

> Good catch, thanks Domenic!
>
> Dom put up https://github.com/w3c/mediacapture-record/pull/212 to change 
> the spec here.
>
> Imranur, once the spec change is made, I would suggest sending an Intent 
> to Ship. An Intent to Prototype is for when you want to implement something 
> behind a flag, but not ship it yet.
>
> Best regards,
> Philip
>
> On Wed, Jan 12, 2022 at 6:06 PM Domenic Denicola  
> wrote:
>
>> This seems like a problematic specification. They should just use 
>> ErrorEvent, instead of creating a new class that is basically identical. I 
>> have filed https://github.com/w3c/mediacapture-record/issues/211 and 
>> hope we can go that route instead.
>>
>> On Wed, Jan 12, 2022 at 11:59 AM Imranur Rahman  
>> wrote:
>>
>>> Contact emailsir.s...@gmail.com
>>>
>>> ExplainerNone
>>>
>>> Specification
>>> https://w3c.github.io/mediacapture-record/#errorevent-section
>>>
>>> Summary
>>>
>>> MediaRecorderErrorEvent is fired when Media Recording API faces an 
>>> error. This API will enable developers to debug more conveniently when an 
>>> exception occurs in Media Recording API. MediaRecorderErrorEvent will 
>>> provide further details about the error with a DOMException object. BUG: 
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1250432 SPEC: 
>>> https://w3c.github.io/mediacapture-record/#errorevent-section
>>>
>>>
>>> Blink componentBlink>MediaRecording 
>>> 
>>>
>>> Motivation
>>>
>>> The main motivation is that currently Chromium fires a plain event, 
>>> whereas if this feature is implemented the developers will have more 
>>> knowledge about the occurred error in Media Recording API and debug 
>>> conveniently.
>>>
>>>
>>> Initial public proposal
>>>
>>> TAG review
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> Gecko: No signal
>>>
>>> WebKit: No signal
>>>
>>> Web developers: No signals
>>>
>>> Other signals:
>>>
>>>
>>> Debuggability
>>>
>>>
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?No
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1250432
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5103987136135168
>>>
>>> This intent message was generated by Chrome Platform Status 
>>> .
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to blink-dev+...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEq642EJPBbCQUGJ%2BuQAFrEi1HXZZAA%3D81x6-ZjdPYZ%3DJcWWqA%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+...@chromium.org.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8OS3ffZcfONb-nEz0y3diWWaC3Xo%3Dh8W2ORK_hxQ6fEg%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/999c970d-0746-4274-99dc-de4f71ec199an%40chromium.org.

[blink-dev] Intent to Ship: mix-blend-mode: plus-lighter

[Vladimir Levin]

Contact emailsvmp...@chromium.org, khushalsa...@chromium.org,
jakearchib...@chromium.org

Explainerhttps://jakearchibald.com/2021/dom-cross-fade/

Specificationhttps://drafts.fxtf.org/compositing-2/#mix-blend-mode

Summary

This proposal adds a plus-lighter value to the mix-blend-mode property.
Plus-lighter adds the source and destination colors multiplied by their
respective alphas. This operation is useful when cross fading between two
elements that may contain common pixels. In that case, plus-lighter ensures
that the common pixels do not change in appearance as opacity changes from
0 to 1 on one element and from 1 to 0 on the other.


Blink componentBlink>CSS


Search tagsplus-lighter


TAG reviewN/A: this is a single value addition to an existing property, and
this value already exists in a canvas context, so the TAG review seemed not
necessary

TAG review statusNot applicable

Risks


Interoperability and Compatibility



Gecko: No signal

WebKit: Shipped/Shipping (
https://github.com/w3c/fxtf-drafts/issues/445#issuecomment-995022125)

Web developers: No signals

Other signals:

Ergonomics

This adds a new value to an existing CSS property. The ergonomics risk is
minimal.


Activation

This adds a new value to an existing CSS property. The activation risk is
minimal. This property is straight-forward to use.


Security

There are no security risks associated with this property.


Debuggability

This relies on existing debuggability of CSS mix-blend-mode.


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=1275782

Estimated milestones

M100

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MsbYsCV57vZ-eVQem4WUudVTGT%3Djzpib0NzezYEAMP-g%40mail.gmail.com



This intent message was generated by Chrome Platform Status
.

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

Re: [blink-dev] Intent to Prototype: MediaRecorderErrorEvent API

[Philip Jägenstedt]

Good catch, thanks Domenic!

Dom put up https://github.com/w3c/mediacapture-record/pull/212 to change
the spec here.

Imranur, once the spec change is made, I would suggest sending an Intent to
Ship. An Intent to Prototype is for when you want to implement something
behind a flag, but not ship it yet.

Best regards,
Philip

On Wed, Jan 12, 2022 at 6:06 PM Domenic Denicola 
wrote:

> This seems like a problematic specification. They should just use
> ErrorEvent, instead of creating a new class that is basically identical. I
> have filed https://github.com/w3c/mediacapture-record/issues/211 and hope
> we can go that route instead.
>
> On Wed, Jan 12, 2022 at 11:59 AM Imranur Rahman 
> wrote:
>
>> Contact emailsir.shi...@gmail.com
>>
>> ExplainerNone
>>
>> Specification
>> https://w3c.github.io/mediacapture-record/#errorevent-section
>>
>> Summary
>>
>> MediaRecorderErrorEvent is fired when Media Recording API faces an error.
>> This API will enable developers to debug more conveniently when an
>> exception occurs in Media Recording API. MediaRecorderErrorEvent will
>> provide further details about the error with a DOMException object. BUG:
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1250432 SPEC:
>> https://w3c.github.io/mediacapture-record/#errorevent-section
>>
>>
>> Blink componentBlink>MediaRecording
>> 
>>
>> Motivation
>>
>> The main motivation is that currently Chromium fires a plain event,
>> whereas if this feature is implemented the developers will have more
>> knowledge about the occurred error in Media Recording API and debug
>> conveniently.
>>
>>
>> Initial public proposal
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>>
>> Debuggability
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1250432
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5103987136135168
>>
>> 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/CAEq642EJPBbCQUGJ%2BuQAFrEi1HXZZAA%3D81x6-ZjdPYZ%3DJcWWqA%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/CAM0wra8OS3ffZcfONb-nEz0y3diWWaC3Xo%3Dh8W2ORK_hxQ6fEg%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/CAARdPYdkQYci8A%3DqqyGirhGZ17zckVKo7yaQApHFUbE7reC5Mw%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Remove Battery Status API on Insecure Origins

[bratell.d via Chromestatus]

LGTM4 (also testing new intent tracking UI)

-- 
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/8f551105d5f1d0b4%40google.com.

[blink-dev] Intent to Prototype: Transferable MediaStreamTracks

['Tony Herre' via blink-dev]

Contact emailshe...@google.com, h...@chromium.org

ExplainerNone

Specification
https://w3c.github.io/mediacapture-extensions/#transferable-mediastreamtrack

Summary

Expose MediaStreamTracks in Workers and allow them to be transferred
between contexts. Allowing this transfer makes it easier to access and
process media in contexts other that where it was created, eg in Workers or
other documents.


Blink componentBlink>MediaStream


Motivation

Having transferable MediaStreamTracks allows much more flexibility for
architecting web applications which have multiple windows which each wish
to contribute video or audio tracks to a single WebRTC conference, without
having to have independent competing network connections via
PeerConnection. This also allows transferring all media processing to a
separate context eg a worker, rather than mediating control signals through
the window.


Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility



Gecko: No signal
Positive in WebRTC Working Group discussions

WebKit: No signal
Positive in WebRTC Working Group discussions

Web developers: No signals

Other signals:



Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?False

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

Estimated milestones

No milestones specified


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

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/CAArnMxEAdAdKs-T5o_TWCnvXpWEXiXDvpoxz_zpwADn%2BpyBwEA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Continue Experimenting: Handwriting Recognition API

[Chris Harrelson]

LGTM

On Tue, Jan 18, 2022 at 8:33 PM 'Jiewei Qian' via blink-dev <
blink-dev@chromium.org> wrote:

> Friendly ping :)
>
>
> On Mon, Jan 10, 2022 at 11:35 AM Glen Robertson 
> wrote:
>
>> As discussed in an earlier thread (
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/OXnXteNYQQQ/m/RezhfPeYCAAJ)
>> we have only received OT feedback from 1 developer, but it has been
>> positive. There is also some feedback as issues on github (
>> https://github.com/WICG/handwriting-recognition/issues?q=is%3Aissue). It
>> has all either been addressed or does not require changes to the API.
>>
>> On Fri, 7 Jan 2022 at 07:41, Daniel Bratell  wrote:
>>
>>> One of the reasons that the process dictates a gap is to remove the
>>> pressure to ship an imperfect API. For us to consider a gap-less shipping
>>> we therefore want to be sure that feedback has been taken into account and
>>> incorporated into the API. Can you point to such examples?
>>>
>>> /Daniel
>>> On 2022-01-07 05:39, 'Jiewei Qian' via blink-dev wrote:
>>>
>>> Hi Blink Owners,
>>>
>>> We are shipping the API in M99, but want to avoid a gap for users yet to
>>> update from M98.
>>>
>>> We are asking to extend the OT end date (currently 2022-02-22, one week
>>> before M99 release) to 2022-04-15 (two weeks after M100 release), without
>>> changing the end milestone.
>>>
>>> This should allow enough time for users to update.
>>>
>>> The API shipped in M99 is the same as the one under origin trial.
>>>
>>> Thanks for considering.
>>>
>>>
>>> On Tue, Jan 4, 2022 at 6:36 AM Chris Harrelson 
>>> wrote:
>>>
 LGTM

 On Tue, Dec 21, 2021 at 7:33 PM Jiewei Qian  wrote:

> Contact emails q...@chromium.org, hongli...@chromium.org,
> mgi...@chromium.org
>
> Explainer
> https://github.com/WICG/handwriting-recognition/blob/main/explainer.md
>
> Specification https://wicg.github.io/handwriting-recognition/
>
> Design docs
> https://github.com/WICG/handwriting-recognition/blob/main/explainer.md
>
> Summary
>
> An API for web applications to make use of advanced handwriting
> recognition services (e.g. those on operating systems) to recognize text
> from handwriting drawings (inks) in real time. In this context, 
> handwriting
> drawing means the temporal and positional information used to describe a
> human handwriting process.
>
>
> Blink component Blink>Handwriting
> 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/591
>
> TAG review status Issues addressed
>
> Link to origin trial feedback summary
> https://docs.google.com/document/d/1BGd3WiwiqBA1JQaG-r0bc5No0f0KkqW13EhO1YeQocA/edit
>
> Risks
>
>
> Interoperability and Compatibility
>
> Different browsers (and operating systems) will expose different
> underlying implementations and produce different outputs given the same
> input. We think this is acceptable given the implementation is
> machine-learning based, and it is not feasible or desirable to precisely
> specify the expected output for a given input in a standard. In the past,
> we have taken this approach for the Web Speech and Shape Detection APIs.
>
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/507) Feedback
> requested, no reply yet.
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-March/031762.html)
> Feedback requested, no reply yet.
>
> Web developers: Positive (
> https://github.com/WICG/handwriting-recognition/issues/21) Twitter:
> https://twitter.com/ChromiumDev/status/1428640785810051074
>
> Other signals:
>
>
> Goals for experimentation
>
> - General API design. Determine if the API design satisfies the App
> developer's use cases - Specifically, we want to see if the current API
> design provides sufficient information (in the result) to enable web
> developers to make use of this feature.
>
>
> Reason this experiment is being extended
> No gap before shipping.
>
> Already LGTMed by blink API owners (chrishtr@) in
> https://groups.google.com/a/chromium.org/g/blink-dev/c/s3n3bGl6i1M/m/36V-w8-rDAAJ
> .
>
> Revised timeline: Original origin trial - first milestone: M91
> Original origin trial - last milestone: M97 Extended origin trial - last
> milestone: M98
>
>
> Ongoing technical constraints
>
> None
>
>
> Debuggability
>
> N/A. Existing DevTools tooling works for this feature.
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)? No
>
> Initially we will implement this feature on Chrome OS, since it has
> handwriting recognition