Re: [blink-dev] Intent to Experiment: Viewport-height client hint

[Yoav Weiss]

In that case, I'm inclined to say that the actual experimentation started
in M100.
Regardless, extending the experimentation till M104 LGTM.

On Thu, Apr 7, 2022 at 10:52 PM Max Curran  wrote:

> We are running a coordinated experiment with Search. The Chrome side was
> started in M99, but they were only able to start their side of the
> experiment this week. Other than Search, no other partners have signed up.
>
> On Thu, Apr 7, 2022 at 2:18 AM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, Apr 6, 2022 at 11:25 PM 'Max Curran' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> curran...@chromium.org, ryanst...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md
>>>
>>> Specification
>>>
>>>
>>> https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height
>>>
>>> Summary
>>>
>>> Currently, Responsive Image Client Hints provide a way for origins to
>>> obtain the viewport’s width. However, no such attribute exists for viewport
>>> height. We’ve observed that to optimize the loading of content that appears
>>> in viewport, it is essential for the origins to adapt HTML response based
>>> on viewport height.
>>>
>>>
>>> Blink component
>>>
>>> Blink>Loader
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/615
>>>
>>> TAG review status
>>>
>>> Issues addressed
>>>
>>> Link to origin trial feedback summary
>>>
>>> https://github.com/WICG/responsive-image-client-hints/issues
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/79)
>>>
>>> WebKit: Negative (
>>> https://lists.webkit.org/pipermail/webkit-dev/2020-November/031576.html)
>>> Likely to be neutral based on discussion in
>>> https://github.com/mozilla/standards-positions/issues/79
>>>
>>> Web developers: No signals
>>>
>>> Other signals:
>>>
>>> Activation
>>>
>>> None
>>>
>>>
>>> WebView Application Risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>>
>>> Goals for experimentation
>>>
>>> Client hints opt-ins from origins are session-sticky which makes it
>>> difficult to experiment with using origin trials since origin trials
>>> operate at document-level. We plan to run an A/B experiment using Chrome’s
>>> field trial infrastructure. Our plan is to enable the feature for at most
>>> 1% users to collect metrics, and ship this feature only if it shows
>>> performance improvement for origins that choose to use this feature.
>>>
>>>
>>> Reason this experiment is being extended
>>>
>>> Due to Chrome approvals taking longer than expected, and partners still
>>> needing to implement how to use the client hint, we have not been able to
>>> experiment yet. We would like to extend the origin trial from M101 to M104.
>>>
>>
>> Has the experiment started in the M99 timeframe? Or are you planning to
>> start it later? Have any partners signed up?
>>
>>
>>> Ongoing technical constraints
>>>
>>> Debuggability
>>>
>>> N/A
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> Flag name
>>>
>>> kViewportHeightClientHintHeader
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1184863
>>>
>>> Launch bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1184862
>>>
>>> Estimated milestones
>>>
>>> OriginTrial desktop last
>>>
>>> 101 → 104
>>>
>>> OriginTrial desktop first
>>>
>>> 99
>>>
>>> OriginTrial android last
>>>
>>> 101 → 104
>>>
>>> OriginTrial android first
>>>
>>> 99
>>>
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5646861215989760
>>>
>>> Links to previous Intent discussions
>>>
>>> Intent to Experiment:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/Q2wcqY2UyNs/m/rPePdX_NBwAJ
>>>
>>>
>>> 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/CA%2BEneNNpr4CxoeqmHxgyTK3shuoN3f5T6hpfzkoT-zY2wR1SgA%40mail.gmail.com
>>> 

Re: [blink-dev] Intent to Experiment: Viewport-height client hint

['Max Curran' via blink-dev]

We are running a coordinated experiment with Search. The Chrome side was
started in M99, but they were only able to start their side of the
experiment this week. Other than Search, no other partners have signed up.

On Thu, Apr 7, 2022 at 2:18 AM Yoav Weiss  wrote:

>
>
> On Wed, Apr 6, 2022 at 11:25 PM 'Max Curran' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> curran...@chromium.org, ryanst...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md
>>
>> Specification
>>
>>
>> https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height
>>
>> Summary
>>
>> Currently, Responsive Image Client Hints provide a way for origins to
>> obtain the viewport’s width. However, no such attribute exists for viewport
>> height. We’ve observed that to optimize the loading of content that appears
>> in viewport, it is essential for the origins to adapt HTML response based
>> on viewport height.
>>
>>
>> Blink component
>>
>> Blink>Loader
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/615
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Link to origin trial feedback summary
>>
>> https://github.com/WICG/responsive-image-client-hints/issues
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/79)
>>
>> WebKit: Negative (
>> https://lists.webkit.org/pipermail/webkit-dev/2020-November/031576.html)
>> Likely to be neutral based on discussion in
>> https://github.com/mozilla/standards-positions/issues/79
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>> Activation
>>
>> None
>>
>>
>> WebView Application Risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>> Goals for experimentation
>>
>> Client hints opt-ins from origins are session-sticky which makes it
>> difficult to experiment with using origin trials since origin trials
>> operate at document-level. We plan to run an A/B experiment using Chrome’s
>> field trial infrastructure. Our plan is to enable the feature for at most
>> 1% users to collect metrics, and ship this feature only if it shows
>> performance improvement for origins that choose to use this feature.
>>
>>
>> Reason this experiment is being extended
>>
>> Due to Chrome approvals taking longer than expected, and partners still
>> needing to implement how to use the client hint, we have not been able to
>> experiment yet. We would like to extend the origin trial from M101 to M104.
>>
>
> Has the experiment started in the M99 timeframe? Or are you planning to
> start it later? Have any partners signed up?
>
>
>> Ongoing technical constraints
>>
>> Debuggability
>>
>> N/A
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>> Flag name
>>
>> kViewportHeightClientHintHeader
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1184863
>>
>> Launch bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1184862
>>
>> Estimated milestones
>>
>> OriginTrial desktop last
>>
>> 101 → 104
>>
>> OriginTrial desktop first
>>
>> 99
>>
>> OriginTrial android last
>>
>> 101 → 104
>>
>> OriginTrial android first
>>
>> 99
>>
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5646861215989760
>>
>> Links to previous Intent discussions
>>
>> Intent to Experiment:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/Q2wcqY2UyNs/m/rPePdX_NBwAJ
>>
>>
>> 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/CA%2BEneNNpr4CxoeqmHxgyTK3shuoN3f5T6hpfzkoT-zY2wR1SgA%40mail.gmail.com
>> 
>> .
>>
>

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

Re: [blink-dev] Intent to Experiment: Viewport-height client hint

[Yoav Weiss]

On Wed, Apr 6, 2022 at 11:25 PM 'Max Curran' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> curran...@chromium.org, ryanst...@chromium.org
>
> Explainer
>
>
> https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md
>
> Specification
>
>
> https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height
>
> Summary
>
> Currently, Responsive Image Client Hints provide a way for origins to
> obtain the viewport’s width. However, no such attribute exists for viewport
> height. We’ve observed that to optimize the loading of content that appears
> in viewport, it is essential for the origins to adapt HTML response based
> on viewport height.
>
>
> Blink component
>
> Blink>Loader
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/615
>
> TAG review status
>
> Issues addressed
>
> Link to origin trial feedback summary
>
> https://github.com/WICG/responsive-image-client-hints/issues
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: No signal (https://github.com/mozilla/standards-positions/issues/79
> )
>
> WebKit: Negative (
> https://lists.webkit.org/pipermail/webkit-dev/2020-November/031576.html)
> Likely to be neutral based on discussion in
> https://github.com/mozilla/standards-positions/issues/79
>
> Web developers: No signals
>
> Other signals:
>
> Activation
>
> None
>
>
> WebView Application Risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
> Goals for experimentation
>
> Client hints opt-ins from origins are session-sticky which makes it
> difficult to experiment with using origin trials since origin trials
> operate at document-level. We plan to run an A/B experiment using Chrome’s
> field trial infrastructure. Our plan is to enable the feature for at most
> 1% users to collect metrics, and ship this feature only if it shows
> performance improvement for origins that choose to use this feature.
>
>
> Reason this experiment is being extended
>
> Due to Chrome approvals taking longer than expected, and partners still
> needing to implement how to use the client hint, we have not been able to
> experiment yet. We would like to extend the origin trial from M101 to M104.
>

Has the experiment started in the M99 timeframe? Or are you planning to
start it later? Have any partners signed up?


> Ongoing technical constraints
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
> Flag name
>
> kViewportHeightClientHintHeader
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1184863
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1184862
>
> Estimated milestones
>
> OriginTrial desktop last
>
> 101 → 104
>
> OriginTrial desktop first
>
> 99
>
> OriginTrial android last
>
> 101 → 104
>
> OriginTrial android first
>
> 99
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5646861215989760
>
> Links to previous Intent discussions
>
> Intent to Experiment:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/Q2wcqY2UyNs/m/rPePdX_NBwAJ
>
>
> 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/CA%2BEneNNpr4CxoeqmHxgyTK3shuoN3f5T6hpfzkoT-zY2wR1SgA%40mail.gmail.com
> 
> .
>

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

[blink-dev] Intent to Experiment: Viewport-height client hint

['Max Curran' via blink-dev]

Contact emails

curran...@chromium.org, ryanst...@chromium.org

Explainer

https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md

Specification

https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height

Summary

Currently, Responsive Image Client Hints provide a way for origins to
obtain the viewport’s width. However, no such attribute exists for viewport
height. We’ve observed that to optimize the loading of content that appears
in viewport, it is essential for the origins to adapt HTML response based
on viewport height.


Blink component

Blink>Loader


TAG review

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

TAG review status

Issues addressed

Link to origin trial feedback summary

https://github.com/WICG/responsive-image-client-hints/issues

Risks

Interoperability and Compatibility

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

WebKit: Negative (
https://lists.webkit.org/pipermail/webkit-dev/2020-November/031576.html)
Likely to be neutral based on discussion in
https://github.com/mozilla/standards-positions/issues/79

Web developers: No signals

Other signals:

Activation

None


WebView Application Risks

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


Goals for experimentation

Client hints opt-ins from origins are session-sticky which makes it
difficult to experiment with using origin trials since origin trials
operate at document-level. We plan to run an A/B experiment using Chrome’s
field trial infrastructure. Our plan is to enable the feature for at most
1% users to collect metrics, and ship this feature only if it shows
performance improvement for origins that choose to use this feature.


Reason this experiment is being extended

Due to Chrome approvals taking longer than expected, and partners still
needing to implement how to use the client hint, we have not been able to
experiment yet. We would like to extend the origin trial from M101 to M104.

Ongoing technical constraints

Debuggability

N/A


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

Yes

Is this feature fully tested by web-platform-tests

?

Yes

Flag name

kViewportHeightClientHintHeader

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Estimated milestones

OriginTrial desktop last

101 → 104

OriginTrial desktop first

99

OriginTrial android last

101 → 104

OriginTrial android first

99



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5646861215989760

Links to previous Intent discussions

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


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/CA%2BEneNNpr4CxoeqmHxgyTK3shuoN3f5T6hpfzkoT-zY2wR1SgA%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Viewport-height client hint

[Yoav Weiss]

Thanks for the update! Still LGTM!

On Sat, Feb 5, 2022 at 12:02 AM Max Curran  wrote:

> We weren’t ready to start the experiments till now, and we are now
> planning on running experiments on M99-M101.
>
> On Tuesday, August 24, 2021 at 2:41:25 AM UTC-7 yoav...@chromium.org
> wrote:
>
>> Thanks for updating the thread! :)
>>
>> On Mon, Aug 23, 2021 at 10:01 PM 'Max Curran' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> This feature has slipped to M95.
>>>
>>> On Monday, August 2, 2021 at 8:21:55 AM UTC-7 Max Curran wrote:
>>>
 Quick update: The experiment for the viewport-height client hint are
 not active in M91-M93. The feature should be code complete in M94, and we
 plan on start experimenting in that milestone.

 On Thursday, March 11, 2021 at 2:12:32 PM UTC-8 Chris Harrelson wrote:

> Great!
>
> LGTM to experiment on M91 on canary/dev/beta.
>
> On Thu, Mar 11, 2021 at 2:03 PM Tarun Bansal 
> wrote:
>
>> I think we should be able to get sufficient data on Canary/Dev/Beta
>> channels, but it's harder to predict for sure. The option to run first on
>> Canary/Dev/Beta channels and ping back this thread seems reasonable to 
>> me.
>>
>> On Thursday, March 11, 2021 at 2:00:27 PM UTC-8 Chris Harrelson wrote:
>>
> On Thu, Mar 11, 2021 at 1:36 PM Tarun Bansal 
>>> wrote:
>>>
 Thanks Chris. Answers inline:

 > - Can you add a milestone range you'd like to experiment on? e.g.
 M91-M93?

 We're hoping to start the experiment in M-91 (I updated this on
 chromestatus as well).

 > - You're suggesting an A/B experiment rather than an Origin
 Trial, since Origin Trials don't work at the networking layer; this 
 makes
 sense. But since it's an A/B experiment, these headers will be exposed 
 to
 all sites in the A group. For this reason, would it suffice to test on 
 the
 Canary/Dev/Beta channels?

 The developers would need to opt-in to get those headers, and yes,
 it would be possible for developers to opt-in, and get the headers 
 from the
 users in group A. However, given the small size of group A, the opt-in
 would succeed only <5% time on stable channel. I would hope developers
 would not rely on it as long as we keep group A size small.

>>>
>>> I agree that the risk is small, but even still it's better not to
>>> experiment with new APIs on the stable channel when possible. Do you 
>>> think
>>> the audience sizes on other channels will be large enough to get a
>>> statistically significant result?
>>>
>>> Another option could be to run first on those channels, and if the
>>> results are not conclusive enough, ping this thread to request stable
>>> channel experimentation.
>>>
>>> On Thursday, March 11, 2021 at 1:13:13 PM UTC-8 Chris Harrelson
 wrote:

>>> Hi,
>
> I have two questions:
>
> - Can you add a milestone range you'd like to experiment on? e.g.
> M91-M93?
>
> - You're suggesting an A/B experiment rather than an Origin Trial,
> since Origin Trials don't work at the networking layer; this makes 
> sense.
> But since it's an A/B experiment, these headers will be exposed to all
> sites in the A group. For this reason, would it suffice to test on the
> Canary/Dev/Beta channels?
>
>
>
>
>
>
> On Thu, Mar 4, 2021 at 2:46 PM Tarun Bansal 
> wrote:
>
>> Intent to Experiment: Viewport-height client hint
>> Contact emails
>>
>> tba...@chromium.org, yoav...@chromium.org, loadi...@chromium.org
>>
>>
>> Explainer
>>
>>
>> https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md
>>
>>
>> Specification
>>
>> The new client hint attribute “viewport-height” (similar to
>> existing viewport-width) would provide a way for origins to
>> obtain the viewport’s height. Similar to other client hints, origins 
>> would
>> be able to register the opt-in for viewport-height client-hint via
>> Accept-CH header, and receive the attribute value as part of
>> HTTP request headers.
>>
>> Spec:
>> https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height
>>
>> Summary/Motivation
>>
>> Currently, Responsive Image Client Hints
>>  provide
>> a way for origins to obtain the viewport’s width. However, no such
>> attribute exists for viewport height. We’ve observed t

Re: [blink-dev] Intent to Experiment: Viewport-height client hint

['Max Curran' via blink-dev]

We weren’t ready to start the experiments till now, and we are now planning 
on running experiments on M99-M101.

On Tuesday, August 24, 2021 at 2:41:25 AM UTC-7 yoav...@chromium.org wrote:

> Thanks for updating the thread! :)
>
> On Mon, Aug 23, 2021 at 10:01 PM 'Max Curran' via blink-dev <
> blin...@chromium.org> wrote:
>
>> This feature has slipped to M95.
>>
>> On Monday, August 2, 2021 at 8:21:55 AM UTC-7 Max Curran wrote:
>>
>>> Quick update: The experiment for the viewport-height client hint are not 
>>> active in M91-M93. The feature should be code complete in M94, and we plan 
>>> on start experimenting in that milestone.
>>>
>>> On Thursday, March 11, 2021 at 2:12:32 PM UTC-8 Chris Harrelson wrote:
>>>
 Great!

 LGTM to experiment on M91 on canary/dev/beta.

 On Thu, Mar 11, 2021 at 2:03 PM Tarun Bansal  
 wrote:

