- From: eberhard speer jr. <seshat@ducis.net>
- Date: Fri, 03 Oct 2014 15:09:36 +0300
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, WHAT Working Group <whatwg@whatwg.org>, Mounir Lamouri <mounir@lamouri.fr>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/2014 09:38, Jonas Sicking wrote: > On Thu, Oct 2, 2014 at 9:24 PM, eberhard speer jr. > <seshat@ducis.net> wrote: >> If you are interested in the intricacies of "UA-sniffing", client >> and server-side, the use-cases, the esoterica etc I'll gladly >> contribute what I can. > > I guess the question at hand is: > > What are the client-side situations when people need to do look up > device capabilities using "UA-sniffing" and DeviceMap? I.e. when > can't they use JS code and the APIs exposed through the DOM to > detect what capabilities are available, and instead they have to > look up these capabilities in DeviceMap? > > For server-side UA sniffing these situations are much more clear > since the server has information to *much* less information. I.e. > the server only has access to the headers that the browser sent. > > However JS code running in a browser has access to a much richer > amount of information. So when does it need to use DeviceMap? > > / Jonas > Hi, I fear you greatly oversimplify matters. For starters, 'responsive design' is not the only use case and secondly it is not the case that the server is at a disadvantage information wise, as a matter of fact, once a device is linked to a known UA-profile the opposite is very much the case. I must say I'm somewhat taken aback by this dismissive attitude. esjr -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJULpIAAAoJEOxywXcFLKYceS0IANCH35fbTl3s/VkwOsPVkMHN 4bYNBQymQEsO0mv81825cKRoClOcdkx/nZUbvTS0qd4C8OgNDUCN/D5Ryj8kvwMx OCjraKnwkbNobMvoxKjR+OiLi1SiipjP15jdnsi+q9NlgQ+vpjHxm+s8jWrUZ+Kj h75Pe3QzUKyLq716WJYLz06fvNhMeZ2+m0eDIGtS7+5KRvnfn+fd8m0lDmFNTNQU Zhb+indcptliEF3awxqsbmTQE1MftTb8Ol4mCmYOGCHcQASOrPkusThMqekwiOqK 4iWECIpHeLDhA4Q+wloYHrI0nABSQgKZYaUi2PGS1Mgy+mGRdT+VwiObwhnZF6Y= =k32y -----END PGP SIGNATURE-----
Received on Friday, 3 October 2014 12:10:33 UTC