UA string: "Touch" or "Tablet" again

[Gervase Markham]

Hi everyone,

Can we quickly revisit the question of whether to have one of "Touch" or
"Tablet" in our UA string under some circumstances? We need to work out
how Windows 8 Metro fits into our plans (bug 787786), plus the new pile
of touch-enabled laptops and desktops that I see in the glossy ads which
come with my weekly news magazine. The concern I see is that if we stick
with "Tablet" and apply it consistently only to tablets, it will be
increasingly not useful to web developers, and simply be a point of
gratuitous confusion and incompatibility.

Points to note:

1) I didn't think very hard when deciding to put "Tablet" in our current
tablet UA. I'm happy to admit it may have been a mistake. It hasn't been
there long and it's probably still possible to remove it.

2) Market data:
* iPad has "iPad" and "Mobile".
* Opera uses "Tablet".
* The RIM Playbook uses "Tablet".
* The Kindle Fire has "Mobile" normally, but not in Silk mode.
* The Nook Color in desktop mode has "Mobile". (Custom UA in mobile
mode.)
* Chrome on the Nexus 7 has neither.
* Stock Android browser on Asus Transformer (10") has neither.
* Windows Phone 8 has "Touch" and "Mobile" (as "IEMobile").
* Microsoft also uses "Touch" on "any machine with touch-capable
hardware", including their Windows 8 tablets.

As far as I'm aware, IE 10 on Windows 8 has the same UA in Metro and
non-Metro modes.

Consistent options we could adopt on this question:

A) Use "Touch" to indicate "has a touch-sensitive screen (and is not
already marked 'Mobile')". This would lead to us using it on tablets,
Windows 8 machines, and any other desktop PC with a touchscreen. It
would not be removed if a keyboard was _also_ present. This is
Microsoft's approach.

B) Use "Tablet" to indicate "has a tablet form-factor (N" or greater,
where suggested value for N is 7). So Windows 8 machines and other
touch-screen desktop machines would have the desktop UA. If a tablet
acquires a keyboard, like the Asus Transformer can, the token would
ideally be removed. This is our current approach, and (as far as I can
see) Opera's.

C) Use "Mobile", like the Kindle and Nook. I think it's unlikely we'd
want to do this for _all_ tablets, so let's say under a certain size,
N", and use the desktop UA above that size. This is Amazon's approach.

D) Use neither, like Chrome. UA sniffing is evil. Developers should use
the presence of a touch API to detect touch capability, and use flexible
layout to adapt to whatever screen size the user has. This is Google's
approach.

Options I want to avoid:

X) Stick with "Tablet", but find out it ends up meaning "Touch" anyway.
If you are arguing for sticking with Tablet, are you happy that we won't
be using it on touchscreen desktops and laptops? Do you think that's
what developers will expect?

Y) Use both. Ick.

Z) Use Touch on Windows 8, and Tablet everywhere else. This is bound to
throw people off.

Questions that I think are relevant:

1) What are web developers expecting? Are people making separate
touch-only sites? Or separate tablet sites? Or are some people doing
each of those?

2) Given the varied sizes of tablet, is a single "Tablet" token, which
must inevitably have a size cutoff, actually going to be useful? Touch
capability is at least binary.

3) Given the choice of "mobile or desktop", what sort of experience do
we think people on tablets should have? Does it depend on size?

Gerv

[Dirkjan Ochtman]

On Mon, Nov 12, 2012 at 4:51 PM, Gervase Markham <ge...@mozilla.org> wrote:
> Can we quickly revisit the question of whether to have one of "Touch" or
> "Tablet" in our UA string under some circumstances? We need to work out how
> Windows 8 Metro fits into our plans (bug 787786), plus the new pile of
> touch-enabled laptops and desktops that I see in the glossy ads which come
> with my weekly news magazine. The concern I see is that if we stick with
> "Tablet" and apply it consistently only to tablets, it will be increasingly
> not useful to web developers, and simply be a point of gratuitous confusion
> and incompatibility.

Metro doesn't really imply touch, though, does it? AFAICT, Windows RT
("Metro" is a deprecated term, AIUI) is a very visible part of the
non-touch desktop-level Windows 8 UI.

> Consistent options we could adopt on this question:
>
> A) Use "Touch" to indicate "has a touch-sensitive screen (and is not already
> marked 'Mobile')". This would lead to us using it on tablets, Windows 8
> machines, and any other desktop PC with a touchscreen. It would not be
> removed if a keyboard was _also_ present. This is Microsoft's approach.

If the above is true (Windows RT non-touch interfaces are common) then
this seems like a bad option. I.e. if Mozilla was to adopt a "Touch"
token in the UA, it would seem most ideal to only use it on hardware
that's actually touch-capable.

> B) Use "Tablet" to indicate "has a tablet form-factor (N" or greater, where
> suggested value for N is 7). So Windows 8 machines and other touch-screen
> desktop machines would have the desktop UA. If a tablet acquires a keyboard,
> like the Asus Transformer can, the token would ideally be removed. This is
> our current approach, and (as far as I can see) Opera's.
>
> C) Use "Mobile", like the Kindle and Nook. I think it's unlikely we'd want
> to do this for _all_ tablets, so let's say under a certain size, N", and use
> the desktop UA above that size. This is Amazon's approach.
>
> D) Use neither, like Chrome. UA sniffing is evil. Developers should use the
> presence of a touch API to detect touch capability, and use flexible layout
> to adapt to whatever screen size the user has. This is Google's approach.

Given all the options listed, this one sounds seriously attractive.
Let the developers use appropriate API's to figure out what kind of
layout is appropriate, instead of having them on confusing UA tokens.

> Options I want to avoid:
>
> X) Stick with "Tablet", but find out it ends up meaning "Touch" anyway. If
> you are arguing for sticking with Tablet, are you happy that we won't be
> using it on touchscreen desktops and laptops? Do you think that's what
> developers will expect?
>
> Y) Use both. Ick.
>
> Z) Use Touch on Windows 8, and Tablet everywhere else. This is bound to
> throw people off.
>
> Questions that I think are relevant:
>
> 1) What are web developers expecting? Are people making separate touch-only
> sites? Or separate tablet sites? Or are some people doing each of those?
>
> 2) Given the varied sizes of tablet, is a single "Tablet" token, which must
> inevitably have a size cutoff, actually going to be useful? Touch capability
> is at least binary.

Probably not.

> 3) Given the choice of "mobile or desktop", what sort of experience do we
> think people on tablets should have? Does it depend on size?

I think having it depend on size makes a lot of sense.

But that's just my $0.02,

Dirkjan

[Gervase Markham]

On 12/11/12 16:07, Dirkjan Ochtman wrote:
>> A) Use "Touch" to indicate "has a touch-sensitive screen (and is not already
>> marked 'Mobile')". This would lead to us using it on tablets, Windows 8
>> machines, and any other desktop PC with a touchscreen. It would not be
>> removed if a keyboard was _also_ present. This is Microsoft's approach.
>
> If the above is true (Windows RT non-touch interfaces are common) then
> this seems like a bad option. I.e. if Mozilla was to adopt a "Touch"
> token in the UA, it would seem most ideal to only use it on hardware
> that's actually touch-capable.

Sorry, yes, in case it's not obvious, I am _not_ suggesting using
"Touch" on non-touch-capable machines! (And neither does Microsoft, AIUI.)

>> D) Use neither, like Chrome. UA sniffing is evil. Developers should use the
>> presence of a touch API to detect touch capability, and use flexible layout
>> to adapt to whatever screen size the user has. This is Google's approach.
>
> Given all the options listed, this one sounds seriously attractive.
> Let the developers use appropriate API's to figure out what kind of
> layout is appropriate, instead of having them on confusing UA tokens.

In an ideal world, I'm sure they'd all do that. Question is, will they?

Gerv

[jim.m...@gmail.com]

I don’t see how this information will be of any use in deciding how to present content, and will likely be used in the wrong way which will break user experiences.

We have a related situation with W3C touch event interfaces. Web authors are using their presence as a way to detect mobile devices with the assumption that these devices don’t support mouse input. See bug 806805 for feel for what breaks when we add support (rightfully) for touch input events in the desktop product. I think it’s possible “Tablet” or “Touch” in the UA could be abused in the same way.

The real problem here seems to be a lack of a good way to detect device capabilities, which can change in real-time while the browser is running. For example, I have a Samsung Series 7 that has touch, a dock, a mouse, and a keyboard. Docking the device makes it a desktop, undocking it makes it a tablet. I’d like web sites to react appropriately to these changes – IMHO this is something that should be solved via information exposed to content through js or css, and through better documentation / examples on MDN.

[Marcio Galli]

Touch++, again. Same points I said in September.

Gerv, do you have an online place that captures the discussion? The reason
I ask this is my interest to really understand what is the current
assumption nowadays on what UA stands for and the complexities involved in
this discussion. Plus I wanted to understand a table about reasoning from
other vendors.

m

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



--
www.telasocial.com

[Kevin Brosnan]

On mobile Chrome leaks the device name in the UA this is the current
method of hardware feature detection on the Android stock browser as
well.

Kevin

[wjohns...@gmail.com]

As Jim mentioned, we've seen problems with our current browser because, when we turn on touch event interfaces in the browser (i.e. document.createTouchEvent), sites start to assume that this is a touch enabled browser and only a touch enabled browser. i.e. users using a mouse on a touch enabled device suddenly find things stop working.

I think the bigger problem is just that sites/webapps/etc need to design for both mouse and touch control. Having these interfaces available should actually make that easier by providing a way to re-dispatch mouse events as touch if wanted. I worry that including tokens like this just extends this problem and encourages sites to design for a single mode of interaction. If we need to write more examples/blog posts/etc talking about this problem and potential solutions, I'm happy to help.

i.e. I agree with Jimm for the most part. IMO, we should set up media queries for touch/mouse/pen/whatever-enabled devices and sites that really want to detect device support (but they shouldn't ever do this!) can use media queried css + window.matchMedia if they really want to do this.

[Matt Brubeck]

Here is my personal suggestion for how we should handle this in our
"Metro" browser, and the reasoning behind my proposal. This is meant to
be a minimal step to bring Firefox for Metro in line with other
platforms, without making changes to any other products. It might need
to be tweaked if we make any broader, cross-platform UA changes.

This was originally posted at:
https://bugzilla.mozilla.org/show_bug.cgi?id=809396#c5

ASSUMPTIONS:

A. The UA header is used mainly by sites that serve very different
content to different devices. Sites that use the same basic UI for both
mouse and touch can serve a single page that works with both types of
input and uses feature detection to determine browser capabilities as
needed.

B. For any site that serves different content to "desktop" and "mobile"
users, some portion of users will disagree with the site's default (no
matter which is the default) and will want to switch to the other version.

C. Users of touch-screen devices will sometimes interact with the device
primarily through touch, and sometimes interact primarily with a mouse /
trackpad / other "precise" pointer device. (Some users will stick to
one interaction type all the time, while others may switch back and
forth even on the same device.)

D. *Most* people will prefer the touch-friendly "Metro" Firefox UI while
they are interacting primarily through touch, and *most* people will
prefer the mouse-friendly "desktop" Firefox UI while they are
interacting primarily with precise pointer devices.

E. Many web developers will test on only one or two device types. More
variations in the User-Agent header would mean more developers who
mishandle some of those variations without realizing it.

PROPOSAL:

* We should add "Tablet" to the User-Agent header when the the Metro
Firefox UI is used *and* the hardware supports touch input.

* For non-touch hardware, we should make no changes to the User-Agent
header.

* For the classic (desktop) Firefox UI, we should make no changes to the
User-Agent header.

PROS:

* Users who browse in the mouse-friendly Windows desktop environment
will see no changes in content. In particular, users of
touch-compatible desktops or notebooks who nonetheless prefer the
traditional "desktop" environment will generally see familiar
desktop-style web content.

* Users who browse in the touch-friendly Windows "Metro" environment are
likely to get touch-optimized content by default.

* Sites are unlikely to serve touch-only content to users without touch
hardware.

* Users have an easy and (somewhat) intuitive way to choose between the
"tablet" and "desktop" versions of sites, for example by using Metro
Firefox's "View in desktop" command.

* Sites that follow our existing guidelines to send tablet-optimized
content to Firefox for Android tablets will not need any changes, and
will immediately begin serving tablet-optimized content to Firefox for
Metro.

CONS:

* "Tablet" is not widely used by other browser vendors. "Touch" would
be consistent with Internet Explorer.

* "Tablet" is kind of misleading since it refers to a specific form
factor and is not accurate for all devices where people use our touch
UI. "Touch" might look more "right", and be more self-documenting. For
example, some authors might wrongly assume "Tablet" implies a certain
screen size.

These and many related issues are discussed in much more detail at:
https://bugzilla.mozilla.org/show_bug.cgi?id=773355

QUESTIONS:

Q. Why "Tablet" and not "Touch"?

Mainly for consistency with our current UA header, especially on
Android. Using both "Tablet" and "Touch" would complicate our UA,
adding more variations and more chances for authors to make errors.
Switching from "Tablet" to "Touch" would undo some of our evangelism
work over the past year, and would involve a transition where both
variations exist, again complicating web development and testing.

However, I think this is a reasonable question to discuss in bug 773355,
and I believe the rest of this proposal would still make sense if we
replaced "Tablet" with "Touch" everywhere.

Q. What about users who want to use desktop Firefox *and* interact with
web pages through touch?

Ideally, most web developers would use feature detection instead of UA
sniffing, and serve a single page with good support for both touch and
mouse interaction, which will work in all browsers.

But for sites that do use UA sniffing, the best we can do is help
developers choose defaults that work best for the majority of users.
Users who dislike the default can easily change it by switching between
Metro and desktop Firefox, or by using an add-on or about:config to
change the header.

[Justin Dolske]

On 11/12/12 7:51 AM, Gervase Markham wrote:

> Can we quickly revisit the question of whether to have one of "Touch" or
> "Tablet" in our UA string under some circumstances? We need to work out
> how Windows 8 Metro fits into our plans (bug 787786)

Noooooooooooo. :/

The UA is such a disaster. I wish we'd just freeze the damn thing
already (or as close to as possible). Surely there are other ways to
help sites do whatever it is they want to do?

Justin

[Henri Sivonen]

On Mon, Nov 12, 2012 at 8:05 PM, Matt Brubeck <mbru...@mozilla.com> wrote:
> PROPOSAL:
>
> * We should add "Tablet" to the User-Agent header when the the Metro Firefox
> UI is used *and* the hardware supports touch input.
>
> * For non-touch hardware, we should make no changes to the User-Agent
> header.
>
> * For the classic (desktop) Firefox UI, we should make no changes to the
> User-Agent header.

+1

> PROS:
>
> * Users who browse in the mouse-friendly Windows desktop environment will
> see no changes in content. In particular, users of touch-compatible
> desktops or notebooks who nonetheless prefer the traditional "desktop"
> environment will generally see familiar desktop-style web content.

This is an important point. I, for one, expect touch screen on laptops
and desktops to be disasters as far as ergonomics go.

> * Sites that follow our existing guidelines to send tablet-optimized content
> to Firefox for Android tablets will not need any changes, and will
> immediately begin serving tablet-optimized content to Firefox for Metro.

This is important. We shouldn’t pull the rug from under the people to
whom we’ve already evangelized “Tablet” and we shouldn’t waste bytes
by having both “Tablet” and “Touch”. Our UA sniffing-related
evangelism efforts will have zero credibility if we keep changing the
UA string all the time (to the extent the efforts say something other
than “don’t look at the UA string”).

> CONS:
>
> * "Tablet" is not widely used by other browser vendors. "Touch" would be
> consistent with Internet Explorer.

This might actually be a pro rather than con as long as IE and Firefox
use a different set of events for touch. And “Tablet” is used by
Opera. By not saying “iPad”, we’ve implicitly already decided not to
chase “widely”.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Jonas Sicking]

On Mon, Nov 12, 2012 at 7:51 AM, Gervase Markham <ge...@mozilla.org> wrote:
> D) Use neither, like Chrome. UA sniffing is evil. Developers should use the
> presence of a touch API to detect touch capability, and use flexible layout
> to adapt to whatever screen size the user has. This is Google's approach.

Note that API detection is only possible client-side. (And using
javascript, though this is less of an issue).

Websites generally send dramatically different content for touch-based
UIs. Different enough that they'd want to send a different piece of
main content.

Note that putting "touch" in the UA is somewhat different than
traditional UA sniffing. It's actually capability testing which is
what we are encouraging people to do. Using HTTP-headers is the way
you do server-side capability testing, comparable to using JS and
API-detection to do client-side capability testing.

Touch definitely gets my vote in both mobile and tablet UIs from a
puristic point of view. Not sure if putting it in mobile will cause
breakage by sending "tablet websites" to mobile devices though?

/ Jonas

[jim.m...@gmail.com]

On Tuesday, November 13, 2012 4:49:14 AM UTC-6, Jonas Sicking wrote:
> Note that API detection is only possible client-side. (And using
> javascript, though this is less of an issue).
>
> Websites generally send dramatically different content for touch-based
> UIs. Different enough that they'd want to send a different piece of
> main content.
>
> Note that putting "touch" in the UA is somewhat different than
> traditional UA sniffing. It's actually capability testing which is
> what we are encouraging people to do. Using HTTP-headers is the way
> you do server-side capability testing, comparable to using JS and
> API-detection to do client-side capability testing.

Isn't this what we want to avoid? For the user with a laptop that
supports touch they are going to get thrown into touch centric (mobile)
interfaces on web sites. I have had this happen on the tablets I test
with thanks to the touch interfaces - it's really annoying.

Also it seems odd that we would only identify one capability through
the UA and not others. By putting "touch" in the UA, what are we conveying
exactly?

[Dao]

On 12.11.2012 19:05, Matt Brubeck wrote:
> * Sites that follow our existing guidelines to send tablet-optimized
> content to Firefox for Android tablets will not need any changes, and
> will immediately begin serving tablet-optimized content to Firefox for
> Metro.

Is there a significant amount of such sites? As far as I know, Firefox
has practically no users on Android tablets. The fact that IE10 uses
"Touch" seems more relevant to me and means that we'll likely have to do
less evangelism in the long run if we use "Touch".

[jim.m...@gmail.com]

On Tuesday, November 13, 2012 4:49:14 AM UTC-6, Jonas Sicking wrote:

> Note that API detection is only possible client-side. (And using
> javascript, though this is less of an issue).
>
> Websites generally send dramatically different content for touch-based
> UIs. Different enough that they'd want to send a different piece of
> main content.
>
> Note that putting "touch" in the UA is somewhat different than
> traditional UA sniffing. It's actually capability testing which is
> what we are encouraging people to do. Using HTTP-headers is the way
> you do server-side capability testing, comparable to using JS and
> API-detection to do client-side capability testing.

[wjohns...@gmail.com]

On Tuesday, November 13, 2012 2:49:14 AM UTC-8, Jonas Sicking wrote:
> Websites generally send dramatically different content for touch-based
> UIs. Different enough that they'd want to send a different piece of
> main content.

Just to be clear, this is NOT generally true in what I've seen. Websites send dramatically different content to small screen devices, but not to touch based ones or tablets.

[wjohns...@gmail.com]

On Tuesday, November 13, 2012 2:49:14 AM UTC-8, Jonas Sicking wrote:

> Websites generally send dramatically different content for touch-based
> UIs. Different enough that they'd want to send a different piece of
> main content.

[Dao]

On 13.11.2012 12:24, jim.m...@gmail.com wrote:
> On Tuesday, November 13, 2012 4:49:14 AM UTC-6, Jonas Sicking wrote:
>> Note that putting "touch" in the UA is somewhat different than
>> traditional UA sniffing. It's actually capability testing which is
>> what we are encouraging people to do. Using HTTP-headers is the way
>> you do server-side capability testing, comparable to using JS and
>> API-detection to do client-side capability testing.
>
> Isn't this what we want to avoid? For the user with a laptop that
> supports touch they are going to get thrown into touch centric (mobile)
> interfaces on web sites. I have had this happen on the tablets I test
> with thanks to the touch interfaces

This is a misguided simile. Once upon a time, the touch interfaces were
actually only present on mobile devices. This is never going to be the
case for the Touch token. The Touch token won't be present on mobile
devices; it's unclear to me why you think anyone would treat it like the
touch interfaces.

[Gervase Markham]

On 12/11/12 16:49, Marcio Galli wrote:
> Touch++, again. Same points I said in September.

Can you give us a reference?

> Gerv, do you have an online place that captures the discussion?

You mean the Touch/Tablet discussion?

> The reason
> I ask this is my interest to really understand what is the current
> assumption nowadays on what UA stands for and the complexities involved in
> this discussion. Plus I wanted to understand a table about reasoning from
> other vendors.

There is no one single place which documents Mozilla's approach to UA
strings, partly because we are always re-evaluating in the light of
changing circumstances, although there are some useful documents:

https://wiki.mozilla.org/Changing_the_UA_String

Gerv

[Gervase Markham]

On 13/11/12 16:37, wjohns...@gmail.com wrote:
> Just to be clear, this is NOT generally true in what I've seen.
> Websites send dramatically different content to small screen devices,
> but not to touch based ones or tablets.

I think this is an important question. Is there anywhere we can get some
data to confirm your or Jonas' view?

Gerv

[Gervase Markham]

On 12/11/12 23:29, Justin Dolske wrote:
> The UA is such a disaster. I wish we'd just freeze the damn thing
> already (or as close to as possible).

Hey, I'm not saying that I like having to revisit this as often as we
are! :-|

> Surely there are other ways to
> help sites do whatever it is they want to do?

If we froze the UA, they'd just use other detection methods, and we'd be
having the same discussion about changing what some JS API returns.

Gerv

[Gervase Markham]

On 12/11/12 16:36, jim.m...@gmail.com wrote:
> I don’t see how this information will be of any use in deciding how
> to present content, and will likely be used in the wrong way which
> will break user experiences.
>
> We have a related situation with W3C touch event interfaces. Web
> authors are using their presence as a way to detect mobile devices
> with the assumption that these devices don’t support mouse input. See
> bug 806805 for feel for what breaks when we add support (rightfully)
> for touch input events in the desktop product. I think it’s possible
> “Tablet” or “Touch” in the UA could be abused in the same way.

I guess the counter-argument could be that bogus assumptions are an
orthogonal problem; unless we remove all possible ways of detecting
touch input (impossible!), then anyone _could_ make this mistake. We
just need to tell framework authors that it is a mistake. And that's
independent of how they are doing the detection.

> The real problem here seems to be a lack of a good way to detect
> device capabilities, which can change in real-time while the browser
> is running. For example, I have a Samsung Series 7 that has touch, a
> dock, a mouse, and a keyboard. Docking the device makes it a desktop,
> undocking it makes it a tablet. I’d like web sites to react
> appropriately to these changes – IMHO this is something that should
> be solved via information exposed to content through js or css, and
> through better documentation / examples on MDN.

That is our mantra :-) Although I'm sure our documentation could be
improved.

Gerv

[Gervase Markham]

On 12/11/12 17:25, Kevin Brosnan wrote:
> On mobile Chrome leaks the device name in the UA this is the current
> method of hardware feature detection on the Android stock browser as
> well.

OK. So given that we don't want to do that (we've rejected it twice
now), if this is the even-worse alternative, than perhaps we do need to
provide something in the UA which answers this common "is it supported?"
question...

Gerv

[Robert Kaiser]

Gervase Markham schrieb:

> A) Use "Touch" to indicate "has a touch-sensitive screen (and is not
> already marked 'Mobile')".

IMHO, this should really be detected via a media query or something like
that. Feature detection with the UA string is a bad habit which we
shouldn't encourage, I think.

Robert Kaiser

[Justin Dolske]

On 11/14/12 3:58 AM, Gervase Markham wrote:

>> Surely there are other ways to
>> help sites do whatever it is they want to do?
>
> If we froze the UA, they'd just use other detection methods, and we'd be
> having the same discussion about changing what some JS API returns.

Sure, but I think we're better at those kinds of discussions, and the
rapid evolution of JS/CSS is broadly understood and working well. (As
opposed to the Errata Obscura of UA changes).

ObTroll: If we put "Touch" in the UA, let's at least prefix it as
experimental. ;-)

Justin

[Jonas Sicking]

If indeed we can't send the token on mobile devices (because it would
cause them to send us the somewhat-larger-screen-size tablet UI?) then
I agree with you. My proposal only makes sense if we can send the
"touch" token for mobile as well.

/ Jonas

[Jonas Sicking]

If this is indeed the case, maybe we should add something to the UA
string which indicates the screen size.

/ Jonas

[Marcio Galli]

On Mon, Nov 19, 2012 at 10:41 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> On Tue, Nov 13, 2012 at 8:37 AM, <wjohns...@gmail.com> wrote:

> If this is indeed the case, maybe we should add something to the UA
> string which indicates the screen size.
>
>

But it is also good to check what toolkit vendors are doing ( specifically
the ones focusing in mobile <-> desktop ).

Just yesterday I was in a meeting and the person next to me asked me to
check his page written with bootstrap (Twitter). See this page:

http://twitter.github.com/bootstrap/ ( resize it to X-small x Y-any and see
).

Toolkit vendors are usually surfacing these problems and some modern of
them won't do UA-based (as opposite to a huge number of online articles
recommending users to do UA-based detection as a means to *even* try to
assert screen size! — which is now, as said, not a reality anymore.)

Plus it seems that things like CSS 3 Grid template would also do as a
solution in this area; perhaps to surface the metaphor of a "semantic
resize" — when screen is small, the arrangement not always will fit the
DOM order so it seems that a kind of template-based modification is going
to happen here.

Marcio


/ Jonas

[Gervase Markham]

On 20/11/12 00:14, Jonas Sicking wrote:
> If indeed we can't send the token on mobile devices (because it would
> cause them to send us the somewhat-larger-screen-size tablet UI?) then
> I agree with you. My proposal only makes sense if we can send the
> "touch" token for mobile as well.

Or developers decide, perhaps with our encouragement, that "Mobile"
implies "Touch".

Gerv

[Gervase Markham]

On 20/11/12 00:41, Jonas Sicking wrote:
> If this is indeed the case, maybe we should add something to the UA
> string which indicates the screen size.

As well as being something no other browser does, that would increase
our fingerprintability.

Gerv