Does Client Hints have multi vendor support?

[othermaciej]

The Fetch specification integrates support for Client Hints, most notably in step 7 of the Fetching algorithm.

Per WHATWG Working Mode, additions are supposed to have "support from at least two implementors", and "the support from implementers should be of the form 'we would like to implement this soon' and not just 'this seems like a reasonable idea'".

I know that Chrome/Blinks supports (and ships) Client Hints and Safari/WebKit does not ship Clients Hints or support it. Mozilla's standards position on the topic doesn't hard refuse, but also doesn't seem to indicate any kind of active support. Are there indications of multi-implementor support that I am missing?

I don't really want to be policing this, but since features shipping only in Safari have been removed from specs based on the multi-implementor support policy before, I think it should be applied consistently. There are also currently open issues for further extending this support, and I'm concerned they may give the impression that Client Hints is part of the interoperable multi-vendor Web Platform.

[yoavweiss]

@othermaciej AFAIK, the current Client Hints language was added to the spec before that rule was in place. Furthermore, the current language doesn't represent the current Chromium implementation, nor where we want to take it. The latter is defined in a WIP PR, until we're able to land it as the feature gets multi-vendor support.

[othermaciej]

AFAIK, the current Client Hints language was added to the spec before that rule was in place.

Looks like it was added in this commit on March 22, 2016: 404dc3a

Working Mode was first explicitly made a separate document in April 25th, 2017. So it seems you are correct about timing.

It's not clear to me whether the policy is supposed to apply retroactively or if so in what cases. However, there have been subsequent updates, the most recent in 2018, still without a showing of multi-implementor support.

If the current language does not have multi-implementor support, and also does not match what the one existing implementation does, perhaps it should be removed in the meantime?

I leave it to the editor's discretion to determine the best course of action here.

[annevk]

I've been thinking about this as well, especially as the model as-is is broken and might confuse potential implementers.

I'd be willing to create a PR to remove it and the resulting commit could be used by @yoavweiss in the PR to eventually add it again, provided support materializes.