Re: [blink-dev] Re: Intent to Ship: CSS Color Module Level 4 + color-mix()

[Daniel Bratell]

LGTM3 (note Rick's condition)

/Daniel

On 2022-10-28 18:37, Rick Byers wrote:



On Thu, Oct 27, 2022 at 3:09 PM 'Aaron Krajeski' via blink-dev 
 wrote:


What will be the devtools experience without that support? Will it
somewhat work and treat the value as an opaque string, or will it
be broken because it's not recognized?

The value becomes an opaque string, but the color picker does not
appear.


That seems reasonable enough to me to ship given Safari has already 
shipped and this is a focus of Interop 2022. Glad to hear work is 
progressing on first class DevTools support.


LGTM2 to ship when the WPT pass rate is at (or near) 100% as planned.

On Thursday, October 27, 2022 at 1:08:50 PM UTC-4 Philip
Jägenstedt wrote:

What will be the devtools experience without that support?
Will it somewhat work and treat the value as an opaque string,
or will it be broken because it's not recognized?

On Thu, Oct 27, 2022 at 5:01 PM Aaron Krajeski
 wrote:

Will the new DevTools support ship at the same time as
that feature?

Mostly likely not, though the dev tools team is hard at
work on features right now:

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

Is there a tracking bug for that?

Yup! crbug.com/1073895 

cc-ing Peter Müller for Dev Tools specific stuff.

On Thursday, October 27, 2022 at 8:12:07 AM UTC-4 Philip
Jägenstedt wrote:

Will the new DevTools support ship at the same time as
that feature? Is there a tracking bug for that?

On Thu, Oct 27, 2022 at 7:09 AM Yoav Weiss
 wrote:

LGTM1

On Wed, Oct 26, 2022 at 7:01 PM Aaron Krajeski
 wrote:


I think these 2 TAG reviews are related to this:
https://github.com/w3ctag/design-reviews/issues/488
https://github.com/w3ctag/design-reviews/issues/526

Commented on both threads! For lab() and lch()
there was no obvious delta, so I just pointed
them at the draft spec. For color-mix there
were some very small differences in input
syntax, I highlighted these and pointed at the
draft spec and tests.
On Wednesday, October 26, 2022 at 12:00:58 PM
UTC-4 yoav...@chromium.org wrote:

On Tuesday, October 25, 2022 at 5:03:26 PM
UTC+2 Mike Taylor wrote:

On 10/25/22 10:58 AM, 'Aaron Krajeski'
via blink-dev wrote:
> Gecko: Shipped/Shipping
>

(https://developer.mozilla.org/en-US/docs/Web/CSS/color_value)

>
> Is that the right link?
>
> Mozilla hasn't published anything
specific on implementing CSS color 4
> but their documentation now lists
all of the functions defined within
> it. That link has entries for lab,
lch and interpolation, for example.
> The new functions are implemented in
Firefox Nightly and that browser
> is currently passing most of the
tests on interop:

(Note that MDN documents many things
that are not implemented in Firefox
- it's not intended to be
browser-specific).

>

https://wpt.fyi/results/css/css-color?label=experimental&label=master&aligned



>
>
> On Tue, Oct 25, 2022 at 4:49 AM Yoav
Weiss  wrote:
>>
>>
>> On Thursday, October 20, 2022 at
4:51:07 PM UTC+2 Aaron Krajeski wrote:
>>> Contact emails
>>>
>>> aar...@chromium.org,
 

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Yoav Weiss]

How would the OT work for the Accept-Language values of the very-first
request sent to the origin? Or are we expecting this request to send higher
entropy, but not to hide potential breakage with later requests sending
lower entropy?

On Thu, Oct 27, 2022 at 7:57 PM Victor Tan  wrote:

> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org
>
> Explainer
>
> https://github.com/Tanych/accept-language
>
> Specification
>
> Variants header:
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>
> Summary
>
> We want to reduce the amount of information the Accept-Language header
> exposes in HTTP requests and JS interface navigator.languages. Instead of
> sending all user’s Accept-Language, we only send the user’s most preferred
> language after language negotiation in the Accept-Language header.
> navigator.languages returns the same value as navigator.language during
> this experiment.
>
> We would like to run an origin trial for sites to opt into the Reduce
> Accept-Language origin trial to proactively test for breakage. See below
> for more details.
>
> Implementation Doc
>
> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>
> Blink component
>
> Privacy>Fingerprinting
> 
>
> Risks
>
> Interoperability and Compatibility
>
> The compatibility risk is low since we're planning to reduce the amount of
> information in the Accept-Language header and navigator.languages, rather
> than remove the header or change value format in the header. Most existing
> Accept-Language detection code should continue to work.
>
> As for interoperability, no signal for other vendors. For multilingual
> sites to rely on the Accept-Language header, developers would need to
> depend on a user's full Accept-Language list for some browsers and a
> primary user's Accept-Language for others.
>
> Another signal is that the Chrome incognito model already reduced the
> Accept-Language header and JS interface navigator.languages to one
> language. The Accept-Language header can potentially expand to two if the
> first Accept-Language includes a region code, like en-US, the reduced
> Accept-Language  header will be en-US,en;q=0.9.
>
> Experiment Summary
>
> The experiment is going to be a little different from a normal Origin
> Trial. The goal is enabling developers to test and ensure compatibility
> with our proposed changes. It’s incredibly important we give developers any
> chance to test systems at every level since this change represents vast
> dependencies on the introduced headers.
>
> As for enabling with the origin trial itself, there will be two components
> controlled by the same origin trial:
>
>-
>
>Reducing the information in navigator.languages if the origin trial
>enabled.
>-
>
>The Accept-Language HTTP request header contains the user’s primary
>preferred language, this can change if we detect a more preferred language
>during the language negotiation process.
>
> Because of the experimental nature of reducing Accept-Language, a valid
> origin token must be sent in the response header by origins which opt-in
> the origin trial. Also two new headers Variants
> 
> (indicating sites supporting languages) accept-language and
> Content-Language  need to
> be sent in the response header in order to make the language negotiation to
> work correctly.
>
> Please see the design and implementation document
> for
> more information.
>
> Experiment Goals
>
> The goal of this origin trial is to enable developers to test how reducing
> the Accept-Language request header and the JS getter navigator.languages
> will affect their systems, especially to understand the user cases on
> navigator.languages. We hope this can provide sufficient time for
> developers to test. We can validate our current plans for reducing
> Accept-Language and safely roll out them to the web based on their feedback.
>
> We will be relying heavily on user and developer feedback to identify
> where breakage occurs,  or where use cases are not accounted for,
> especially for multilingual sites depending on the Accept-Language header,
> and navigator.languages.  We will create a GitHub repository and a public
> mailing list for gathering feedback. When the origin trial is ready, we
> plan to publish developer guidance on how to enroll and provide feedback.
>
> Experiment Risks
>
> There are some risks, as many multilingual sites have come to rely on the
> value in Accept-Language header and JS interfaces navigator.languages to
> send the right representation pages to the user.  Site breakage can take
> many forms, both obvious and non-obvious. However, since sites

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

> How would the OT work for the Accept-Language values of the very-first
request sent to the origin?
As described in the implementation doc
,
there are some limitations for the current OT architecture, we can't
validate the response OT token before we send the request.
For the very first request, we are still sending the full Accept-Language
user's list, after we validate the response, all subsequent requests start
to send a reduced Accept-Language header.

Bests,
Victor

On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss  wrote:

> How would the OT work for the Accept-Language values of the very-first
> request sent to the origin? Or are we expecting this request to send higher
> entropy, but not to hide potential breakage with later requests sending
> lower entropy?
>
> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan  wrote:
>
>> Contact emails
>>
>> victor...@chromium.org, miketa...@chromium.org
>>
>> Explainer
>>
>> https://github.com/Tanych/accept-language
>>
>> Specification
>>
>> Variants header:
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> We want to reduce the amount of information the Accept-Language header
>> exposes in HTTP requests and JS interface navigator.languages. Instead of
>> sending all user’s Accept-Language, we only send the user’s most preferred
>> language after language negotiation in the Accept-Language header.
>> navigator.languages returns the same value as navigator.language during
>> this experiment.
>>
>> We would like to run an origin trial for sites to opt into the Reduce
>> Accept-Language origin trial to proactively test for breakage. See below
>> for more details.
>>
>> Implementation Doc
>>
>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>
>> Blink component
>>
>> Privacy>Fingerprinting
>> 
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The compatibility risk is low since we're planning to reduce the amount
>> of information in the Accept-Language header and navigator.languages,
>> rather than remove the header or change value format in the header. Most
>> existing Accept-Language detection code should continue to work.
>>
>> As for interoperability, no signal for other vendors. For multilingual
>> sites to rely on the Accept-Language header, developers would need to
>> depend on a user's full Accept-Language list for some browsers and a
>> primary user's Accept-Language for others.
>>
>> Another signal is that the Chrome incognito model already reduced the
>> Accept-Language header and JS interface navigator.languages to one
>> language. The Accept-Language header can potentially expand to two if the
>> first Accept-Language includes a region code, like en-US, the reduced
>> Accept-Language  header will be en-US,en;q=0.9.
>>
>> Experiment Summary
>>
>> The experiment is going to be a little different from a normal Origin
>> Trial. The goal is enabling developers to test and ensure compatibility
>> with our proposed changes. It’s incredibly important we give developers any
>> chance to test systems at every level since this change represents vast
>> dependencies on the introduced headers.
>>
>> As for enabling with the origin trial itself, there will be two
>> components controlled by the same origin trial:
>>
>>-
>>
>>Reducing the information in navigator.languages if the origin trial
>>enabled.
>>-
>>
>>The Accept-Language HTTP request header contains the user’s primary
>>preferred language, this can change if we detect a more preferred language
>>during the language negotiation process.
>>
>> Because of the experimental nature of reducing Accept-Language, a valid
>> origin token must be sent in the response header by origins which opt-in
>> the origin trial. Also two new headers Variants
>> 
>> (indicating sites supporting languages) accept-language and
>> Content-Language  need to
>> be sent in the response header in order to make the language negotiation to
>> work correctly.
>>
>> Please see the design and implementation document
>> for
>> more information.
>>
>> Experiment Goals
>>
>> The goal of this origin trial is to enable developers to test how
>> reducing the Accept-Language request header and the JS getter
>> navigator.languages will affect their systems, especially to understand the
>> user cases on navigator.languages. We hope this can provide sufficient time
>> for developers to test. We can validate our current plans for reducing
>> Accept-Language and safely roll out them to the web based on their feedback.
>>
>> We 

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Yoav Weiss]

