Guidance on prevention of ossification or burn-in?

[amtunlimited]

No description provided.

[miketaylr]

@amtunlimited can you provide some more details here?

[amtunlimited]

Oh that's odd, it cleared out the body. I'll try to recreate it

I think there should be a section (maybe non-normative) about how to avoid possible burn-in issues when making new client hints. The hint that comes to mind is a discussion about a possible "form-factor" or "device-type" hint, where the introduction of new values posed a problem, with either fallback and the new values never really catching on, or devices lying because they'd get ignored otherwise.

I recall that the decision for that particular hint came down to the fact that that hint would end up just being a proxy for some other value like device width or input method

[abeyad]

wouldn't Origin Trials help avoid burn-in of new/experimental client hints?

[amtunlimited]

I'm referring to the values of the client hint headers, as opposed to the usage. For the "form-factor" example, if we started off with a list like "desktop" and "mobile" and someone wanted to start using "tablet", how should API consumers handle that? How would they know when new values show up, or what they mean? What would be a reasonable fallback? Maintaining a list might be possible but is a burden, and so on.

[abeyad]

Wouldn't we need to define it in the spec, similar to other UA client hints? https://wicg.github.io/ua-client-hints/#http-ua-hints

[abeyad]

In terms of workflow, I would imagine we first start out with an Origin Trial for some new values, and if the API sticks, then draft it up and communicate it as part of the spec?