> I think we should be able to get sufficient data on Canary/Dev/Beta 
> channels, but it's harder to predict for sure. The option to run first on 
> Canary/Dev/Beta channels and ping back this thread seems reasonable to 
> me. 
>
> On Thursday, March 11, 2021 at 2:00:27 PM UTC-8 Chris Harrelson wrote:
>
 On Thu, Mar 11, 2021 at 1:36 PM Tarun Bansal  
>> wrote:
>>
>>> Thanks Chris. Answers inline:
>>>
>>> > - Can you add a milestone range you'd like to experiment on? e.g. 
>>> M91-M93?
>>>
>>> We're hoping to start the experiment in M-91 (I updated this on 
>>> chromestatus as well).
>>>
>>> > - You're suggesting an A/B experiment rather than an Origin Trial, 
>>> since Origin Trials don't work at the networking layer; this makes 
>>> sense. 
>>> But since it's an A/B experiment, these headers will be exposed to all 
>>> sites in the A group. For this reason, would it suffice to test on the 
>>> Canary/Dev/Beta channels?
>>>
>>> The developers would need to opt-in to get those headers, and yes, 
>>> it would be possible for developers to opt-in, and get the headers from 
>>> the 
>>> users in group A. However, given the small size of group A, the opt-in 
>>> would succeed only <5% time on stable channel. I would hope developers 
>>> would not rely on it as long as we keep group A size small. 
>>>
>>
>> I agree that the risk is small, but even still it's better not to 
>> experiment with new APIs on the stable channel when possible. Do you 
>> think 
>> the audience sizes on other channels will be large enough to get a 
>> statistically significant result?
>>
>> Another option could be to run first on those channels, and if the 
>> results are not conclusive enough, ping this thread to request stable 
>> channel experimentation.
>>
>> On Thursday, March 11, 2021 at 1:13:13 PM UTC-8 Chris Harrelson wrote:
>>>
>> Hi,

 I have two questions:

 - Can you add a milestone range you'd like to experiment on? e.g. 
 M91-M93?

 - You're suggesting an A/B experiment rather than an Origin Trial, 
 since Origin Trials don't work at the networking layer; this makes 
 sense. 
 But since it's an A/B experiment, these headers will be exposed to all 
 sites in the A group. For this reason, would it suffice to test on the 
 Canary/Dev/Beta channels?



  


 On Thu, Mar 4, 2021 at 2:46 PM Tarun Bansal  
 wrote:

