W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

Re: [whatwg] Adding a property to navigator for getting device model

From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
Date: Wed, 24 Sep 2014 13:43:16 +0200
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, James Graham <james@hoppipolla.co.uk>
Message-ID: <87k34tz1kb.fsf@dieweltistgarnichtso.net>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>
Silvia Pfeiffer <silviapfeiffer1@gmail.com> writes:

> On 24 Sep 2014 20:40, "James Graham" <james@hoppipolla.co.uk> wrote:
>> On 24/09/14 02:54, Jonas Sicking wrote:
>> > In the meantime, I'd like to add a property to window.navigator to
>> > enable websites to get the same information from there as is already
>> > available in the UA string. That would at least help with the parsing
>> > problem.
>> >
>> > And if means that we could more quickly move the device model out of
>> > the UA string, then it also helps with the UA-string keying thing.
>> It's not entirely clear this won't just leave us with the device string
>> in two places, and unable to remove either of them. Do we have any
>> evidence that the sites using UA detection will all change their code in
>> relatively short order, or become unimportant enough that we are able to
>> break them?
> Why don't we provide a better structure and not just a random string. For
> example: deviceID, browserID, renderingEngineVersion ... Not sure what else
> would be useful to group actions that the developer needs to take. Haven't
> looked in detail.

This can and will lead to undue discrimination. Not using any of IE,
Firefox, Safari or Chrome can already be enough to not be locked out of
a site that would work if only a check for a UA string was not there.

What developers actually do want to know is if some devices have some
capabilities. That something feature detection provides. The UA version
or hardware almost always constitutes a hidden query for something else.

Nils Dagsson Moskopp // erlehmann
Received on Wednesday, 24 September 2014 11:44:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC