Re: [w3ctag/design-reviews] User-Agent Client Hints & UA Reduction (#640)

Hi @jorabin-51d,
> > A site won’t need to migrate to UA-CH if they only rely on browser name, major version, platform, or mobileness

> In general that’s not the case. One of the strongest use cases is for device type, for example.

Can you clarify what you mean by device type?

> We don’t think that gross mis-operation in the form of 500 errors etc. is the primary concern. Of more concern is user experience and optimisation.

I agree that 500s are not the only kinds of concerning site breakage (and in my experience 400-level errors are more common than 500-level for UA changes). If you know about concrete UX or optimization bugs, or just things generally not working as expected please [file them](https://crbug.com/new).

> It is a very significant concern that there is no other implementer, since this means that the Chromium way of doing things will splinter the Web. There is a good chance that this fracture in the Web will continue indefinitely. 

It's fairly normal for one engine to ship ahead of other engines, depending on the feature. That's not a new thing. Chrome is actually lagging when it comes to User-Agent Reduction efforts: Safari gets a gold medal from me 🥇 for being the leader, I think, with Firefox coming in second place 🥈 (reasonable people can disagree with the ordering there 🤷 ).

But I will note that other browsers like Firefox and Safari have _not_ offered a way to recover the information lost to reduction. I'm not sure that's a better outcome for sites. That said, I'm hopeful they will see the value in the UA-CH API and eventually implement it, and am happy to work with them on the spec and in whatever eventual working group it ends up in to address their feedback.

> Were another implementer to come on board it seems likely to me that the standard would move on from today’s specification with potential further disruption to website operators. 

Are you saying another implementer is going to make things worse? Or am I missing the point?

> Noting that this RFC is “Experimental” and is therefore not standardised at IETF.

OK. I think we have different definitions (and spellings!) in mind for standardization.

> However the plan to proceed appears to be independent of what this TAG review will conclude.

Maybe there's some misunderstanding of what role TAG a review plays in the [Blink Process](https://www.chromium.org/blink/launching-features/).  The Chromium project asks for the TAG's review and advice when it comes to technical designs and how they fit into the broader platform, not for advice on product decisions like shipping or timelines.

(An [early review](https://github.com/w3ctag/design-reviews/issues/320#issuecomment-460926256) by the TAG seemed pretty positive on the concept in general, FWIW.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/640#issuecomment-1045340729

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/640/1045340729@github.com>

Received on Friday, 18 February 2022 23:28:05 UTC