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

[Jiewei Qian]

The spec is currently being reviewed by the spec mentor. Otherwise we think
the feature is ready for review.

On Thu, Dec 16, 2021 at 3:57 AM Chris Harrelson 
wrote:

> Coming back to the intent-to-ship part: do you consider it ready for
> approval? Or are there more spec or other issues to iron out before we
> should consider approval?
>
> On Thu, Dec 9, 2021 at 9:50 PM Chris Harrelson 
> wrote:
>
>> I think it's ok. LGTM. Thanks for doing your best to ship a high-quality
>> implementation!
>>
>> Note that this will be a total of 8 milestones
>> ,
>> including M98, but as was mentioned in a previous intent, there was also a
>> breaking API change in M95, plus evidence of experimental feedback.
>>
>> On Wed, Dec 8, 2021 at 9:07 PM Glen Robertson 
>> wrote:
>>
>>> Given that the Handwriting Recognition OT ends with M97, and M98
>>> branches today, it seems like it will be difficult to ship in M98 - a merge
>>> request to enable the feature is unlikely to be approved.
>>>
>>> Blink Owners: Would it be acceptable to extend the OT for 1 additional
>>> milestone (end in M98) and ship in M99?
>>>
>>> On Thu, 9 Dec 2021 at 02:57, 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/ [in review]

 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:


 Debuggability

 N/A. Existing DevTools tooling works for this feature.


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

 No. Full coverage relies on platform-specific implementation. WPT only
 tests failure cases.

 Flag name

 Requires code in //chrome?

 False

 Tracking bug

 https://crbug.com/1207667

 Launch bug

 https://crbug.com/1206121

 Estimated milestones

 OriginTrial desktop last

 97

 OriginTrial desktop first

 91




 Link to entry on the Chrome Platform Status

 https://chromestatus.com/feature/5263213807534080

 Links to previous Intent discussions

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

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


 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/CAPV%2BSg-5XE4cpDbwT69_T4

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

[Ari Chivukula]

Please ignore this thread and 
use https://groups.google.com/a/chromium.org/g/blink-dev/c/JQ68cvYuiQU 
instead. This one was mislabeled as an intent to prototype, when it should 
be an intent to ship.

On Monday, December 20, 2021 at 2:00:00 PM UTC-8 Ari Chivukula wrote:

> Contact emails
>
> aric...@chromium.org, jadekess...@chromium.org, miketa...@chromium.org
>
> Design Doc
>
>
> https://docs.google.com/document/d/1U3P9yvaT1NXG_qRmY3Lp6Me7M5kTnd3QrBb1yFUVNNk/edit
>
> Specification
>
> https://wicg.github.io/client-hints-infrastructure/
>
> Summary
>
> To support content negotiation use cases such as differential serving of 
> variable 
> fonts 
> ,
>  
> color vector fonts , 
> responsive images 
> ,
>  
> and other third-party content which requires client information lost by user 
> agent reduction 
> . For 
> example: variable fonts 
> 
>  
> allow significantly less font information to be transferred without loss of 
> functionality, but only works on specific operating systems.
>
>  
>
> Blink component
>
> Blink>Network>ClientHints 
> 
>
>  
>
> Motivation
>
> It’s already possible to set a Permissions Policy 
>  in the HTTP response 
> header, but for sites without the ability to modify HTTP headers a HTML 
> solution would be ideal. This proposal ships a meta tag which allows 
> delegation of client hints to third-party origins. These tags could be 
> included in code-snippets for embedded third-party content for ease of use.
>
>  
>
> For example, to specify third party requests to `https://foo.bar` must 
> include `sec-ch-width` you could include:
>
> https://foo.bar )">
>
>  
>
> You may still omit the permission policy and rely on the default allowlist 
> as follows:
>
> 
>
>  
>
> Note that this is the equivalent of the following today:
>
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/702
>
> Compatibility
>
> We do not anticipate compatibility risks for this addition - Blink 
> currently implements first party client hints via a `http-equiv` meta tag, 
> and that functionality will not be removed or modified.
>
>  
> Interoperability
>
>  
>
> Gecko: Neutral 
>
>  
>
> WebKit: Requested 
> 
>
>  
>
> Web developers: Positive interest from Cloudinary 
> 
>
> Debuggability
>
> Any improperly formatted client hint meta tags will be flagged in the 
> Issues tab 
> 
> .
>
> Is this feature fully tested by web-platform-tests?
>
> https://github.com/web-platform-tests/wpt/pull/32142
>
> Tracking bug
>
> https://crbug.com/1219359
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5684289032159232
>
>

-- 
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/e94121ce-4969-4ddc-8003-82bd926a5102n%40chromium.org.

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

[Ari Chivukula]

Contact emails

aric...@chromium.org, jadekess...@chromium.org, miketa...@chromium.org

Design Doc

