Incomplete information for Accept-CH page

[summercms]

Related to this location: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH

This page is missing a huge amount of data, it seems to only cover:

• DPR
• Viewport Width
• Width

Yet Client Hints cover a lot more, such as:

• Device Memory
• Rtt
• Downlink
• Ect
• Save-Data
  etc.

I would like to see the MDN team update the information on the page to add these extra Client Hints and also update the Browser compatibility table.

Thanks.

[hamishwillee]

The page doesn't attempt to document everything - it links to the Client Hints glossary item where you are supposed to get information about all the headers it might work with.

I think the approach is right, but it should instead link to the list of supported headers at HTTP/Headers#client_hints.

The current list of headers on that page is: Accept-CH, Accept-CH-Lifetime ,Early-Data, Device-Memory, Save-Data, Viewport-Width, Width

So it is missing DPR and Downlink.

@ayumi-cloud What other ones do you know about?

• I can't see any more in https://tools.ietf.org/html/draft-grigorik-http-client-hints-03
• I can't see any info about RTT

Once we have a list we can update that page, and also look at the BCD for ACCEPT_CH

[summercms]

@hamishwillee

What other ones do you know about?

See here: https://wicg.github.io/client-hints-infrastructure/#find-client-hint-value-section

There is also Lang Client Hint which has been deprecated, not sure if you want to also mention that in MDN?

I can't see any info about RTT

Use this info: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/client-hints#rtt

I find that page useful about the blockquotes talking about fingerprinting, in the rtt case:

Note: The value of RTT is rounded to the nearest 25 milliseconds to prevent fingerprinting.

Is the Early-Data a client hint? I thought it was a separate thing like 103 Early Hints

Thanks.

[Ryuno-Ki]

There is also Lang Client Hint which has been deprecated, not sure if you want to also mention that in MDN?

In my observation, those things tend to be mentioned, but also marked as deprecated.
This way, it will become discoverable but also inform, that it shouldn't be used.

[hamishwillee]

Thanks. Hope to start thinking about this on Monday.

[hamishwillee]

FYI I am not ignoring this, and happy for someone to take it on. Just "time poor". I will get to it at some point.

[hamishwillee]

Reopening. Still got some bits to do: #4907 (comment)

[summercms]

Some more Client Hints that can be added to MDN.

1. Client Hint Reliability

https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md
https://datatracker.ietf.org/doc/html/draft-davidben-http-client-hint-reliability-03
https://chromestatus.com/feature/5555544540577792
https://chromestatus.com/feature/5727177800679424

Details	Link
The Critical-CH Response Header Field	https://datatracker.ietf.org/doc/html/draft-davidben-http-client-hint-reliability-03#section-3
The ACCEPT_CH Frame	https://datatracker.ietf.org/doc/html/draft-davidben-http-client-hint-reliability-03#section-4

2. User Preference Media Features Client Hints Headers

https://github.com/tomayac/user-preference-media-features-headers
https://chromestatus.com/feature/5642300464037888

The list of the client hints is modelled after the user preference media features in Media Queries Level 5.

Client Hint	Allowed Values	Corresponding User Preference Media Feature
Sec-CH-Prefers-Reduced-Motion	no-preference, reduce	prefers-reduced-motion
Sec-CH-Prefers-Reduced-Transparency	no-preference, reduce	prefers-reduced-transparency
Sec-CH-Prefers-Contrast	no-preference, less, more, custom	prefers-contrast
Sec-CH-Forced-Colors	active, none	forced-colors
Sec-CH-Prefers-Color-Scheme	light, dark	prefers-color-scheme
Sec-CH-Prefers-Reduced-Data	no-preference, reduce	prefers-reduced-data

[hamishwillee]

Thanks @summercms . Do the above meet the requirement for documentation here: https://developer.mozilla.org/en-US/docs/MDN/Guidelines/Conventions_definitions#when_to_document_new_technologies ?

We also have to consider these cases: #4907 (comment)

Anyway, if there are new whole "collections" like these then probably wroth having separate issues for each (once verified it is time to document them). The work could be shared better that way.

[summercms]

@hamishwillee

You should definitely consider documenting a new technology if:

• It is specified in a specification document published under a reliable standards organization (such as W3C, WHATWG, Khronos, IETF, etc.), which has reached a reasonable level of stability (e.g. a W3C working draft or candidate recommendation, or the spec is looking to be fairly stable judging by the flow of issues filed against it).

Both are under Web Incubator CG (WICG)

• It is implemented consistently in at least one browser, with other browser developers showing signs of interest (such as an active ticket or "intent to implement" process in effect).

Both are currently being added to Google Chrome.

---

Can open two separate issues for each - let me know and I can open 2 issues.

I have seen lately many new client hints being developed on the web, so MDN would probably like to add each one under a separate page to keep the doc's clean and not end up with a huge wall of text in the near future.

[hamishwillee]

FYI, slow progress, but I have nearly updated docs/BCD for the original headers in MDN. Some of these are now deprecated and have been replaced by Responsive Image Client Hints - but those aren't yet in any browsers.

Next start thinking about these other new ones.

[hamishwillee]

@summercms Regarding #1408 (comment), My interpretation is that neither of these are ready for documentation.
The relevant restriction is: and is implemented somewhere. Being in development is not good enough. To avoid having lots of churn on docs while a spec is still being "hardened" by real use, we wait until it is in a release build and there is some interest from other browsers. Often appearance in browser compatibility data is another good trigger.

For the same reason I won't be documenting Responsive Image Client Hints yet. However I have asked about the User agent client hints talked about here, because they went into Chrome 89https://www.chromestatus.com/feature/5995832180473856

[chris-schra]

Sorry for chiming in with a naive question, but why is CH Width marked deprecated? I can‘t find any references saying it is deprecated

[hamishwillee]

@chris-makaio If you mean https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Width , it is no longer in any current spec. It has been superseded in another spec, but the replacement has not yet appeared in any browser.

[himanshugarg]

Are more fixes expected here? The linked PR is merged.

[sideshowbarker]

Closing per #1408 (comment)

[hamishwillee]

Thanks guys - yes this was done, module minor changes around a Save-Data change that has not yet landed in any browser.