That's fair. What is the experiment's timeline?

On Mon, Oct 31, 2022 at 3:09 PM Victor Tan  wrote:

> > How would the OT work for the Accept-Language values of the very-first
> request sent to the origin?
> As described in the implementation doc
> ,
> there are some limitations for the current OT architecture, we can't
> validate the response OT token before we send the request.
> For the very first request, we are still sending the full Accept-Language
> user's list, after we validate the response, all subsequent requests start
> to send a reduced Accept-Language header.
>
> Bests,
> Victor
>
> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss  wrote:
>
>> How would the OT work for the Accept-Language values of the very-first
>> request sent to the origin? Or are we expecting this request to send higher
>> entropy, but not to hide potential breakage with later requests sending
>> lower entropy?
>>
>> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
>> wrote:
>>
>>> Contact emails
>>>
>>> victor...@chromium.org, miketa...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/Tanych/accept-language
>>>
>>> Specification
>>>
>>> Variants header:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>
>>> Summary
>>>
>>> We want to reduce the amount of information the Accept-Language header
>>> exposes in HTTP requests and JS interface navigator.languages. Instead of
>>> sending all user’s Accept-Language, we only send the user’s most preferred
>>> language after language negotiation in the Accept-Language header.
>>> navigator.languages returns the same value as navigator.language during
>>> this experiment.
>>>
>>> We would like to run an origin trial for sites to opt into the Reduce
>>> Accept-Language origin trial to proactively test for breakage. See below
>>> for more details.
>>>
>>> Implementation Doc
>>>
>>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>>
>>> Blink component
>>>
>>> Privacy>Fingerprinting
>>> 
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> The compatibility risk is low since we're planning to reduce the amount
>>> of information in the Accept-Language header and navigator.languages,
>>> rather than remove the header or change value format in the header. Most
>>> existing Accept-Language detection code should continue to work.
>>>
>>> As for interoperability, no signal for other vendors. For multilingual
>>> sites to rely on the Accept-Language header, developers would need to
>>> depend on a user's full Accept-Language list for some browsers and a
>>> primary user's Accept-Language for others.
>>>
>>> Another signal is that the Chrome incognito model already reduced the
>>> Accept-Language header and JS interface navigator.languages to one
>>> language. The Accept-Language header can potentially expand to two if the
>>> first Accept-Language includes a region code, like en-US, the reduced
>>> Accept-Language  header will be en-US,en;q=0.9.
>>>
>>> Experiment Summary
>>>
>>> The experiment is going to be a little different from a normal Origin
>>> Trial. The goal is enabling developers to test and ensure compatibility
>>> with our proposed changes. It’s incredibly important we give developers any
>>> chance to test systems at every level since this change represents vast
>>> dependencies on the introduced headers.
>>>
>>> As for enabling with the origin trial itself, there will be two
>>> components controlled by the same origin trial:
>>>
>>>-
>>>
>>>Reducing the information in navigator.languages if the origin trial
>>>enabled.
>>>-
>>>
>>>The Accept-Language HTTP request header contains the user’s primary
>>>preferred language, this can change if we detect a more preferred 
>>> language
>>>during the language negotiation process.
>>>
>>> Because of the experimental nature of reducing Accept-Language, a valid
>>> origin token must be sent in the response header by origins which opt-in
>>> the origin trial. Also two new headers Variants
>>> 
>>> (indicating sites supporting languages) accept-language and
>>> Content-Language  need
>>> to be sent in the response header in order to make the language negotiation
>>> to work correctly.
>>>
>>> Please see the design and implementation document
>>> for
>>> more information.
>>>
>>> Experiment Goals
>>>
>>> The goal of this origin trial is to enable developers to test how
>>> reducing the Accept-Language request header and the JS getter
>>> navigator.languages will affect their systems, especially to understand the
>>> u

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

