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

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 Wednesday, 24 September 2014 10:35:04 UTC