Bug 61970 (zealvurte) - CSS 3 media queries device-width, device-height, width, and height are all handled incorrectly.
Summary: CSS 3 media queries device-width, device-height, width, and height are all ha...
Status: RESOLVED INVALID
Alias: zealvurte
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-02 14:59 PDT by Daniel Upstone
Modified: 2013-05-24 11:29 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Upstone 2011-06-02 14:59:46 PDT
device-width, device-height, width, and height do not follow the CSS 3 media queries spec correctly. On Android (and possibly iOS) device-width and device-height report the same as width and height. In all cases, none of these change when zooming to reflect the scaling of CSS units.

This may be a Webkit issue itself but i'm not 100% sure as i can't test on an iPhone.

It's well known that the device-width/height reported for Android's browser incorrectly uses the value of the virtual viewport (Which is also known to be larger than the true device dimensions), not the device-width/height itself. This has required designers to use a HTML meta tag to tell the viewport to equal the device-width to force the device's dimensions to report correctly (The device-width/height and viewport width/height are already equal, so this itself is nonsensical owing to the fact that device-width/height is not the true value used internally.).

This should not be a necessary requirement of designers, as the same result would be achieved more easily and effectively if only the true value was returned instead. We do not even need to know the px to pixels ratio either, as this should be a transparent process to CSS when you implement DPI awareness, as as such be reported by the resolution media query correctly for DPI adjustment (Not zoom scaling!).

A secondary bug is that the device-width/height and width/height do not change when using a zoom function. Scaling changes the relationship of a CSS px unit to the physical pixel, and the values reported in CSS 3 media queries use CSS units, so as the page is zoomed in less of these units make up the device's rendering surface, so the device-width/height should report a reduced size.
As the viewport on Android is normaly greater than device's rendering surface and thus virtual it need not be expected that the value of the viewport width/height change if the viewport is changing in size along with the content (I don't know the mechanics of this, so i don't know if that is effectively true.), but on the desktop and when android is using viewport of the same size as the device, the viewport does not change size when zooming, so it too should change it's reported value as you zoom.

This would allow designers to create flexible designs with absolute units and follow the draft media queries spec correctly, without the need to target specific devices or causing scrolling where it is not needed.

For some extra reading on the complexities of the issue and some quick tests:
http://static.zealous-studios.co.uk/projects/web_tests/PPI%20tests.html
http://static.zealous-studios.co.uk/projects/web_tests/units%20and%20media%20queries.html
Comment 1 Daniel Upstone 2011-06-02 15:21:48 PDT
*-(Not zoom scaling!)
Don't know what i was thinking there.
Comment 2 Alexey Proskuryakov 2011-06-02 22:33:02 PDT
Since Android is not built directly from webkit.org source code, we can't track bugs that are unique to it here. Please report this to Google.
Comment 3 Daniel Upstone 2011-06-03 05:08:31 PDT
I have done so, but Safari exhibits the same secondary bug behaviour as Chrome, so that appears to be a Webkit bug.

I can only assume the iPhone exhibits the same behaviour as Andriod, as the meta tag originaly started out life on the iPhone for the same reasons as it's now used on Andriod, so again this appears to be a Webkit bug.
Comment 4 John Mellor 2013-05-24 11:11:50 PDT
> the device-width/height reported for Android's browser incorrectly uses the value of the virtual viewport

There is/was a bug that the legacy Android Browser would give a value for device-width measured in device-pixels instead of DIPs (see below for definition of DIPs). So on a 720x1280 Galaxy Nexus with a device-pixel-ratio of 2, it would return a device-width of 720 instead of 360. That bug has been fixed in Chrome for Android.

I've never seen any cases where it returns the size of the virtual viewport though. I suspect you were just seeing the issue above.

> A secondary bug is that the device-width/height and width/height do not change when using a zoom function.

It's very deliberate that the values of width and device-width expressions in media queries do not change when the user pinch zooms. Pinch zooming is a way for the user to temporarily enlarge part of the page; it is not intended to change the layout of the page.

Although CSS always claims to use CSS pixels for everything, CSS is actually just ambiguous. About half the time that they refer to CSS pixels, they really mean "device-independent pixels" (DIPs), which are a fixed multiple of device pixels. For example if window.devicePixelRatio is 2, each DIP is a 2x2 block of device pixels. This is the unit that CSS usually intends when it talks about window sizes. And the width in DIPs of the device doesn't change when you pinch zoom. I agree that it's really confusing for CSS to use the same name to refer to two different units - I encourage you to raise this on www-style.
Comment 5 John Mellor 2013-05-24 11:13:37 PDT
(I do however agree that the width media query should change when you use full page zoom in a desktop browser, and I've fixed bug 53186, so that should now work).
Comment 6 Daniel Upstone 2013-05-24 11:29:10 PDT
Pretty sure DIPs are not intended to be part of CSS at all and specific to implementations as an interpretation of the spec, before they were defined to be CSS pixels (which are device independent anyway, but aren't always accurate thanks to use of DIPs). The DIPs are actually the problem I was referring to with the virtual viewport. It's not the true value and just an abstraction to create DPI thresholds for the OS.

If the zoom for Android is only ever meant to be that type of zoom, then fine (mentioned this for no viewport declarations, but it seems unintuitive when the viewport size is requested to be fixed), but that does mean implementing a zoom that does change layout for accessibility in web apps (and anything else) is not as easy as it should be.

Glad to see the desktop zoom fix though, thanks.