We are expected to start in M109 Beta until 2023 Q2. We will document more
in the web blog post.

Bests,
Victor

On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss  wrote:

> That's fair. What is the experiment's timeline?
>
> On Mon, Oct 31, 2022 at 3:09 PM Victor Tan  wrote:
>
>> > How would the OT work for the Accept-Language values of the very-first
>> request sent to the origin?
>> As described in the implementation doc
>> ,
>> there are some limitations for the current OT architecture, we can't
>> validate the response OT token before we send the request.
>> For the very first request, we are still sending the full Accept-Language
>> user's list, after we validate the response, all subsequent requests start
>> to send a reduced Accept-Language header.
>>
>> Bests,
>> Victor
>>
>> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss 
>> wrote:
>>
>>> How would the OT work for the Accept-Language values of the very-first
>>> request sent to the origin? Or are we expecting this request to send higher
>>> entropy, but not to hide potential breakage with later requests sending
>>> lower entropy?
>>>
>>> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
>>> wrote:
>>>
 Contact emails

 victor...@chromium.org, miketa...@chromium.org

 Explainer

 https://github.com/Tanych/accept-language

 Specification

 Variants header:
 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06

 Summary

 We want to reduce the amount of information the Accept-Language header
 exposes in HTTP requests and JS interface navigator.languages. Instead of
 sending all user’s Accept-Language, we only send the user’s most preferred
 language after language negotiation in the Accept-Language header.
 navigator.languages returns the same value as navigator.language during
 this experiment.

 We would like to run an origin trial for sites to opt into the Reduce
 Accept-Language origin trial to proactively test for breakage. See below
 for more details.

 Implementation Doc

 https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY

 Blink component

 Privacy>Fingerprinting
 

 Risks

 Interoperability and Compatibility

 The compatibility risk is low since we're planning to reduce the amount
 of information in the Accept-Language header and navigator.languages,
 rather than remove the header or change value format in the header. Most
 existing Accept-Language detection code should continue to work.

 As for interoperability, no signal for other vendors. For multilingual
 sites to rely on the Accept-Language header, developers would need to
 depend on a user's full Accept-Language list for some browsers and a
 primary user's Accept-Language for others.

 Another signal is that the Chrome incognito model already reduced the
 Accept-Language header and JS interface navigator.languages to one
 language. The Accept-Language header can potentially expand to two if the
 first Accept-Language includes a region code, like en-US, the reduced
 Accept-Language  header will be en-US,en;q=0.9.

 Experiment Summary

 The experiment is going to be a little different from a normal Origin
 Trial. The goal is enabling developers to test and ensure compatibility
 with our proposed changes. It’s incredibly important we give developers any
 chance to test systems at every level since this change represents vast
 dependencies on the introduced headers.

 As for enabling with the origin trial itself, there will be two
 components controlled by the same origin trial:

-

Reducing the information in navigator.languages if the origin trial
enabled.
-

The Accept-Language HTTP request header contains the user’s primary
preferred language, this can change if we detect a more preferred 
 language
during the language negotiation process.

 Because of the experimental nature of reducing Accept-Language, a valid
 origin token must be sent in the response header by origins which opt-in
 the origin trial. Also two new headers Variants
 
 (indicating sites supporting languages) accept-language and
 Content-Language  need
 to be sent in the response header in order to make the language negotiation
 to work correctly.

 Please see the design and implementation document
 

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Yoav Weiss]

When do you expect the experiment to end?

On Mon, Oct 31, 2022 at 3:32 PM Victor Tan  wrote:

