- From: <bugzilla@jessica.w3.org>
- Date: Tue, 03 Jan 2012 10:57:13 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15380
--- Comment #3 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2012-01-03 10:57:11 UTC ---
(In reply to comment #1)
> I think this sounds like a good idea in general. Would you suggest that a
> single canonical User-Agent string be specified, or should there still be some
> implementation-specific information in it?
A single canonical User-Agent string does not sound realistic. Such a string
would not be a User-Agent string. Or, at least its meaning would then only
become "This is a HTML5-compatible user agent", or something like that. (In a
way: no different from the accept header that tells that it accepts 'text/html'
...) Nevertheless, this would not be of much interest for those who read user
agent statistics - such as the vendors themselves.
So yes, there must be implementation-specific info there. Basically, the
de-facto requirements for UA strings should be collected and documented, so
that old and new vendors can know what possible pitfalls there could be. The
key things would be expected tokens and expected (sub)formats. For example
"Mozilla/0" seems to be synonymous with "a UA that pretends to be a GUI UA".
One additional idea: Keep a registry of HTML UA strings? The list could
document the support level of each UA together with its official UA string.
There seems to be two kinds of Web page makers that vendors/UA develoeprs need
to be aware of:
a) Active developers, like Facebook. Such Web developers
could probably make use of such list.
b) Passive, those who use some software which, perhaps without
their knowledge discriminate users of less common browsers
So, one could have two lists: A list of limitations when it comes to picking a
UA string. And a list of the actual UA strings/string formats in use.
--
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 Tuesday, 3 January 2012 10:57:16 UTC