- 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