> We are expected to start in M109 Beta until 2023 Q2. We will document more
> in the web blog post.
>
> Bests,
> Victor
>
> On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss 
> wrote:
>
>> That's fair. What is the experiment's timeline?
>>
>> On Mon, Oct 31, 2022 at 3:09 PM Victor Tan 
>> wrote:
>>
>>> > How would the OT work for the Accept-Language values of the very-first
>>> request sent to the origin?
>>> As described in the implementation doc
>>> ,
>>> there are some limitations for the current OT architecture, we can't
>>> validate the response OT token before we send the request.
>>> For the very first request, we are still sending the full
>>> Accept-Language user's list, after we validate the response, all subsequent
>>> requests start to send a reduced Accept-Language header.
>>>
>>> Bests,
>>> Victor
>>>
>>> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss 
>>> wrote:
>>>
 How would the OT work for the Accept-Language values of the very-first
 request sent to the origin? Or are we expecting this request to send higher
 entropy, but not to hide potential breakage with later requests sending
 lower entropy?

 On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
 wrote:

> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org
>
> Explainer
>
> https://github.com/Tanych/accept-language
>
> Specification
>
> Variants header:
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>
> Summary
>
> We want to reduce the amount of information the Accept-Language header
> exposes in HTTP requests and JS interface navigator.languages. Instead of
> sending all user’s Accept-Language, we only send the user’s most preferred
> language after language negotiation in the Accept-Language header.
> navigator.languages returns the same value as navigator.language during
> this experiment.
>
> We would like to run an origin trial for sites to opt into the Reduce
> Accept-Language origin trial to proactively test for breakage. See below
> for more details.
>
> Implementation Doc
>
> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>
> Blink component
>
> Privacy>Fingerprinting
> 
>
> Risks
>
> Interoperability and Compatibility
>
> The compatibility risk is low since we're planning to reduce the
> amount of information in the Accept-Language header and
> navigator.languages, rather than remove the header or change value format
> in the header. Most existing Accept-Language detection code should 
> continue
> to work.
>
> As for interoperability, no signal for other vendors. For multilingual
> sites to rely on the Accept-Language header, developers would need to
> depend on a user's full Accept-Language list for some browsers and a
> primary user's Accept-Language for others.
>
> Another signal is that the Chrome incognito model already reduced the
> Accept-Language header and JS interface navigator.languages to one
> language. The Accept-Language header can potentially expand to two if the
> first Accept-Language includes a region code, like en-US, the reduced
> Accept-Language  header will be en-US,en;q=0.9.
>
> Experiment Summary
>
> The experiment is going to be a little different from a normal Origin
> Trial. The goal is enabling developers to test and ensure compatibility
> with our proposed changes. It’s incredibly important we give developers 
> any
> chance to test systems at every level since this change represents vast
> dependencies on the introduced headers.
>
> As for enabling with the origin trial itself, there will be two
> components controlled by the same origin trial:
>
>-
>
>Reducing the information in navigator.languages if the origin
>trial enabled.
>-
>
>The Accept-Language HTTP request header contains the user’s
>primary preferred language, this can change if we detect a more 
> preferred
>language during the language negotiation process.
>
> Because of the experimental nature of reducing Accept-Language, a
> valid origin token must be sent in the response header by origins which
> opt-in the origin trial. Also two new headers Variants
> 
> (indicating sites supporting languages) accept-language and
> Content-Language  need
> to be sent in the r

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

Sorry for the unclear end milestone, we would like to experiment from M109
to M115.

Bests,
Victor

On Mon, Oct 31, 2022 at 10:34 AM Yoav Weiss  wrote:

> When do you expect the experiment to end?
>
> On Mon, Oct 31, 2022 at 3:32 PM Victor Tan  wrote:
>
>> We are expected to start in M109 Beta until 2023 Q2. We will document
>> more in the web blog post.
>>
>> Bests,
>> Victor
>>
>> On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss 
>> wrote:
>>
>>> That's fair. What is the experiment's timeline?
>>>
>>> On Mon, Oct 31, 2022 at 3:09 PM Victor Tan 
>>> wrote:
>>>
 > How would the OT work for the Accept-Language values of the
 very-first request sent to the origin?
 As described in the implementation doc
 ,
 there are some limitations for the current OT architecture, we can't
 validate the response OT token before we send the request.
 For the very first request, we are still sending the full
 Accept-Language user's list, after we validate the response, all subsequent
 requests start to send a reduced Accept-Language header.

 Bests,
 Victor

 On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss 
 wrote:

> How would the OT work for the Accept-Language values of the very-first
> request sent to the origin? Or are we expecting this request to send 
> higher
> entropy, but not to hide potential breakage with later requests sending
> lower entropy?
>
> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
> wrote:
>
>> Contact emails
>>
>> victor...@chromium.org, miketa...@chromium.org
>>
>> Explainer
>>
>> https://github.com/Tanych/accept-language
>>
>> Specification
>>
>> Variants header:
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> We want to reduce the amount of information the Accept-Language
>> header exposes in HTTP requests and JS interface navigator.languages.
>> Instead of sending all user’s Accept-Language, we only send the user’s 
>> most
>> preferred language after language negotiation in the Accept-Language
>> header. navigator.languages returns the same value as navigator.language
>> during this experiment.
>>
>> We would like to run an origin trial for sites to opt into the Reduce
>> Accept-Language origin trial to proactively test for breakage. See below
>> for more details.
>>
>> Implementation Doc
>>
>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>
>> Blink component
>>
>> Privacy>Fingerprinting
>> 
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The compatibility risk is low since we're planning to reduce the
>> amount of information in the Accept-Language header and
>> navigator.languages, rather than remove the header or change value format
>> in the header. Most existing Accept-Language detection code should 
>> continue
>> to work.
>>
>> As for interoperability, no signal for other vendors. For
>> multilingual sites to rely on the Accept-Language header, developers 
>> would
>> need to depend on a user's full Accept-Language list for some browsers 
>> and
>> a primary user's Accept-Language for others.
>>
>> Another signal is that the Chrome incognito model already reduced the
>> Accept-Language header and JS interface navigator.languages to one
>> language. The Accept-Language header can potentially expand to two if the
>> first Accept-Language includes a region code, like en-US, the reduced
>> Accept-Language  header will be en-US,en;q=0.9.
>>
>> Experiment Summary
>>
>> The experiment is going to be a little different from a normal Origin
>> Trial. The goal is enabling developers to test and ensure compatibility
>> with our proposed changes. It’s incredibly important we give developers 
>> any
>> chance to test systems at every level since this change represents vast
>> dependencies on the introduced headers.
>>
>> As for enabling with the origin trial itself, there will be two
>> components controlled by the same origin trial:
>>
>>-
>>
>>Reducing the information in navigator.languages if the origin
>>trial enabled.
>>-
>>
>>The Accept-Language HTTP request header contains the user’s
>>primary preferred language, this can change if we detect a more 
>> preferred
>>language during the language negotiation process.
>>
>> Because of the experimental nature of reducing Accept-Language, a
>> valid origin token must be sent in the response header by origins which
>

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Yoav Weiss]

