- From: <bugzilla@jessica.w3.org>
- Date: Thu, 02 Feb 2012 11:57:24 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15380 --- Comment #18 from Henri Sivonen <hsivonen@iki.fi> 2012-02-02 11:57:22 UTC --- (In reply to comment #17) > But if you believe this is useful work then there's no reason why you couldn't > define it in a separate document. If you need help with the IETF process, let > me know. A UA string spec written without the developers of the products that send UA strings is going to fail. Don't bother. UA strings are compromises between various considerations: * Wishing to look similar enough to what came before to satisfy existing sniffers. * Wishing to look different from what came before to be recognized as something different for promotional purposes. * Wishing to reveal as little information as possible to avoid fingerprinting and to avoid giving sites the opportunity to sniff for inessential things and ruin UX for some users whose browser sends something different for inessential parts of the UA string. * Wishing to reveal as much information as possible for support forums, software downloads, bug trackers or plain curiosity. * Etc., etc. It's hard to get consensus on the balance of these things even within one vendor. And if the end state of what you are trying to do results in different UA strings between vendors, sites will continue to target browsers by vendor and you haven't really accomplished a level playing field by standardization. Ask yourself: * What problem are you trying to solve? * What's your solution? * Why would the stakeholders accept your solution? * Would your solution actually end up solving the problem? * How much damage would implementing your solution inflict? * Is your solution implementable on a vendor-by-vendor basis or does it require everyone to ship at the same time? -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 2 February 2012 11:57:26 UTC