[blink-dev] Intent to Deprecate: Standardize existing client hint naming
Ari Chivukula
Contact emails
ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
Design Doc
https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit
https://docs.google.com/document/d/1X5bEbIZ9U2DQhB_4yWxVuR9rGnnWjAOW-gSdlINbnNU/edit
Specification
https://wicg.github.io/client-hints-infrastructure/
https://wicg.github.io/responsive-image-client-hints/
https://wicg.github.io/savedata/#save-data-request-header-field
https://wicg.github.io/netinfo/#networkinformation-interface
Summary
Now that our implementation aligns with the Client Hint proposal and the new names for existing client hints with the `sec-ch-` prefix are launched, we should alert web developers to migrate to them. The best way to do this is by introducing a new Client Hints DevTool issue.
Blink component
Motivation
Client Hints, a method to request information about the user's device or conditions, have been implemented in Chrome, but since the initial implementation the naming scheme has changed. If implemented, this proposal would alert developers using `dpr`, `width`, `viewport-width`, and `device-memory` to migrate to use `sec-ch-dpr`, `sec-ch-width`, `sec-ch-viewport-width`, and `sec-ch-device-memory` respectively. The three network related client hints with legacy names, `rtt`, `downlink`, and `ect`, will not be updated as they may be replaced by different hints in an independent process.
TAG review
Not needed
Risks
Only Blink implements client hints and we are not (yet) removing any current ones, just pushing developers to use the corrected names. If usage permits, we will remove the legacy names down the line in another intent.
Interoperability and Compatibility
Gecko: No official position; mild positive signals.
Firefox: UA Client hints considered non-harmful
Web developers: Positive interest from Cloudinary
Is this feature fully tested by web-platform-tests?
N/A (the issues tab isn’t in other browsers)
Tracking bug
Link to entry on the Chrome Platform Status
Jeffrey Yasskin
Contact emails
ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
Design Doc
https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit
https://docs.google.com/document/d/1X5bEbIZ9U2DQhB_4yWxVuR9rGnnWjAOW-gSdlINbnNU/edit
Specification
https://wicg.github.io/client-hints-infrastructure/
https://wicg.github.io/responsive-image-client-hints/
https://wicg.github.io/savedata/#save-data-request-header-field
https://wicg.github.io/netinfo/#networkinformation-interface
Summary
Now that our implementation aligns with the Client Hint proposal and the new names for existing client hints with the `sec-ch-` prefix are launched, we should alert web developers to migrate to them. The best way to do this is by introducing a new Client Hints DevTool issue.
Blink component
Motivation
Client Hints, a method to request information about the user's device or conditions, have been implemented in Chrome, but since the initial implementation the naming scheme has changed. If implemented, this proposal would alert developers using `dpr`, `width`, `viewport-width`, and `device-memory` to migrate to use `sec-ch-dpr`, `sec-ch-width`, `sec-ch-viewport-width`, and `sec-ch-device-memory` respectively. The three network related client hints with legacy names, `rtt`, `downlink`, and `ect`, will not be updated as they may be replaced by different hints in an independent process.
TAG review
Not needed
Risks
Only Blink implements client hints and we are not (yet) removing any current ones, just pushing developers to use the corrected names. If usage permits, we will remove the legacy names down the line in another intent.
Interoperability and Compatibility
Gecko: No official position; mild positive signals.
Firefox: UA Client hints considered non-harmful
Web developers: Positive interest from Cloudinary
Is this feature fully tested by web-platform-tests?
N/A (the issues tab isn’t in other browsers)
Tracking bug
Link to entry on the Chrome Platform Status
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJq4f6LvkROvh83M%3D%2Bd85DMBYdS05ofjKj4VyRFtuGh4w%40mail.gmail.com.
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dX%3DWwwaSc8vSef3JYzVH9OUqUzp8xXLAtv1L%3DvWEk9_8%3DA%40mail.gmail.com.
Daniel Bratell
We discussed this at the API Owners meeting and we did not see that the move to a special tab in devtools changes the how to look at deprecations of an indeterminate length.
The problem with deprecations of an indeterminate length is
two-fold:
* They can be around for a long time which will contribute to "warning fatigue" which makes developers in general less likely to notice the information we give them.
* Without a set date, it becomes hard for a developer to know when to act, and the result can be that they don't act at all which reduces the value of the warning.
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWU2VF2C0qY5sGabcgcjCsgi6B8ZgkTn0UKqivw%3DrLj9w%40mail.gmail.com.