Even though this is not a typical OT, I don't think it should go beyond the
current policy of 6 milestone before showing significant progress towards
shipping.
Would M109 to M114 (inclusive) be enough?

On Mon, Oct 31, 2022 at 3:36 PM Victor Tan  wrote:

> Sorry for the unclear end milestone, we would like to experiment from M109
> to M115.
>
> Bests,
> Victor
>
> On Mon, Oct 31, 2022 at 10:34 AM Yoav Weiss 
> wrote:
>
>> When do you expect the experiment to end?
>>
>> On Mon, Oct 31, 2022 at 3:32 PM Victor Tan 
>> wrote:
>>
>>> We are expected to start in M109 Beta until 2023 Q2. We will document
>>> more in the web blog post.
>>>
>>> Bests,
>>> Victor
>>>
>>> On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss 
>>> wrote:
>>>
 That's fair. What is the experiment's timeline?

 On Mon, Oct 31, 2022 at 3:09 PM Victor Tan 
 wrote:

> > How would the OT work for the Accept-Language values of the
> very-first request sent to the origin?
> As described in the implementation doc
> ,
> there are some limitations for the current OT architecture, we can't
> validate the response OT token before we send the request.
> For the very first request, we are still sending the full
> Accept-Language user's list, after we validate the response, all 
> subsequent
> requests start to send a reduced Accept-Language header.
>
> Bests,
> Victor
>
> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss 
> wrote:
>
>> How would the OT work for the Accept-Language values of the
>> very-first request sent to the origin? Or are we expecting this request 
>> to
>> send higher entropy, but not to hide potential breakage with later 
>> requests
>> sending lower entropy?
>>
>> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
>> wrote:
>>
>>> Contact emails
>>>
>>> victor...@chromium.org, miketa...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/Tanych/accept-language
>>>
>>> Specification
>>>
>>> Variants header:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>
>>> Summary
>>>
>>> We want to reduce the amount of information the Accept-Language
>>> header exposes in HTTP requests and JS interface navigator.languages.
>>> Instead of sending all user’s Accept-Language, we only send the user’s 
>>> most
>>> preferred language after language negotiation in the Accept-Language
>>> header. navigator.languages returns the same value as navigator.language
>>> during this experiment.
>>>
>>> We would like to run an origin trial for sites to opt into the
>>> Reduce Accept-Language origin trial to proactively test for breakage. 
>>> See
>>> below for more details.
>>>
>>> Implementation Doc
>>>
>>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>>
>>> Blink component
>>>
>>> Privacy>Fingerprinting
>>> 
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> The compatibility risk is low since we're planning to reduce the
>>> amount of information in the Accept-Language header and
>>> navigator.languages, rather than remove the header or change value 
>>> format
>>> in the header. Most existing Accept-Language detection code should 
>>> continue
>>> to work.
>>>
>>> As for interoperability, no signal for other vendors. For
>>> multilingual sites to rely on the Accept-Language header, developers 
>>> would
>>> need to depend on a user's full Accept-Language list for some browsers 
>>> and
>>> a primary user's Accept-Language for others.
>>>
>>> Another signal is that the Chrome incognito model already reduced
>>> the Accept-Language header and JS interface navigator.languages to one
>>> language. The Accept-Language header can potentially expand to two if 
>>> the
>>> first Accept-Language includes a region code, like en-US, the reduced
>>> Accept-Language  header will be en-US,en;q=0.9.
>>>
>>> Experiment Summary
>>>
>>> The experiment is going to be a little different from a normal
>>> Origin Trial. The goal is enabling developers to test and ensure
>>> compatibility with our proposed changes. It’s incredibly important we 
>>> give
>>> developers any chance to test systems at every level since this change
>>> represents vast dependencies on the introduced headers.
>>>
>>> As for enabling with the origin trial itself, there will be two
>>> components controlled by the same origin trial:
>>>
>>>-
>>>
>>>Reducing the information in navigator.languages if the orig

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

Yeap, M109 to M104 inclusive is enough for this OT.

Bests,
Victor

On Mon, Oct 31, 2022 at 10:58 AM Yoav Weiss  wrote:

> Even though this is not a typical OT, I don't think it should go beyond
> the current policy of 6 milestone before showing significant progress
> towards shipping.
> Would M109 to M114 (inclusive) be enough?
>
> On Mon, Oct 31, 2022 at 3:36 PM Victor Tan  wrote:
>
>> Sorry for the unclear end milestone, we would like to experiment from
>> M109 to M115.
>>
>> Bests,
>> Victor
>>
>> On Mon, Oct 31, 2022 at 10:34 AM Yoav Weiss 
>> wrote:
>>
>>> When do you expect the experiment to end?
>>>
>>> On Mon, Oct 31, 2022 at 3:32 PM Victor Tan 
>>> wrote:
>>>
 We are expected to start in M109 Beta until 2023 Q2. We will document
 more in the web blog post.

 Bests,
 Victor

 On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss 
 wrote:

