| Summary: | pointer/hover media queries should update dynamically | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Rick Byers <rbyers> |
| Component: | CSS | Assignee: | Rick Byers <rbyers> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | abarth, jamesr, tonikitoo |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Rick Byers
2012-06-05 09:41:45 PDT
Adam/James - sounds like there is still debate over whether dynamic properties like touch/mouse belong in Settings or somewhere else. I'll plan leave them in Settings for now, unless we can come to some conclusion on where they should be instead. Settings can change over time. Many ports have APIs for manipulating settings that they expose to third parties. The notion that settings are static is just incorrect. Moving discussion from (mostly unrelated bug http://code.google.com/p/chromium/issues/detail?id=118173). Comment 18 by abarth@chromium.org, Today (57 minutes ago) ... Another interesting question is what to do about media queries when users plug and unplug a mouse from a touch-enabled device. Comment 19 by rbyers@chromium.org, Today (32 minutes ago) I've been assuming that plugging and unplugging a device is essentially the same (on the WK side anyway) as moving a window between a touch and non-touch screen. I was hoping we could just update the setting and trigger style recalc. Comment 20 by jamesr@chromium.org, Today (12 minutes ago) That's one interpretation, but it's not immediately obvious that it's the behavior we want - imagine some sort of bluetooth mouse that periodically gains/loses its connection, do we want to be constantly toggling this setting and perhaps changing the style on the page? --- That's an interesting scenario. I'm not sure how realistic it is that the ONLY mouse/trackpad device is that flaky (seems like the occasional website changing styles is perhaps the least of the user's frustration in this case). But the media query spec is intentionally worded to give the UA some freedom to determine what pointer it expects the user to use ("primary pointing device"). If such a case was an issue in practice, perhaps we need some heuristic so such a mouse isn't considered a primary pointer? At least that way the behavior will be more consistent (eg. opening a link to the same site in a new tab won't show different UI). This comes back to something I've been wondering about in the current implementation: what's the right level of abstraction here in the WebKit API. Do we really want WebCore to have the responsibility of determining the "least capable primary pointer device" based on low-level present/absent bits from the platform. Or is it better to plumb the entire decision up to the platform with a single 'getLeastCapablePrimaryPointer' API. One way to think about those sorts of questions is to consider how you would approach this problem if you were programming directly to the Mac OS or iOS APIs rather than to a Chromium abstraction of the real OS APIs. *** This bug has been marked as a duplicate of bug 134822 *** |