> Intent to Experiment: Viewport-height client hint
> Contact emails
>
> tba...@chromium.org, yoav...@chromium.org, loadi...@chromium.org  
>
> Explainer
>
>
> https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md
>
>
> Specification
>
> The new client hint attribute “viewport-height” (similar to 
> existing viewport-width) would provide a way for origins to 
> obtain the viewport’s height. Similar to other client hints, origins 
> would 
> be able to register the opt-in for viewport-height client-hint via 
> Accept-CH header, and receive the attribute value as part of HTTP 
> request headers.
>
> Spec: 
> https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height
>
> Summary/Motivation
>
> Currently, Responsive Image Client Hints 
>  provide a 
> way for origins to obtain the viewport’s width. However, no such 
> attribute 
> exists for viewport height. We’ve observed that to optimize the 
> loading of 
> content that appears in viewport, it is essential for the origins to 
> adapt 
> HTML response based on viewport height. Current metho

Re: [blink-dev] Intent to Experiment: Viewport-height client hint

[Yoav Weiss]

Thanks for updating the thread! :)

On Mon, Aug 23, 2021 at 10:01 PM 'Max Curran' via blink-dev <
blink-dev@chromium.org> wrote:

> This feature has slipped to M95.
>
> On Monday, August 2, 2021 at 8:21:55 AM UTC-7 Max Curran wrote:
>
>> Quick update: The experiment for the viewport-height client hint are not
>> active in M91-M93. The feature should be code complete in M94, and we plan
>> on start experimenting in that milestone.
>>
>> On Thursday, March 11, 2021 at 2:12:32 PM UTC-8 Chris Harrelson wrote:
>>
>>> Great!
>>>
>>> LGTM to experiment on M91 on canary/dev/beta.
>>>
>>> On Thu, Mar 11, 2021 at 2:03 PM Tarun Bansal 
>>> wrote:
>>>
 I think we should be able to get sufficient data on Canary/Dev/Beta
 channels, but it's harder to predict for sure. The option to run first on
 Canary/Dev/Beta channels and ping back this thread seems reasonable to me.

 On Thursday, March 11, 2021 at 2:00:27 PM UTC-8 Chris Harrelson wrote:

>>> On Thu, Mar 11, 2021 at 1:36 PM Tarun Bansal 
> wrote:
>
>> Thanks Chris. Answers inline:
>>
>> > - Can you add a milestone range you'd like to experiment on? e.g.
>> M91-M93?
>>
>> We're hoping to start the experiment in M-91 (I updated this on
>> chromestatus as well).
>>
>> > - You're suggesting an A/B experiment rather than an Origin Trial,
>> since Origin Trials don't work at the networking layer; this makes sense.
>> But since it's an A/B experiment, these headers will be exposed to all
>> sites in the A group. For this reason, would it suffice to test on the
>> Canary/Dev/Beta channels?
>>
>> The developers would need to opt-in to get those headers, and yes, it
>> would be possible for developers to opt-in, and get the headers from the
>> users in group A. However, given the small size of group A, the opt-in
>> would succeed only <5% time on stable channel. I would hope developers
>> would not rely on it as long as we keep group A size small.
>>
>
> I agree that the risk is small, but even still it's better not to
> experiment with new APIs on the stable channel when possible. Do you think
> the audience sizes on other channels will be large enough to get a
> statistically significant result?
>
> Another option could be to run first on those channels, and if the
> results are not conclusive enough, ping this thread to request stable
> channel experimentation.
>
> On Thursday, March 11, 2021 at 1:13:13 PM UTC-8 Chris Harrelson wrote:
>>
> Hi,
>>>
>>> I have two questions:
>>>
>>> - Can you add a milestone range you'd like to experiment on? e.g.
>>> M91-M93?
>>>
>>> - You're suggesting an A/B experiment rather than an Origin Trial,
>>> since Origin Trials don't work at the networking layer; this makes 
>>> sense.
>>> But since it's an A/B experiment, these headers will be exposed to all
>>> sites in the A group. For this reason, would it suffice to test on the
>>> Canary/Dev/Beta channels?
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 4, 2021 at 2:46 PM Tarun Bansal 
>>> wrote:
>>>
 Intent to Experiment: Viewport-height client hint
 Contact emails

 tba...@chromium.org, yoav...@chromium.org, loadi...@chromium.org

 Explainer


 https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md


 Specification

 The new client hint attribute “viewport-height” (similar to
 existing viewport-width) would provide a way for origins to obtain
 the viewport’s height. Similar to other client hints, origins would be 
 able
 to register the opt-in for viewport-height client-hint via
 Accept-CH header, and receive the attribute value as part of HTTP
 request headers.

 Spec:
 https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height

 Summary/Motivation

 Currently, Responsive Image Client Hints
  provide a
 way for origins to obtain the viewport’s width. However, no such 
 attribute
 exists for viewport height. We’ve observed that to optimize the 
 loading of
 content that appears in viewport, it is essential for the origins to 
 adapt
 HTML response based on viewport height. Current methods of doing that
 include content-negotiation through the User-Agent string, but that is
 suboptimal as it’s indirect, and doesn’t cover all platforms.

 The new attribute “viewport-height” would enable origins to e.g.,
 inline all the content that’s expected to appear in the viewport, or 
 avoid
 lazy-loading it. That’s particular