> That's fair. What is the experiment's timeline?
>
> On Mon, Oct 31, 2022 at 3:09 PM Victor Tan 
> wrote:
>
>> > How would the OT work for the Accept-Language values of the
>> very-first request sent to the origin?
>> As described in the implementation doc
>> ,
>> there are some limitations for the current OT architecture, we can't
>> validate the response OT token before we send the request.
>> For the very first request, we are still sending the full
>> Accept-Language user's list, after we validate the response, all 
>> subsequent
>> requests start to send a reduced Accept-Language header.
>>
>> Bests,
>> Victor
>>
>> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss 
>> wrote:
>>
>>> How would the OT work for the Accept-Language values of the
>>> very-first request sent to the origin? Or are we expecting this request 
>>> to
>>> send higher entropy, but not to hide potential breakage with later 
>>> requests
>>> sending lower entropy?
>>>
>>> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
>>> wrote:
>>>
 Contact emails

 victor...@chromium.org, miketa...@chromium.org

 Explainer

 https://github.com/Tanych/accept-language

 Specification

 Variants header:
 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06

 Summary

 We want to reduce the amount of information the Accept-Language
 header exposes in HTTP requests and JS interface navigator.languages.
 Instead of sending all user’s Accept-Language, we only send the user’s 
 most
 preferred language after language negotiation in the Accept-Language
 header. navigator.languages returns the same value as 
 navigator.language
 during this experiment.

 We would like to run an origin trial for sites to opt into the
 Reduce Accept-Language origin trial to proactively test for breakage. 
 See
 below for more details.

 Implementation Doc

 https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY

 Blink component

 Privacy>Fingerprinting
 

 Risks

 Interoperability and Compatibility

 The compatibility risk is low since we're planning to reduce the
 amount of information in the Accept-Language header and
 navigator.languages, rather than remove the header or change value 
 format
 in the header. Most existing Accept-Language detection code should 
 continue
 to work.

 As for interoperability, no signal for other vendors. For
 multilingual sites to rely on the Accept-Language header, developers 
 would
 need to depend on a user's full Accept-Language list for some browsers 
 and
 a primary user's Accept-Language for others.

 Another signal is that the Chrome incognito model already reduced
 the Accept-Language header and JS interface navigator.languages to one
 language. The Accept-Language header can potentially expand to two if 
 the
 first Accept-Language includes a region code, like en-US, the reduced
 Accept-Language  header will be en-US,en;q=0.9.

 Experiment Summary

 The experiment is going to be a little different from a normal
 Origin Trial. The goal is enabling developers to test and ensure
 compatibility with our proposed changes. It’s incredibly important we 
 give
 developers any chance to test systems at every level since this change
 represents vast depend

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Yoav Weiss]

LGTM to experiment M109-M114

On Mon, Oct 31, 2022 at 4:02 PM Victor Tan  wrote:

> Yeap, M109 to M104 inclusive is enough for this OT.
>
> Bests,
> Victor
>
> On Mon, Oct 31, 2022 at 10:58 AM Yoav Weiss 
> wrote:
>
>> Even though this is not a typical OT, I don't think it should go beyond
>> the current policy of 6 milestone before showing significant progress
>> towards shipping.
>> Would M109 to M114 (inclusive) be enough?
>>
>> On Mon, Oct 31, 2022 at 3:36 PM Victor Tan 
>> wrote:
>>
>>> Sorry for the unclear end milestone, we would like to experiment from
>>> M109 to M115.
>>>
>>> Bests,
>>> Victor
>>>
>>> On Mon, Oct 31, 2022 at 10:34 AM Yoav Weiss 
>>> wrote:
>>>
 When do you expect the experiment to end?

 On Mon, Oct 31, 2022 at 3:32 PM Victor Tan 
 wrote:

> We are expected to start in M109 Beta until 2023 Q2. We will document
> more in the web blog post.
>
> Bests,
> Victor
>
> On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss 
> wrote:
>
>> That's fair. What is the experiment's timeline?
>>
>> On Mon, Oct 31, 2022 at 3:09 PM Victor Tan 
>> wrote:
>>
>>> > How would the OT work for the Accept-Language values of the
>>> very-first request sent to the origin?
>>> As described in the implementation doc
>>> ,
>>> there are some limitations for the current OT architecture, we can't
>>> validate the response OT token before we send the request.
>>> For the very first request, we are still sending the full
>>> Accept-Language user's list, after we validate the response, all 
>>> subsequent
>>> requests start to send a reduced Accept-Language header.
>>>
>>> Bests,
>>> Victor
>>>
>>> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss 
>>> wrote:
>>>
 How would the OT work for the Accept-Language values of the
 very-first request sent to the origin? Or are we expecting this 
 request to
 send higher entropy, but not to hide potential breakage with later 
 requests
 sending lower entropy?

 On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
 wrote:

> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org
>
> Explainer
>
> https://github.com/Tanych/accept-language
>
> Specification
>
> Variants header:
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>
> Summary
>
> We want to reduce the amount of information the Accept-Language
> header exposes in HTTP requests and JS interface navigator.languages.
> Instead of sending all user’s Accept-Language, we only send the 
> user’s most
> preferred language after language negotiation in the Accept-Language
> header. navigator.languages returns the same value as 
> navigator.language
> during this experiment.
>
> We would like to run an origin trial for sites to opt into the
> Reduce Accept-Language origin trial to proactively test for breakage. 
> See
> below for more details.
>
> Implementation Doc
>
> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>
> Blink component
>
> Privacy>Fingerprinting
> 
>
> Risks
>
> Interoperability and Compatibility
>
> The compatibility risk is low since we're planning to reduce the
> amount of information in the Accept-Language header and
> navigator.languages, rather than remove the header or change value 
> format
> in the header. Most existing Accept-Language detection code should 
> continue
> to work.
>
> As for interoperability, no signal for other vendors. For
> multilingual sites to rely on the Accept-Language header, developers 
> would
> need to depend on a user's full Accept-Language list for some 
> browsers and
> a primary user's Accept-Language for others.
>
> Another signal is that the Chrome incognito model already reduced
> the Accept-Language header and JS interface navigator.languages to one
> language. The Accept-Language header can potentially expand to two if 
> the
> first Accept-Language includes a region code, like en-US, the reduced
> Accept-Language  header will be en-US,en;q=0.9.
>
> Experiment Summary
>
> The experiment is going to be a little different from a normal
> Origin Trial. The goal is enabling develop

Re: [blink-dev] Re: Intent to Ship: CSS Color Module Level 4 + color-mix()

[Steve Justice]

Thanks

On Mon, Oct 31, 2022, 5:51 AM Daniel Bratell  wrote:

