- From: Rune Lillesveen <rune@opera.com>
- Date: Wed, 29 May 2013 10:22:02 +0200
- To: "www-style list" <www-style@w3.org>
- Cc: aelias@chromium.org
There have been experimentation with enabling viewport meta for all products in Blink and I was brought into the discussion. Device-width and device-height works when the browser window uses the whole screen and isn't resizable. When you start to support @viewport (or viewport meta) in browsers where the window is smaller than the screen, you'll get undesireable results. The question is if there is really a need for device-width/device-height at all since the author would normally mean "@viewport { width: auto; height: auto; }" instead. The viewport meta background is that Safari and Presto, at least, have been truly using device-width and device-height as what they are: width and height of the device in CSS px. It's detectable for device-height as content="initial-scale=1" will give you an ICB height that subtracts the height of the UI chrome from the device-height, while content="height=device-height" will give you the height of the screen in CSS px regardless of the presence of UI chrome. Now, the current implementation in Blink will actually translate device-width/height to the width/height of the ICB established by the browser window showing no difference between content="initial-scale=1" and content="height". An important argument in favor of removing the support for the device-* values in @viewport is that authors would likely continue to use those values as they match what they're used to from viewport meta, which would be bad. PROPOSAL: Remove device-width and device-height from <viewport-length> and keep them in the viewport meta part. -- Rune Lillesveen
Received on Wednesday, 29 May 2013 08:22:32 UTC