https://docs.google.com/document/d/1U3P9yvaT1NXG_qRmY3Lp6Me7M5kTnd3QrBb1yFUVNNk/edit

Specification

https://wicg.github.io/client-hints-infrastructure/


Intent to Prototype

https://groups.google.com/a/chromium.org/g/blink-dev/c/FTNrw03Xs9s/m/O74Mp6bmCAAJ


Summary

To support content negotiation use cases such as differential serving
of variable
fonts
,
color vector fonts
, responsive
images
,
and other third-party content which requires client information lost by user
agent reduction
. For
example: variable fonts

allow significantly less font information to be transferred without loss of
functionality, but only works on specific operating systems.



Blink component

Blink>Network>ClientHints




Motivation

It’s already possible to set a Permissions Policy
 in the HTTP response
header, but for sites without the ability to modify HTTP headers a HTML
solution would be ideal. This proposal ships a meta tag which allows
delegation of client hints to third-party origins. These tags could be
included in code-snippets for embedded third-party content for ease of use.



For example, to specify third party requests to `https://foo.bar` must
include `sec-ch-width` you could include:

https://foo.bar )">



You may still omit the permission policy and rely on the default allowlist
as follows:





Note that this is the equivalent of the following today:



TAG review

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

Compatibility

We do not anticipate compatibility risks for this addition - Blink
currently implements first party client hints via a `http-equiv` meta tag,
and that functionality will not be removed or modified.


Interoperability



Gecko: Neutral 



WebKit: Requested




Web developers: Positive interest from Cloudinary


Debuggability

Any improperly formatted client hint meta tags will be flagged in the
Issues tab

.

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

https://github.com/web-platform-tests/wpt/pull/32142

Tracking bug

https://crbug.com/1219359

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5684289032159232

-- 
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/CAGpy5D%2BCMCakKz0dH9C-d7%3D75446vu-j3geD5ZgbKmQSsQm9vA%40mail.gmail.com.

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

[Ari Chivukula]

Contact emails

aric...@chromium.org, jadekess...@chromium.org, miketa...@chromium.org

Design Doc

https://docs.google.com/document/d/1U3P9yvaT1NXG_qRmY3Lp6Me7M5kTnd3QrBb1yFUVNNk/edit

Specification

https://wicg.github.io/client-hints-infrastructure/

Summary

To support content negotiation use cases such as differential serving
of variable
fonts
,
color vector fonts
, responsive
images
,
and other third-party content which requires client information lost by user
agent reduction
. For
example: variable fonts

allow significantly less font information to be transferred without loss of
functionality, but only works on specific operating systems.



Blink component

Blink>Network>ClientHints




Motivation

It’s already possible to set a Permissions Policy
 in the HTTP response
header, but for sites without the ability to modify HTTP headers a HTML
solution would be ideal. This proposal ships a meta tag which allows
delegation of client hints to third-party origins. These tags could be
included in code-snippets for embedded third-party content for ease of use.



For example, to specify third party requests to `https://foo.bar` must
include `sec-ch-width` you could include:

https://foo.bar )">



You may still omit the permission policy and rely on the default allowlist
as follows:





Note that this is the equivalent of the following today:



TAG review

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

Compatibility

We do not anticipate compatibility risks for this addition - Blink
currently implements first party client hints via a `http-equiv` meta tag,
and that functionality will not be removed or modified.


Interoperability



Gecko: Neutral 



WebKit: Requested




Web developers: Positive interest from Cloudinary


Debuggability

Any improperly formatted client hint meta tags will be flagged in the
Issues tab

.

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

https://github.com/web-platform-tests/wpt/pull/32142

Tracking bug

https://crbug.com/1219359

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5684289032159232

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

Re: [blink-dev] Re: Intent to Ship: WebRTC Scalable Video Coding extensions

['Chris Cunningham' via blink-dev]

Sorry I'm late. Lots of family stuff this month. I'm about to be OOO for 
the holidays. 

