Add standard names for Device Client hints

[tunetheweb]

Description

• Copies the device client hints to new docs with their standard Sec-CH names.
• Adds Sec-CH-Viewport-Height page.
• Prefers the Sec-CH- variants to their old names.

Motivation

Fix developer confusion: https://bsky.app/profile/ericportis.com/post/3m7oa4vo5fk2q

Additional details

Device-Memory, DPR and Width were added in Chrome 97: https://chromestatus.com/feature/6658223894429696 (note Device-Memory was not noted there)

Height was added in Chrome 105: https://chromestatus.com/feature/5646861215989760

Related issues and pull requests

BCD changes: mdn/browser-compat-data#28636

[github-actions]

Preview URLs (14 pages)

• /en-US/docs/Web/API/Device_Memory_API
• /en-US/docs/Web/API/Navigator/deviceMemory
• /en-US/docs/Web/API/WorkerNavigator/deviceMemory
• /en-US/docs/Web/HTTP/Guides/Client_hints
• /en-US/docs/Web/HTTP/Reference/Headers/Content-DPR
• /en-US/docs/Web/HTTP/Reference/Headers/DPR
• /en-US/docs/Web/HTTP/Reference/Headers/Device-Memory
• /en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-DPR
• /en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-Device-Memory
• /en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-Viewport-Height
• /en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-Viewport-Width
• /en-US/docs/Web/HTTP/Reference/Headers/Viewport-Width
• /en-US/docs/Web/HTTP/Reference/Headers/Width
• /en-US/docs/Web/HTTP/Reference/Headers

Flaws (6)

Note! 12 documents with no flaws that don't need to be listed. 🎉

URL: /en-US/docs/Web/HTTP/Reference/Headers
Title: HTTP headers
Flaw count: 3

• macros:
  • Macro httpheader produces link /en-US/docs/Web/HTTP/Reference/Headers/Accept-Signature which doesn't resolve
  • Macro httpheader produces link /en-US/docs/Web/HTTP/Reference/Headers/Signature which doesn't resolve
  • Macro httpheader produces link /en-US/docs/Web/HTTP/Reference/Headers/Signed-Headers which doesn't resolve

---

URL: /en-US/docs/Web/HTTP/Reference/Headers/Viewport-Width
Title: Viewport-Width header
Flaw count: 3

• unknown:
  • No generic content config found
  • no blog root
  • no blog root

External URLs (4)

URL: /en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-Device-Memory
Title: Sec-CH-Device-Memory header

• https://developer.chrome.com/docs/privacy-security/user-agent-client-hints (1 time) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-DPR
Title: Sec-CH-DPR header

• https://developer.chrome.com/docs/privacy-security/user-agent-client-hints (1 time) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-Viewport-Height
Title: Sec-CH-Viewport-Height header

• https://developer.chrome.com/docs/privacy-security/user-agent-client-hints (1 time) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-Viewport-Width
Title: Sec-CH-Viewport-Width header

• https://developer.chrome.com/docs/privacy-security/user-agent-client-hints (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2025-12-15 22:20:37)

[hamishwillee]

MDN follows BCD, and BCD keeps information for 2 years after a feature is removed from all browsers.

So the way this is handled really depends on what you do in BCD - e.g. if there is just one record with an alias then you might delete and redirect one of the records as done here.

Personally I would maintain the both records in BCD, and also maintain the pages in MDN. Deletion would then happen 2 years after all browsers stop supporting a particular header name - such as DPR.

[tunetheweb]

I was trying to avoid duplication of content, but since both are still supported for now that's a fair call.

Added back now so PTAL.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[tunetheweb]

This pull request has merge conflicts that must be resolved before it can be merged.

Fixed

[hamishwillee]

Thanks @tunetheweb , FYI, I've squash merged and rebased all your commits. This is of course not "necessary", but I find it much easier to keep things up to date and understand thinking if changes are needed using a rebase merge rather than just merging main. Hope this does not annoy you.

EDIT Also added some review comments. Most of these are arguable, but I think provide about the right level of cross linking. The actual new content LGTM.

[tunetheweb]

Thanks for the thorough review @hamishwillee !

I've accepted most of the feedback but have an outstanding comment about one of the pieces of feedback (x3). I have a slight preference to keep it as I'd written to it, but not 100% wedded to it if you feel strongly about this.

[hamishwillee]

Thanks @tunetheweb - appreciate your patience.

[tunetheweb]

And yours! And your thoughtful reviews. Good to merge from my end!