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
___
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 Mon, Nov 19, 2012 at 10:41 PM, Jonas Sicking wrote:
> On Tue, Nov 13, 2012 at 8:37 AM, 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 se
On Tue, Nov 13, 2012 at 8:37 AM, 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 to be clear, th
On Tue, Nov 13, 2012 at 2:46 PM, Dao wrote:
> 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 te
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
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 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 alternativ
On 12/11/12 16:36, jim.math...@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 t
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 som
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 wan
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
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 HTT
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. Websit
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
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 wan
On Mon, Nov 12, 2012 at 7:51 AM, Gervase Markham 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
On Mon, Nov 12, 2012 at 8:05 PM, Matt Brubeck 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
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
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 w
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
On Mon, Nov 12, 2012 at 8:12 AM, Gervase Markham 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 scre
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 t
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
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_ pr
On Mon, Nov 12, 2012 at 4:51 PM, 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), plus the new pile of
> touch-enabled
26 matches
Mail list logo
