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

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

From: Ashley Gullen <ashley@scirra.com>
Date: Tue, 30 Sep 2014 17:18:33 +0100
Message-ID: <CAABs73hW9ZvujScQSX6HMGwb50HV_00fB2gx6sSfuALJffj6PQ@mail.gmail.com>
To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Cc: WHAT Working Group <whatwg@whatwg.org>, Jonas Sicking <jonas@sicking.cc>, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
Am I right that a lot of the mentioned problems stem from old Android
devices with browsers that have been shoddily hacked and broken by the
manufacturers (presumably in the name of making "improvements")? For
example I remember specific versions of some Samsung Android device
browsers would freeze during touches, ruining canvas games. I suppose the
intent is to detect this OS version and affected devices and display a
warning perhaps (there weren't any workarounds to that as far as I know).
At least with Android both the web view and OS browser is moving to Chrome,
and manufacturers don't hack it to pieces any more. I'm not aware of any
other platforms where you get model-specific hacks/modifications/bugs, so
maybe this problem is going away by itself?

I would suggest breaking out every token of the UA string to its own
navigator property, but that's already failed - for example every browser
already reports navigator.appName as "Netscape", presumably for
long-standing backwards compatibility. The UA string, while getting
ridiculously ugly these days, can be extended backwards-compatibility,
which I guess is a feature.


On 24 September 2014 11:34, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>

> On Wed, Sep 24, 2014 at 10:38 AM, Nils Dagsson Moskopp <
> nils@dieweltistgarnichtso.net> wrote:
> > Jonas Sicking <jonas@sicking.cc> writes:
> >
> > > In some cases websites uses the UA strings for bad reasons ("this is
> > > how we've always done it"), in other cases because it's literally the
> > > best way for them to create a good user experience for their users.
> >
> > I have seen lots of the former and only some of the latter (software
> > downloads for a specific OS / hardware come to mind). Please list
> > examples of “good user experience” for which hardware is needed.
> >
> Ohhhh, I could write a book about this, but let's scratch the surface:
> * Disable animations for specific devices where they're janky / crash /
> don't work, as in the view doesn't even end up in the correct end state of
> the animation.
> * Force a reflow on devices where the UA fails to repaint when the
> transform matrix is updated. Forcing reflow on all devices would be a
> massive performance degradation on all devices, whereas not forcing reflow
> at all would lead to completely broken experience on a specific device.
> * Override feature detection, e.g. one older Galaxy Note device reported in
> the webview that "transform"/"transition" in
> document.createElement("div").style is true, but using the unprefixed
> property didn't work. Using both didn't work either because it selected the
> unprefixed setting which it didn't actually support. Android 2.3 and IE9
> support simple CORS XHR but can't be feature-detected without making a
> request.
> * Apologize from users for whom the experience is irrevocably broken
> (Android 4.0.x), or recommend them to switch browsers (doesn't help if
> you're in a webview).
> * Apply z-index hacks that fix the layering on specific devices while
> breaking it on others.
> * Request user interaction for something that would on other UAs be OK to
> do without user interaction, e.g. creating an AudioContext (silently fails
> on iOS unless in response to a user interaction).
> * (Server-side) approximate screen size to deliver the correct critical
> rendering path.
> * (Server-side) approximate screen size to deliver an approximation of
> correct image sizes before for example a picture polyfill kicks in.
> * (Server-side) approximate screen size to deliver an approximation of a
> grid system as CSS that matching the layout before JS kicks in.
> * (Server-side) deliver only the needed polyfills.
> This is just stuff that I remember off the bat without looking at any
> specific codebase. I might add more later if necessary.
> > > […]
> > >
> > > I'm just suggesting that on platforms where various browsers are
> > > *already* exposing a device model through the UA string. That we
> > > expose the same information in a more easy-to-consume property in the
> > > DOM.
> > >
> > > My suggested name would be navigator.deviceModel
> > >
> > > Thoughts?
> >
> > This would lead to yet another entry point for device
> > discrimination. Please do not make this easier.
> >
> Yes, we can choose to not make developers lives easier, sit in an ivory
> tower looking at a perfect world where every browser behaves exactly
> according to standards with exact same performance characteristics and
> shame developers when they desperately try to drive people to use their
> native apps instead of their websites, or we could try to understand the
> reasons why developing good experiences for the web is such a pain that
> they'd rather push their users away from the product of their sweat and
> tears.
> You could argue that the developers shouldn't have to do this - that it's
> on the browser/device manufacturers - and you'd be right. However that's
> not much consolation to the developers when 20% of their user base is on a
> device that will never get updates and has a mostly broken experience. Or
> when a major manufacturer releases the hottest new device ever and then the
> web app developers' brand is taking damage because of partnerships with
> that manufacturer, while having a completely broken experience on their
> flagship product. We can tell them the future will be better with
> ever-green browsers, but that doesn't mean that we shouldn't provide the
> developers with the best tools possible to deal with the situation when it
> goes sour.
> Of course this leads to also bad things when the next breakthrough in
> devices using the web is made and suddenly everyone is targeting designs to
> a specific device again (because it's the only one with certain
> characteristics), but one way or another they'll manage to do it anyway,
> whether we make it hard or not. However, the harder we make things, the
> harder it becomes to change the workarounds for these things to be more
> generic and thus we'll just slow down progress.
> - Jussi
> > --
> > Nils Dagsson Moskopp // erlehmann
> > <http://dieweltistgarnichtso.net>
> >
Received on Tuesday, 30 September 2014 16:19:01 UTC

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