- From: Oren Freiberg <oren.freiberg@microsoft.com>
- Date: Fri, 25 Apr 2014 21:58:25 +0000
- To: Rick Byers <rbyers@chromium.org>
- CC: Tab Atkins Jr. <jackalmage@gmail.com>, François REMY <francois.remy.dev@outlook.com>, CSS WG <www-style@w3.org>
- Message-ID: <99e4b8930d074c028c14af2f854e3302@BY2PR03MB222.namprd03.prod.outlook.com>
From: rbyers@google.com [mailto:rbyers@google.com] On Behalf Of Rick Byers Sent: Friday, April 25, 2014 1:43 PM To: Oren Freiberg Cc: Tab Atkins Jr.; François REMY; CSS WG Subject: Re: [mediaqueries4]Differentiating touchscreen+mouse from touchscreen only scenarios On Fri, Apr 25, 2014 at 4:33 PM, Oren Freiberg <oren.freiberg@microsoft.com<mailto:oren.freiberg@microsoft.com>> wrote: From: rbyers@google.com<mailto:rbyers@google.com> [mailto:rbyers@google.com<mailto:rbyers@google.com>] On Behalf Of Rick Byers Sent: Friday, April 25, 2014 1:19 PM To: Tab Atkins Jr. Cc: François REMY; Oren Freiberg; CSS WG Subject: Re: [mediaqueries4]Differentiating touchscreen+mouse from touchscreen only scenarios On Fri, Apr 25, 2014 at 3:36 PM, Tab Atkins Jr. <jackalmage@gmail.com<mailto:jackalmage@gmail.com>> wrote: On Fri, Apr 25, 2014 at 12:32 PM, Rick Byers <rbyers@chromium.org<mailto:rbyers@chromium.org>> wrote: > On Thu, Apr 24, 2014 at 9:20 PM, Oren Freiberg <oren.freiberg@microsoft.com<mailto:oren.freiberg@microsoft.com>> > wrote: >> It seems Rick felt we should match both but it looks like Chrome never >> implemented it. Rick do you still feel the same way and plan on implementing >> a solution that supports matching both fine and coarse on a hybrid device? >> >> http://lists.w3.org/Archives/Public/www-style/2013Apr/0534.html > > I'd like to yes, but I didn't want to change anything here (or even finish > our implementation of this feature) until this was reflected in the spec > (indicating there was some kind of consensus here). My understanding from > my last discussion with Tab was that he planned to update the spec to > explicitly state that setting BOTH coarse and fine was OK when multiple > input devices are considered 'primary'. That was done some time ago, btw. ^_^ Oh awesome, I never noticed that this happened: "if there are multiple reasonable "primary" input mechanisms with different characteristics, UAs may make the feature match multiple values. " Great, thank you! > In general I haven't heard much interested from other vendors on these MQ > features, so I've been hesitant to commit ourselves beyond the minimal > pointer:coarse support we added. If IE was interested in these, I'm sure we > could quickly come to an agreement on behavior that we'd both implement :-) And if y'all agree on something more specific than what the spec currently suggests, please let me know so I can spec it. Sounds good. I was thinking we'd start by always setting 'coarse' on Android, 'fine' on Win/Mac/Linux/ChromeOS if a mouse/trackpad is detected, and 'coarse' on Win/Linux/ChromeOS if a touchscreen is detected. Does that sound reasonable? Can anyone comment on what IE might like to do? Again I think we might want to refine this over time (eg. we know some fraction of touchscreen laptop users almost never use their touchscreen, maybe we should detect them and report only 'fine' for those), so the spec shouldn't be too prescriptive. But I think it's reasonable to start by just reporting what devices we've found to be present. I was thinking of one of two approaches below. 1. We won't report touch on hybrid devices where it isn’t the primay form of input. It seems easier for a web dev if we just don’t report the coarse experience on these hybrid devices. The touch experience is also typically not the most used form of input. So on Win/Linux/ChromeOS where both a touch screen and track pad are detected ‘fine’ would be reported. 2. We will report both coarse and fine. This provides the most information which can be good for websites that are way better for one experience over the other. Yeah I like this better because it let's the site say what's important to them rather than us assuming there's one answer for all scenarios. In the limit I could imagine some sites wanting to expose a choice to the user (similar to how gmail provides different layout options in their UI and defaults to 'touch optimized' when pointer:coarse is set). The hybrid device experience is important to us so reporting just coarse on a hybrid device doesn’t sit well right now. The concern is those devices might get a mobile optimized experience. Exactly, that's in part what lead to our bug. In practice it's ONLY hybrid devices that people use this for on Chrome today (AFAIK), they're already in the habit of UA sniffing for mobile devices :-(. We chose not to modify our UA for touchscreen laptops (the way IE did) so felt we needed SOME signal developers could use to tweak their UI for touch (that's better than the broken behavior of looking to see if the browser supports touch events). One concern I have with supporting both that a team member brought up is that media features are said to behave like CSS properties. CSS properties have a single value. So media features should also have a single value. The point of the values being drawn from a set is that the items in the set should be mutually exclusive. If we take a look at every other discrete feature, the sets of things are mutually exclusive: {dim, normal, washed} {enabled, initial-only, none} {none, on-demand, hover} {none, slow, normal}, etc. Because of this I think we should add a new value like ‘hybrid’ which address that concern, getting mobile content on ‘coarse’ and is easy for web developers to understand. On ‘hybrid’ provide the user the choice where on ‘coarse’ do touch only and ‘fine’ optimize for mouse. The name might need some work but what are your thoughts?
Received on Friday, 25 April 2014 21:58:57 UTC