Re: [blink-dev] Intent to Experiment: Viewport-height client hint

['Max Curran' via blink-dev]

This feature has slipped to M95.

On Monday, August 2, 2021 at 8:21:55 AM UTC-7 Max Curran wrote:

> Quick update: The experiment for the viewport-height client hint are not 
> active in M91-M93. The feature should be code complete in M94, and we plan 
> on start experimenting in that milestone.
>
> On Thursday, March 11, 2021 at 2:12:32 PM UTC-8 Chris Harrelson wrote:
>
>> Great!
>>
>> LGTM to experiment on M91 on canary/dev/beta.
>>
>> On Thu, Mar 11, 2021 at 2:03 PM Tarun Bansal  wrote:
>>
>>> I think we should be able to get sufficient data on Canary/Dev/Beta 
>>> channels, but it's harder to predict for sure. The option to run first on 
>>> Canary/Dev/Beta channels and ping back this thread seems reasonable to me. 
>>>
>>> On Thursday, March 11, 2021 at 2:00:27 PM UTC-8 Chris Harrelson wrote:
>>>
>> On Thu, Mar 11, 2021 at 1:36 PM Tarun Bansal  wrote:

> Thanks Chris. Answers inline:
>
> > - Can you add a milestone range you'd like to experiment on? e.g. 
> M91-M93?
>
> We're hoping to start the experiment in M-91 (I updated this on 
> chromestatus as well).
>
> > - You're suggesting an A/B experiment rather than an Origin Trial, 
> since Origin Trials don't work at the networking layer; this makes sense. 
> But since it's an A/B experiment, these headers will be exposed to all 
> sites in the A group. For this reason, would it suffice to test on the 
> Canary/Dev/Beta channels?
>
> The developers would need to opt-in to get those headers, and yes, it 
> would be possible for developers to opt-in, and get the headers from the 
> users in group A. However, given the small size of group A, the opt-in 
> would succeed only <5% time on stable channel. I would hope developers 
> would not rely on it as long as we keep group A size small. 
>

 I agree that the risk is small, but even still it's better not to 
 experiment with new APIs on the stable channel when possible. Do you think 
 the audience sizes on other channels will be large enough to get a 
 statistically significant result?

 Another option could be to run first on those channels, and if the 
 results are not conclusive enough, ping this thread to request stable 
 channel experimentation.

 On Thursday, March 11, 2021 at 1:13:13 PM UTC-8 Chris Harrelson wrote:
>
 Hi,
>>
>> I have two questions:
>>
>> - Can you add a milestone range you'd like to experiment on? e.g. 
>> M91-M93?
>>
>> - You're suggesting an A/B experiment rather than an Origin Trial, 
>> since Origin Trials don't work at the networking layer; this makes 
>> sense. 
>> But since it's an A/B experiment, these headers will be exposed to all 
>> sites in the A group. For this reason, would it suffice to test on the 
>> Canary/Dev/Beta channels?
>>
>>
>>
>>  
>>
>>
>> On Thu, Mar 4, 2021 at 2:46 PM Tarun Bansal  
>> wrote:
>>
>>> Intent to Experiment: Viewport-height client hint
>>> Contact emails
>>>
>>> tba...@chromium.org, yoav...@chromium.org, loadi...@chromium.org  
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md
>>>
>>>
>>> Specification
>>>
>>> The new client hint attribute “viewport-height” (similar to existing 
>>> viewport-width) would provide a way for origins to obtain the 
>>> viewport’s height. Similar to other client hints, origins would be able 
>>> to 
>>> register the opt-in for viewport-height client-hint via Accept-CH 
>>> header, and receive the attribute value as part of HTTP request headers.
>>>
>>> Spec: 
>>> https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height
>>>
>>> Summary/Motivation
>>>
>>> Currently, Responsive Image Client Hints 
>>>  provide a 
>>> way for origins to obtain the viewport’s width. However, no such 
>>> attribute 
>>> exists for viewport height. We’ve observed that to optimize the loading 
>>> of 
>>> content that appears in viewport, it is essential for the origins to 
>>> adapt 
>>> HTML response based on viewport height. Current methods of doing that 
>>> include content-negotiation through the User-Agent string, but that is 
>>> suboptimal as it’s indirect, and doesn’t cover all platforms.
>>>
>>> The new attribute “viewport-height” would enable origins to e.g., 
>>> inline all the content that’s expected to appear in the viewport, or 
>>> avoid 
>>> lazy-loading it. That’s particularly important when it comes to image 
>>> content.
>>>
>>> Even if the above mechanism is an optimization, using Client Hints 
>>> would enable to benefit from Client Hints Reliability 
>>>