On Mon, Nov 19, 2012 at 10:41 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 13, 2012 at 8:37 AM, wjohnston2...@gmail.com wrote:
On Tuesday, November 13, 2012 2:49:14 AM UTC-8, Jonas Sicking wrote:
Websites generally send dramatically different content for touch-based
UIs.
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
On Tue, Nov 13, 2012 at 8:37 AM, wjohnston2...@gmail.com wrote:
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
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
On 13/11/12 16:37, wjohnston2...@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
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
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
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
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.
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
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
hsivo...@iki.fi
http
On Mon, Nov 12, 2012 at 7:51 AM, Gervase Markham g...@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
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
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
On 13.11.2012 12:24, jim.math...@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
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
On Mon, Nov 12, 2012 at 4:51 PM, Gervase Markham g...@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
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_
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
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
On Mon, Nov 12, 2012 at 8:12 AM, Gervase Markham g...@mozilla.org wrote:
On 12/11/12 16:07, Dirkjan Ochtman 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
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
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
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)
N. :/
The UA is such a disaster. I wish
On 18/09/12 17:13, Asa Dotzler wrote:
I think we should go with Touch like Microsoft and not Tablet.
The bug on this has been reopened:
https://bugzilla.mozilla.org/show_bug.cgi?id=773355
Gerv
___
dev-platform mailing list
. However, in all
fairness, I have no data on how many sites currently recognize the
Firefox Tablet UA.
I think that sites which are doing whole-UA detection are either deeply
specialized or seriously broken. I would hope that changing Tablet to
Touch would affect only sites which care about whether
On Thursday, August 2, 2012 6:32:30 AM UTC-7, Gervase Markham wrote:
http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx
IE10 has introduced the Touch token to the UA string, which overlaps in
intent with our Tablet token.
Dao suggests it would be nice to get
27 matches
Mail list logo