> LGTM3 (note Rick's condition)
>
> /Daniel
> On 2022-10-28 18:37, Rick Byers wrote:
>
>
>
> On Thu, Oct 27, 2022 at 3:09 PM 'Aaron Krajeski' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> What will be the devtools experience without that support? Will it
>> somewhat work and treat the value as an opaque string, or will it be broken
>> because it's not recognized?
>>
>> The value becomes an opaque string, but the color picker does not appear.
>
>
> That seems reasonable enough to me to ship given Safari has already
> shipped and this is a focus of Interop 2022.  Glad to hear work is
> progressing on first class DevTools support.
>
> LGTM2 to ship when the WPT pass rate is at (or near) 100% as planned.
>
> On Thursday, October 27, 2022 at 1:08:50 PM UTC-4 Philip Jägenstedt wrote:
>>
>>> What will be the devtools experience without that support? Will it
>>> somewhat work and treat the value as an opaque string, or will it be broken
>>> because it's not recognized?
>>>
>>> On Thu, Oct 27, 2022 at 5:01 PM Aaron Krajeski 
>>> wrote:
>>>
 Will the new DevTools support ship at the same time as that feature?

 Mostly likely not, though the dev tools team is hard at work on
 features right now:

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

 Is there a tracking bug for that?

 Yup! crbug.com/1073895

 cc-ing Peter Müller for Dev Tools specific stuff.

>>> On Thursday, October 27, 2022 at 8:12:07 AM UTC-4 Philip Jägenstedt
 wrote:

>>> Will the new DevTools support ship at the same time as that feature? Is
> there a tracking bug for that?
>
> On Thu, Oct 27, 2022 at 7:09 AM Yoav Weiss 
> wrote:
>
>> LGTM1
>>
>> On Wed, Oct 26, 2022 at 7:01 PM Aaron Krajeski 
>> wrote:
>>
>>>
>>> I think these 2 TAG reviews are related to this:
>>> https://github.com/w3ctag/design-reviews/issues/488
>>> https://github.com/w3ctag/design-reviews/issues/526
>>>
>>> Commented on both threads! For lab() and lch() there was no obvious
>>> delta, so I just pointed them at the draft spec. For color-mix there 
>>> were
>>> some very small differences in input syntax, I highlighted these and
>>> pointed at the draft spec and tests.
>>> On Wednesday, October 26, 2022 at 12:00:58 PM UTC-4
>>> yoav...@chromium.org wrote:
>>>
 On Tuesday, October 25, 2022 at 5:03:26 PM UTC+2 Mike Taylor wrote:

> On 10/25/22 10:58 AM, 'Aaron Krajeski' via blink-dev wrote:
> > Gecko: Shipped/Shipping
> > (https://developer.mozilla.org/en-US/docs/Web/CSS/color_value)
> >
> > Is that the right link?
> >
> > Mozilla hasn't published anything specific on implementing CSS
> color 4
> > but their documentation now lists all of the functions defined
> within
> > it. That link has entries for lab, lch and interpolation, for
> example.
> > The new functions are implemented in Firefox Nightly and that
> browser
> > is currently passing most of the tests on interop:
>
> (Note that MDN documents many things that are not implemented in
> Firefox
> - it's not intended to be browser-specific).
>
> >
> https://wpt.fyi/results/css/css-color?label=experimental&label=master&aligned
> >
> >
> > On Tue, Oct 25, 2022 at 4:49 AM Yoav Weiss 
> wrote:
> >>
> >>
> >> On Thursday, October 20, 2022 at 4:51:07 PM UTC+2 Aaron
> Krajeski wrote:
> >>> Contact emails
> >>>
> >>> aar...@chromium.org, fs...@chromium.org, ccam...@chromium.org,
> fut...@chromium.org, juan...@chromium.org
> >>>
> >>>
> >>> Explainer
> >>>
> >>> https://developer.mozilla.org/en-US/docs/Web/CSS/color_value
> >>>
> >>>
> >>> Specification
> >>> https://www.w3.org/TR/css-color-4/
> >>> https://www.w3.org/TR/css-color-5/
> >>>
> >>> Summary
> >>>
> >>> Several new features are being added to CSS Colors from CSS
> Color Module Level 4:
> >>>
> >>> 1. New color types: lab, Oklab, lch, Oklch
> >>>
> >>> 2. color() function for specifying colors with predefined
> color spaces.
> >>>
> >>> 3. Ability to specify color spaces for animations and
> transitions.
> >>>
> >>> 4. Users can now specify color spaces for gradients.
> >>>
> >>> Additionally the color-mix() function is being added from CSS
> Color Module Level 5.
> >>>
> >>>
> >>> Blink component
> >>>
> >>> Blink>CSS
> >>>
> >>>
> >>> TAG r

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

['Ashley Gullen' via blink-dev]

Apologies for bringing back an old thread, but I thought it was important
to bring this up here.

I was surprised to read that Google are abandoning their efforts to
implement JPEG-XL:
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84

As I understood it, JPEG-XL brought significant improvements over existing
image formats, and had a lot of interest in the technology world. However
the reasons cited were apparently lack of benefits and lack of interest.

I for one was interested in this format and the improvements it would
bring, and it seems many others are disappointed too.  Can Google explain
how they came to this conclusion? How are they evaluating the benefits and
interest? Even this intent to prototype lists many of the purported
benefits and the extent of the interest, which makes this reversal
particularly hard to understand.




On Tue, 30 Mar 2021 at 20:20, 'Moritz Firsching' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
>
> *de...@chromium.org , firsch...@google.com
> , l...@google.com , jy...@google.com
> *Explainer
>
>
> *https://jpeg.org/jpegxl/
> http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf
> *Specification
>
>
> *https://arxiv.org/abs/1908.03565 *
> Summary
>
>
>
>
> *JPEG XL is a new royalty-free image codec targeting the image quality as
> found on the web, providing about ~60% size savings when compared to
> original JPEG at the same perceptual quality, while supporting modern
> features like HDR, animation, alpha channel, lossless JPEG recompression,
> lossless and progressive modes. It is based on Google's PIK and
> Cloudinary's FUIF, and is in the final steps of standardization with
> ISO.This feature enables image/jxl decoding support in the blink 
> renderer.*Blink
> component
>
>
> *Blink>Image
> *
> Motivation
>
>
>
>
> *The main motivations for supporting JPEG XL in Chrome are: - The
> improvement in image quality vs image size, about 60% file size savings for
> the same visual quality (lossy compression of larger originals) when
> compared to JPEG at the qualities found on the web.- Improved visual
> latency by both smaller download sizes and supporting progressive decoding
> modes. - Support for HDR, animation and progressive all together in the
> same image codec.  - Support for lossless-recompressed JPEGs - Ecosystem
> interest in JPEG XL: Several Google teams evaluated using JPEG XL for
> storing and delivering images, as well as outside of Google: including CDNs
> interest in storing lossless-recompressed JPEGs as JPEG XL and converting
> to JPEG on request is the browser doesn't support JXL. Facebook is
> exploring to use JPEG XL.*Initial public proposal
>
>
> *Support decoding image/jxl behind a feature flag which is turned off by
> default on all platforms. *Search tags
>
>
> *jxl *TAG review
>
>
> *Not applicable for image decoders*TAG review status
>
>
> *Not applicable*Risks
>
> Interoperability and Compatibility
>
>
>
>
>
>
> *JPEG XL is in the final stage ISO standardization. Firefox has an open
> bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
> Edge/Safari - no
> signals yetGecko: No signalWebKit: No signalWeb developers: high
> interest/many stars in the tracking bug, and there was a separate external
> crbug requesting the feature. A lot of interest on encode.su
> , r/jpegxl,  discord
> , ...*Is this feature
> fully tested by web-platform-tests
> 
> ?
>
>
> *No, but planning to have complete tests before shipping. *Tracking bug
>
>
> *https://bugs.chromium.org/p/chromium/issues/detail?id=1178058
> *Launch bug
>
>
> *https://bugs.chromium.org/p/chromium/issues/detail?id=1178040
> *Link to
> entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5188299478007808
>
> 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/CAMM7wxZEBJ8uf5OB%3DR1j2J6w5OF8OT1o%2B%2BN4t8G_brOo-Zgh_w%40mail.gmail.com
> 

[blink-dev] Re: Intent to Experiment: Reduce Accept-Language Origin Trial

[Brian Birtles]

Hi,

Where should developers give feedback about this proposal?

The changes to the Accept-Language header are ameliorated by the Variants 
header. Is there any such mechanism proposed for the changes to the JS 
interface?

Thanks,

Brian

2022年10月28日金曜日 2:57:18 UTC+9 vict...@chromium.org:

> Contact emails
>
> vict...@chromium.org, mike...@chromium.org 
>
> Explainer
>
> https://github.com/Tanych/accept-language
>
> Specification
>
> Variants header: 
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>
> Summary
>
> We want to reduce the amount of information the Accept-Language header 
> exposes in HTTP requests and JS interface navigator.languages. Instead of 
> sending all user’s Accept-Language, we only send the user’s most preferred 
> language after language negotiation in the Accept-Language header. 
> navigator.languages returns the same value as navigator.language during 
> this experiment. 
>
> We would like to run an origin trial for sites to opt into the Reduce 
> Accept-Language origin trial to proactively test for breakage. See below 
> for more details. 
>
> Implementation Doc
>
> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>
> Blink component
>
> Privacy>Fingerprinting 
> 
>
> Risks
>
> Interoperability and Compatibility
>
> The compatibility risk is low since we're planning to reduce the amount of 
> information in the Accept-Language header and navigator.languages, rather 
> than remove the header or change value format in the header. Most existing 
> Accept-Language detection code should continue to work. 
>
> As for interoperability, no signal for other vendors. For multilingual 
> sites to rely on the Accept-Language header, developers would need to 
> depend on a user's full Accept-Language list for some browsers and a 
> primary user's Accept-Language for others. 
>
> Another signal is that the Chrome incognito model already reduced the 
> Accept-Language header and JS interface navigator.languages to one 
> language. The Accept-Language header can potentially expand to two if the 
> first Accept-Language includes a region code, like en-US, the reduced 
> Accept-Language  header will be en-US,en;q=0.9. 
>
> Experiment Summary
>
> The experiment is going to be a little different from a normal Origin 
> Trial. The goal is enabling developers to test and ensure compatibility 
> with our proposed changes. It’s incredibly important we give developers any 
> chance to test systems at every level since this change represents vast 
> dependencies on the introduced headers. 
>
> As for enabling with the origin trial itself, there will be two components 
> controlled by the same origin trial:
>
>- 
>
>Reducing the information in navigator.languages if the origin trial 
>enabled.
>- 
>
>The Accept-Language HTTP request header contains the user’s primary 
>preferred language, this can change if we detect a more preferred language 
>during the language negotiation process. 
>
> Because of the experimental nature of reducing Accept-Language, a valid 
> origin token must be sent in the response header by origins which opt-in 
> the origin trial. Also two new headers Variants 
> 
>  
> (indicating sites supporting languages) accept-language and 
> Content-Language  need to 
> be sent in the response header in order to make the language negotiation to 
> work correctly.
>
> Please see the design and implementation document 
> for
>  
> more information. 
>
> Experiment Goals
>
> The goal of this origin trial is to enable developers to test how reducing 
> the Accept-Language request header and the JS getter navigator.languages 
> will affect their systems, especially to understand the user cases on 
> navigator.languages. We hope this can provide sufficient time for 
> developers to test. We can validate our current plans for reducing 
> Accept-Language and safely roll out them to the web based on their feedback.
>
> We will be relying heavily on user and developer feedback to identify 
> where breakage occurs,  or where use cases are not accounted for, 
> especially for multilingual sites depending on the Accept-Language header, 
> and navigator.languages.  We will create a GitHub repository and a public 
> mailing list for gathering feedback. When the origin trial is ready, we 
> plan to publish developer guidance on how to enroll and provide feedback.
>
> Experiment Risks
>
> There are some risks, as many multilingual sites have come to rely on the 
> value in Accept-Language header and JS interfaces navigator.languages to 
> send the right representation pages to the user.  Site brea