> There seems to be agreement to add support for referenceScaling in Media 
Capabilities (https://github.com/w3c/media-capabilities/issues/182) so I'm 
assuming that a PR will follow.  

I can confirm this agreement for MediaCapabilities. I expect +Johannes Kron 
will send a PR to amend the MC spec. 

On Wednesday, December 15, 2021 at 3:14:42 PM UTC-8 Harald Alvestrand wrote:

> At the moment, I think we can safely ship:
>
> - RTCRtpEncodingParameters extension scalabilityMode (
> https://w3c.github.io/webrtc-svc/#dom-rtcrtpencodingparameters-scalabilitymode
> )
>
> We have an open discussion on whether or not to ship this part on senders 
> (we've decided not to ship it on receivers):
>
> - RTCRtpCodecCapability extension scalabilityModes (
> https://w3c.github.io/webrtc-svc/#dom-rtcrtpcodeccapability-scalabilitymodes
> )
>
> There are no mandatory-to-implement scalability modes except for L1T1 
> (which we need to add support for).
>
> I think that as currently specified, feature detection can be done in the 
> absence of the RTCRtpCodecCapability extension by setting the mode to L1T1, 
> reading back the encoding parameters, and seeing if the mode is set.
>
>
>
>
> On Wed, Dec 15, 2021 at 6:01 PM Philip Jägenstedt  
> wrote:
>
>> Hi Bernard,
>>
>> Can you clarify what the consensus is on RTCRtpEncodingParameters's 
>> scalabilityMode member? That remains in https://w3c.github.io/webrtc-svc/, 
>> but will it be removed? Meanwhile, referenceScaling is only partly spec'd, 
>> there's no IDL for it but a link to 
>> https://github.com/w3c/media-capabilities/issues/182.
>>
>> Harald, if you could confirm the precise API surface that you'd like to 
>> ship, that would be great.
>>
>> Best regards,
>> Philip
>>
>> On Thu, Dec 9, 2021 at 3:21 AM Bernard Aboba  wrote:
>>
>>> Harald said: 
>>>
>>> "It seems like we don't have a strong push towards either the 
>>> MediaCapabilities or the Codec Capabilities solution in the issue on the 
>>> sender side (https://github.com/w3c/webrtc-svc/issues/49). This is bad 
>>> for quick resolution."
>>>
>>> [BA] On the receiver/decoder side (for WebRTC-SVC, Media Capabilities 
>>> and WebCodecs), we have a path forward  which involves using a 
>>> referenceScaling boolean and removing scalabiltyMode advertisement and 
>>> configuration.  The consensus is  reflected in the current editor's draft 
>>> of WebRTC-SVC (see:  https://w3c.github.io/webrtc-svc/ ) and compatible 
>>> PRs are under development for MediaCapabilities and WebCodecs. 
>>>
>>> On the sender/encoder side, we have added the "L1T1" scalability mode 
>>> and specified its use in both advertisement and encoder configuration. 
>>>
>>> Chris can provide more details with respect to the moving parts in Media 
>>> Capabilities and WebCodecs. 
>>>
>>> Here are links to the (now resolved) WebRTC-SVC issues:
>>> https://github.com/w3c/webrtc-svc/issues/48
>>> https://github.com/w3c/webrtc-svc/issues/52
>>>
>>> Here are links to related WebCodecs issues: 
>>> https://github.com/w3c/webcodecs/issues/399
>>>
>>> Here are links to the related Media Capabilities issues:  
>>> https://github.com/w3c/media-capabilities/issues/182
>>> https://github.com/w3c/media-capabilities/issues/183
>>> https://github.com/w3c/media-capabilities/issues/185
>>>
>>>
>>>
>>>
>>> On Wednesday, December 8, 2021 at 9:37:57 AM UTC-8 Philipp Hancke wrote:
>>>
 Am Mi., 8. Dez. 2021 um 17:52 Uhr schrieb Philip Jägenstedt <
 foo...@chromium.org>:

> Hi Harald,
>
> Can you spell out what the uncontroversial parts of this would be? 
> Looking at the IDL in https://w3c.github.io/webrtc-svc/ it looks like 
> it's all about modes.
>
> My guess is that it's RTCRtpEncodingParameters's scalabilityMode, but 
> is that right?
>

 yeah

 https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_rtp_encoding_parameters.idl;l=24
 which is currently behind a flag.

 Best regards,
> Philip
>
> On Mon, Dec 6, 2021 at 3:27 PM 'Harald Alvestrand' via blink-dev <
> blin...@chromium.org> wrote:
>
>> It seems like we don't have a strong push towards either the 
>> MediaCapabilities or the Codec Capabilities solution in the issue on the 
>> sender side (https://github.com/w3c/webrtc-svc/issues/49). This is 
>> bad for quick resolution.
>>
>> In the interest of getting the uncontroversial parts shipped - what 
>> would people think of letting the Codec Capabilities list of modes 
>> remain 
>> behind the flag, and push the rest of the API to public?
>> Many usages of the function would work quite well with only probing 
>> for supported modes by trying to set the ones they want; we could then 
>> let 
>> the issue sort itself out in peace.
>>
>> (On the receiver side, there seems

Re: [blink-dev] Intent to Deprecate and Remove: Minor WebCodecs spec violations

['Chris Cunningham' via blink-dev]

Thanks Mike,

> LGTM1 if we can change the deprecation message to "is deprecated".

CL is out for review 
. All of 
the OWNERS are OOO until the new year, but 98 doesn't promote to Beta until 
Jan 6... could still work out. 

Best,
Chris

On Monday, December 20, 2021 at 11:42:34 AM UTC-8 Chris Harrelson wrote:

> LGTM2
>
> On Mon, Dec 20, 2021, 6:41 AM Mike Taylor  wrote:
>
>> On 12/19/21 7:03 PM, Chris Cunningham wrote:
>>
>> Hi Mike, 
>>
>> > And the proposed change here is to remove temporalLayderId as a 
>> top-level key on EncodedVideoChunkMetadata, right?
>>
>> That's right.
>>
>> > The proposed change here is to start throwing without a timestamp key 
>> in the VideoFrameInit dictionary, for all "image" types except VideoFrame 
>> and HTMLVideoElement, correct?
>>
>> That's also right. 
>>
>> > Can you clarify the timing of the proposed removal? Do you intend to 
>> send deprecation messages in M99, and if so, for how long? Or do you intend 
>> to deprecate and remove all at once in M99?
>>
>> My ideal timing would be to remove in 99. We've just landed a flag (
>> --enable-features=RemoveWebCodecsSpecViolations 
>> ) to 
>> simulate the removal, which I should be able to merge back to 98. We landed 
>> a "may deprecate" message for the VideoFrame constructor in 97. I could 
>> merge a change to 98 that hardens language to "is deprecated". I'm not sure 
>> we can add a message for the metadata.temporalLayerId deprecation since 
>> it's just an output dictionary member.
>>
>> Happy to be flexible if this timeline is problematic. At this point I 
>> think the usage of the bad paths is actually near zero, so a faster 
>> timeline has advantages too. 
>>
>> Given that usage is around .00015% right now, I agree that moving faster 
>> on this change is probably smart. *LGTM1* if we can change the 
>> deprecation message to "is deprecated". 
>>
>> Merging back the flag back to M98 seems useful if we can make developers 
>> aware it exists, perhaps by updating https://web.dev/webcodecs/ with an 
>> "update" blurb up to mentioning the changes and the flag?
>>
>> (Before I hit send, I went and searched for `temporalLayerId` in the 
>> httparchive.latest.requests_desktop dataset and got zero results - that 
>> makes me feel better about hitting send).
>>
>> Best,
>> Chris
>>
>>
>>
>> On Sat, Dec 18, 2021 at 12:30 PM Mike Taylor  
>> wrote:
>>
>>> Hi Chris,
>>>
>>> On 12/17/21 3:24 PM, Chris Cunningham wrote:
>>>
>>> Contact emails 
>>>
>>>
>>> * chcunn...@chromium.org * Explainer 
>>>
>>>
>>> * https://github.com/w3c/webcodecs/blob/main/explainer.md 
>>>    * 
>>> Specification 
>>>
>>>
>>> * https://w3c.github.io/webcodecs/  * 
>>> Summary 
>>>
>>>
>>> * We've identified two areas where our implementation violates the 
>>> specification. We've implemented parallel correct paths for authors to use 
>>> and would like to deprecate the original bad paths. The issues affect 
>>> VideoFrame construction and the EncodedVideoChunkMetadata dictionary. * 
>>> Blink 
>>> component 
>>>
>>>
>>> * Blink>Media>WebCodecs 
>>> 
>>>  
>>> * Motivation 
>>>
>>>
>>>
>>> * We've identified two areas where our implementation of WebCodecs 
>>> violates the specification. We've considered changing the spec, but prefer 
>>> to instead fix the implementation. The specified behavior is cleaner and 
>>> less error prone. The changes are breaking, but the workarounds are trivial 
>>> and WebCodecs usage is currently very low (we just shipped in Chrome 94, 
>>> only engine to ship so far). 
>>> https://chromestatus.com/metrics/feature/timeline/popularity/3464 
>>>  
>>> Details: 1. The spec defines the temporalLayerId attribute as a member of 
>>> the SvcOutputMetadata dictionary which is nested under the 
>>> EncodedVideoChunkMetadata dictionary (metadata.svc.temporalLayerId). But 
>>> Chrome places the temporalLayerId directly on the top level 
>>> EncodedVideoChunkMetadata dictionary (metadata.temporalLayerId). As of 
>>> Chrome 98, either option is available.  * 
>>>
>>> And the proposed change here is to remove temporalLayderId as a 
>>> top-level key on EncodedVideoChunkMetadata, right?
>>>
>>> * 2. The spec requires that the VideoFrame(CanvasImageSource, ...) 
>>> constructor include a timestamp argument (VideoFrameInit.timestamp) for 
>>> CanvasImageSource types that don't implicitly have a timestamp (e.g. 
>>> HTMLCanvasElement). Failing to include the timestamp should result in a 
>>> TypeError, but Chrome currently defaults the timestamp to zero. Chrome will 
>>> respect the timestamp if one is given. * 
>>>
>>> The proposed change here is to start thro

Re: [blink-dev] Intent to Deprecate and Remove: Minor WebCodecs spec violations

[Chris Harrelson]

LGTM2

On Mon, Dec 20, 2021, 6:41 AM Mike Taylor  wrote:

> On 12/19/21 7:03 PM, Chris Cunningham wrote:
>
> Hi Mike,
>
> > And the proposed change here is to remove temporalLayderId as a
> top-level key on EncodedVideoChunkMetadata, right?
>
> That's right.
>
> > The proposed change here is to start throwing without a timestamp key in
> the VideoFrameInit dictionary, for all "image" types except VideoFrame and
> HTMLVideoElement, correct?
>
> That's also right.
>
> > Can you clarify the timing of the proposed removal? Do you intend to
> send deprecation messages in M99, and if so, for how long? Or do you intend
> to deprecate and remove all at once in M99?
>
> My ideal timing would be to remove in 99. We've just landed a flag (
> --enable-features=RemoveWebCodecsSpecViolations
> ) to
> simulate the removal, which I should be able to merge back to 98. We landed
> a "may deprecate" message for the VideoFrame constructor in 97. I could
> merge a change to 98 that hardens language to "is deprecated". I'm not sure
> we can add a message for the metadata.temporalLayerId deprecation since
> it's just an output dictionary member.
>
> Happy to be flexible if this timeline is problematic. At this point I
> think the usage of the bad paths is actually near zero, so a faster
> timeline has advantages too.
>
> Given that usage is around .00015% right now, I agree that moving faster
> on this change is probably smart. *LGTM1* if we can change the
> deprecation message to "is deprecated".
>
> Merging back the flag back to M98 seems useful if we can make developers
> aware it exists, perhaps by updating https://web.dev/webcodecs/ with an
> "update" blurb up to mentioning the changes and the flag?
>
> (Before I hit send, I went and searched for `temporalLayerId` in the
> httparchive.latest.requests_desktop dataset and got zero results - that
> makes me feel better about hitting send).
>
> Best,
> Chris
>
>
>
> On Sat, Dec 18, 2021 at 12:30 PM Mike Taylor 
> wrote:
>
>> Hi Chris,
>>
>> On 12/17/21 3:24 PM, Chris Cunningham wrote:
>>
>> Contact emails
>>
>>
>> * chcunning...@chromium.org  * Explainer
>>
>>
>> * https://github.com/w3c/webcodecs/blob/main/explainer.md
>>    *
>> Specification
>>
>>
>> * https://w3c.github.io/webcodecs/  *
>> Summary
>>
>>
>> * We've identified two areas where our implementation violates the
>> specification. We've implemented parallel correct paths for authors to use
>> and would like to deprecate the original bad paths. The issues affect
>> VideoFrame construction and the EncodedVideoChunkMetadata dictionary. * Blink
>> component
>>
>>
>> * Blink>Media>WebCodecs
>> 
>> * Motivation
>>
>>
>>
>> * We've identified two areas where our implementation of WebCodecs
>> violates the specification. We've considered changing the spec, but prefer
>> to instead fix the implementation. The specified behavior is cleaner and
>> less error prone. The changes are breaking, but the workarounds are trivial
>> and WebCodecs usage is currently very low (we just shipped in Chrome 94,
>> only engine to ship so far).
>> https://chromestatus.com/metrics/feature/timeline/popularity/3464
>> 
>> Details: 1. The spec defines the temporalLayerId attribute as a member of
>> the SvcOutputMetadata dictionary which is nested under the
>> EncodedVideoChunkMetadata dictionary (metadata.svc.temporalLayerId). But
>> Chrome places the temporalLayerId directly on the top level
>> EncodedVideoChunkMetadata dictionary (metadata.temporalLayerId). As of
>> Chrome 98, either option is available.  *
>>
>> And the proposed change here is to remove temporalLayderId as a top-level
>> key on EncodedVideoChunkMetadata, right?
>>
>> * 2. The spec requires that the VideoFrame(CanvasImageSource, ...)
>> constructor include a timestamp argument (VideoFrameInit.timestamp) for
>> CanvasImageSource types that don't implicitly have a timestamp (e.g.
>> HTMLCanvasElement). Failing to include the timestamp should result in a
>> TypeError, but Chrome currently defaults the timestamp to zero. Chrome will
>> respect the timestamp if one is given. *
>>
>> The proposed change here is to start throwing without a timestamp key in
>> the VideoFrameInit dictionary, for all "image" types except VideoFrame and
>> HTMLVideoElement, correct?
>>
>> Initial public proposal
>>
>>
>> *
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/7UlTzFMbTFs/m/Rib4ca4-BQAJ
>> 
>> * TAG review
>>
>>
>> * https://github.com/w3ctag/design-reviews/issues/612
>>  * TAG review status
>>
>>
>> * Complete * Risks
>> Site breakage
>>
>>
>>

Re: [blink-dev] Fwd: Can't run Web Tests locally on MacOS 12 device

[Slade Watkins]

On Thu, Dec 16, 2021 at 5:32 PM Dave Tapuska  wrote:
>
> FYI... Seems PHP was removed in macOS Monterey. Nico sounds like we need to 
> revert your patch.

dave,
yes, PHP was removed in macOS 12.
https://developer.apple.com/forums/thread/681907

cheers,
slade

--
This email message may contain sensitive or otherwise confidential
information and is intended for the addressee(s) only. If you believe
to have received this message in error, please let the sender know
*immediately* and delete the message. Thank you for your cooperation!

-- 
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/CA%2Bpv%3DHPRuLfNMfrhLV3Uvu4x9-z2whtqi3Mwici9meHo3H5hHw%40mail.gmail.com.

[blink-dev] Disable devtools in release build

[Rahul Patel]

Hi All,
 Looks like Chromium devtools/devtools_frontend is enabled by default in
every build, is there a way to remove devtools from the release build?

I am looking for the binary size reduction, and I am hoping it would help
us?


Thanks,
 Rahul

-- 
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/CAAbAqvyozogv-62v9FiZ5DOHh%3DjmZHbdSm2_2H-%3DBZsco63upQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Unprefixed text-emphasis properties

['Joe Medley' via blink-dev]

Kent,

In which version are you hoping to ship this?

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


On Thu, Dec 16, 2021 at 9:01 AM Manuel Rego Casasnovas 
wrote:

>
>
> On 16/12/2021 15:49, TAMURA, Kent wrote:
> > I think so.  If the current implementation has interoperability issues,
> > we should fix them before shipping the unprefixed properties.
>
> LGTM3, if we fix the potential interop issues before shipping.
>
> Cheers,
>   Rego
>
> --
> 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/e99a1321-256c-c59f-67e7-b8b3948e262a%40igalia.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/CAJUhtG_f2NG8f-xqaKXi-p-CrPcXWF8RPHusF2QRVCW5xxD3Kg%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Minor WebCodecs spec violations

[Mike Taylor]

On 12/19/21 7:03 PM, Chris Cunningham wrote:

Hi Mike,

> And the proposed change here is to remove temporalLayderId as a 
top-level key on EncodedVideoChunkMetadata, right?


That's right.

> The proposed change here is to start throwing without a timestamp 
key in the VideoFrameInit dictionary, for all "image" types except 
VideoFrame and HTMLVideoElement, correct?


That's also right.

> Can you clarify the timing of the proposed removal? Do you intend to 
send deprecation messages in M99, and if so, for how long? Or do you 
intend to deprecate and remove all at once in M99?


My ideal timing would be to remove in 99. We've just landed a flag 
(--enable-features=RemoveWebCodecsSpecViolations 
) 
to simulate the removal, which I should be able to merge back to 98. 
We landed a "may deprecate" message for the VideoFrame constructor in 
97. I could merge a change to 98 that hardens language to "is 
deprecated". I'm not sure we can add a message for the 
metadata.temporalLayerId deprecation since it's just an output 
dictionary member.


Happy to be flexible if this timeline is problematic. At this point I 
think the usage of the bad paths is actually near zero, so a faster 
timeline has advantages too.


Given that usage is around .00015% right now, I agree that moving faster 
on this change is probably smart. *LGTM1* if we can change the 
deprecation message to "is deprecated".


Merging back the flag back to M98 seems useful if we can make developers 
aware it exists, perhaps by updating https://web.dev/webcodecs/ with an 
"update" blurb up to mentioning the changes and the flag?


(Before I hit send, I went and searched for `temporalLayerId` in the 
httparchive.latest.requests_desktop dataset and got zero results - that 
makes me feel better about hitting send).



Best,
Chris



On Sat, Dec 18, 2021 at 12:30 PM Mike Taylor  
wrote:


Hi Chris,

On 12/17/21 3:24 PM, Chris Cunningham wrote:



Contact emails


*

chcunning...@chromium.org


*


Explainer


*

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


*


Specification


*

https://w3c.github.io/webcodecs/



*


Summary


*

We've identified two areas where our implementation
violates the specification. We've implemented parallel
correct paths for authors to use and would like to
deprecate the original bad paths. The issues affect
VideoFrame construction and the EncodedVideoChunkMetadata
dictionary.


*


Blink component


*

Blink>Media>WebCodecs




*


Motivation


*

We've identified two areas where our implementation of
WebCodecs violates the specification. We've considered
changing the spec, but prefer to instead fix the
implementation. The specified behavior is cleaner and
less error prone. The changes are breaking, but the
workarounds are trivial and WebCodecs usage is currently
very low (we just shipped in Chrome 94, only engine to
ship so far).
https://chromestatus.com/metrics/feature/timeline/popularity/3464



Details:


1. The spec defines the temporalLayerId attribute as a
member of the SvcOutputMetadata dictionary which is
nested under the EncodedVideoChunkMetadata dictionary
(metadata.svc.temporalLayerId). But Chrome places the
temporalLayerId directly on the top level
EncodedVideoChunkMetadata dictionary
(metadata.temporalLayerId). As of Chrome 98, either
option is available.

*


And the proposed change here is to remove temporalLayderId as a
top-level key on EncodedVideoChunkMetadata, right?



*

2. The spec requires that the
VideoFrame(CanvasImageSource, ...) constructor include a
timestamp argument (VideoFrameInit.timestamp) for
CanvasImageSource types that don't implicitly have a
timestamp (e.g. HTMLCanvasElement). Failing to include
the timestamp should result in a TypeError, but Chrome
currently defaults the timestamp to zero. Chrome will
respect the timestamp if one is given.

*


The proposed change here is to start throwing without a timestamp
key in the VideoFrameInit dictionary, for all "image" types except
VideoFrame and HTMLVideoElem

Re: [blink-dev] Re: Intent to Deprecate and Freeze: The User-Agent string

[Mike Taylor]

Hi Chris,

Could you please file a bug at crbug.com/new, with the exact website you 
had an issue on? I'm happy to follow up once that's done.


thanks,
Mike

On 12/20/21 9:11 AM, Chris Bloggs wrote:
Can someone please contact sony, when I reduced these headers I was 
unable to auth on their website, it seems they specifically probably 
have whitelisted portions of the removed headers to allow 
authentication, it needs a google/chrome rep rather than a end user 
like myself.


On Friday, 11 June 2021 at 18:34:14 UTC+1 James Rosewell wrote:

Please could you publish information concerning this proposals
compliance with the draft commitments Google


made to the Competition and Markets Authority which were published
today?
On Wednesday, 19 May 2021 at 21:49:10 UTC+1 Mike Taylor wrote:

Hi Par (and others),

Today we published an update on our UA Reduction plans, in a
new thread:
https://groups.google.com/a/chromium.org/g/blink-dev/c/e3pZJu96g6c


Happy to answer any questions over there (rather than engage
in multiple
threads on the topic).

Thanks,
Mike

On 5/6/21 10:33 AM, Mike Taylor wrote:
> Hi Par,
>
> Yep, this is the right mailing list to follow for announcements
> related to these proposed changes.
>
> We don't have anything to share right now, but hope to soon
(not a
> super satisfying answer, I know).
>
> thanks,
> Mike
>
> On 5/6/21 9:22 AM, 'par.andersson%neten...@gtempaccount.com'
via
> blink-dev wrote:
>> Any update on this? Where can I follow progress on this
topic, is
>> this the right place? (sorry if this has been
asked/answered before,
>> I have not seen such comment)
>> Thanks,
>> Par
>>
>> On Thursday, February 25, 2021 at 5:20:34 AM UTC+1 Aaron
Tagliaboschi
>> wrote:
>>
>>
>>
>>     On Wed, Feb 24, 2021, 22:41 James Nghiem

>> wrote:
>>
>>
>>     Ah I see it in the release now. A few more questions:
>>     As part of the Chrome 89 rollout, I'm assuming that
the UA will
>>     also be frozen, correct?
>>
>>
>>     No, the UA string will *not* be frozen in Chrome 89.
We've yet to
>>     release a firm timeline.
>>
>>     If so, will the UA still be up-to-date for Chrome
89 or should
>>     we expect it to be frozen at Chrome 88's value?
>>     On Wednesday, February 24, 2021 at 11:16:43 AM
UTC-8 Aaron
>>     Tagliaboschi wrote:
>>
>>     The User Agent Client Hints feature will be
fully rolled in
>>     Chrome 89
>>
>>
>>     Aaron Tagliaboschi | Software Engineer, Chrome
Trust &
>> Safety
>>
>>
>>     On Wed, Feb 24, 2021 at 1:36 PM James Nghiem
>>      wrote:
>>
>>     Just wanted to follow up on this since I
haven't seen or
>>     been able to find any updates to the
timeline! Do we
>>     have any specific dates on when we're
expecting UACH to
>>     roll out?
>>
>>
>>
>>     On Friday, January 29, 2021 at 9:16:39 AM
UTC-8 Thomas
>>     Ziegelbecker wrote:
>>
>>     +1 ?
>>
>>     On Thursday, December 17, 2020 at
9:31:48 PM UTC+1
>>     Saurav Kumar wrote:
>>
>>     Hi James,
>>
>>     Now that we are nearing 2021, do we
have an
>>     approximate date when Chrome would
start to roll
>>     out frozen UA strings?
>>
>>     Thanks
>>     Saurav
>>
>>     On Monday, 27 July 2020 at 14:32:01
UTC-7 James
>>     Nghiem wrote:
>>
>>     Hi Yoav,
>>
>>     Just wanted to clarify part of
your message:
>>
>>  > First, the phase of the
project that
>>     reduces the amount of available
information
>>     in the tradit

Re: [blink-dev] Re: Intent to Deprecate and Freeze: The User-Agent string

[Chris Bloggs]

Can someone please contact sony, when I reduced these headers I was unable 
to auth on their website, it seems they specifically probably have 
whitelisted portions of the removed headers to allow authentication, it 
needs a google/chrome rep rather than a end user like myself.

On Friday, 11 June 2021 at 18:34:14 UTC+1 James Rosewell wrote:

> Please could you publish information concerning this proposals compliance 
> with the draft commitments Google 
> 
>  
> made to the Competition and Markets Authority which were published today?
> On Wednesday, 19 May 2021 at 21:49:10 UTC+1 Mike Taylor wrote:
>
>> Hi Par (and others), 
>>
>> Today we published an update on our UA Reduction plans, in a new thread: 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/e3pZJu96g6c 
>>
>> Happy to answer any questions over there (rather than engage in multiple 
>> threads on the topic). 
>>
>> Thanks, 
>> Mike 
>>
>> On 5/6/21 10:33 AM, Mike Taylor wrote: 
>> > Hi Par, 
>> > 
>> > Yep, this is the right mailing list to follow for announcements 
>> > related to these proposed changes. 
>> > 
>> > We don't have anything to share right now, but hope to soon (not a 
>> > super satisfying answer, I know). 
>> > 
>> > thanks, 
>> > Mike 
>> > 
>> > On 5/6/21 9:22 AM, 'par.andersson%neten...@gtempaccount.com' via 
>> > blink-dev wrote: 
>> >> Any update on this? Where can I follow progress on this topic, is 
>> >> this the right place? (sorry if this has been asked/answered before, 
>> >> I have not seen such comment) 
>> >> Thanks, 
>> >> Par 
>> >> 
>> >> On Thursday, February 25, 2021 at 5:20:34 AM UTC+1 Aaron Tagliaboschi 
>> >> wrote: 
>> >> 
>> >> 
>> >> 
>> >> On Wed, Feb 24, 2021, 22:41 James Nghiem  
>> >> wrote: 
>> >> 
>> >> 
>> >> Ah I see it in the release now. A few more questions: 
>> >> As part of the Chrome 89 rollout, I'm assuming that the UA 
>> will 
>> >> also be frozen, correct? 
>> >> 
>> >> 
>> >> No, the UA string will *not* be frozen in Chrome 89. We've yet to 
>> >> release a firm timeline. 
>> >> 
>> >> If so, will the UA still be up-to-date for Chrome 89 or should 
>> >> we expect it to be frozen at Chrome 88's value? 
>> >> On Wednesday, February 24, 2021 at 11:16:43 AM UTC-8 Aaron 
>> >> Tagliaboschi wrote: 
>> >> 
>> >> The User Agent Client Hints feature will be fully rolled 
>> in 
>> >> Chrome 89 
>> >> 
>> >> 
>> >> Aaron Tagliaboschi | Software Engineer, Chrome Trust & 
>> >> Safety 
>> >> 
>> >> 
>> >> On Wed, Feb 24, 2021 at 1:36 PM James Nghiem 
>> >>  wrote: 
>> >> 
>> >> Just wanted to follow up on this since I haven't seen 
>> or 
>> >> been able to find any updates to the timeline! Do we 
>> >> have any specific dates on when we're expecting UACH 
>> to 
>> >> roll out? 
>> >> 
>> >> 
>> >> 
>> >> On Friday, January 29, 2021 at 9:16:39 AM UTC-8 Thomas 
>> >> Ziegelbecker wrote: 
>> >> 
>> >> +1 ? 
>> >> 
>> >> On Thursday, December 17, 2020 at 9:31:48 PM UTC+1 
>> >> Saurav Kumar wrote: 
>> >> 
>> >> Hi James, 
>> >> 
>> >> Now that we are nearing 2021, do we have an 
>> >> approximate date when Chrome would start to 
>> roll 
>> >> out frozen UA strings? 
>> >> 
>> >> Thanks 
>> >> Saurav 
>> >> 
>> >> On Monday, 27 July 2020 at 14:32:01 UTC-7 
>> James 
>> >> Nghiem wrote: 
>> >> 
>> >> Hi Yoav, 
>> >> 
>> >> Just wanted to clarify part of your 
>> message: 
>> >> 
>> >>  > First, the phase of the project that 
>> >> reduces the amount of available 
>> information 
>> >> in the traditional User-Agent string to 
>> >> browser (e.g. “Chrome”), major browser 
>> >> version, and mobile/desktop, has been 
>> >> deferred until at least 2021 to provide 
>> >> additional time for the ecosystem to 
>> >> evaluate the new UA-CH capabilities. 
>> >> 
>> >> Will the delay also include freezing the 
>> UA 
>> >> string (i.e. will the current UA string be 
>> >> up-to-date until some change in 2021). 
>> >> 
>> >> Thanks and really appreciate your work! 
>> >>