W3C home > Mailing lists > Public > www-style@w3.org > February 2015

Re: [css-device-adaptation] Progress?

From: Rune Lillesveen <rune@opera.com>
Date: Thu, 19 Feb 2015 11:09:43 +0100
Message-ID: <CANz6XvR+oP6OZRTWhCFX3RkAenCWgbU0We2AVVYfd0Js+5uGZA@mail.gmail.com>
To: Matt Rakow <marakow@microsoft.com>
Cc: "Christiansen, Kenneth R" <kenneth.r.christiansen@intel.com>, David Bokan <bokan@chromium.org>, "www-style@w3.org" <www-style@w3.org>
On Tue, Feb 17, 2015 at 7:42 PM, Matt Rakow <marakow@microsoft.com> wrote:

> 1. "device-width" and "device-height" properties (or other named values with similar functionality, don't want to bikeshed on whether "device" is appropriate!) vs. 100%, 100vw, or "auto" property, latest thread: [1]

I've reported https://www.w3.org/Bugs/Public/show_bug.cgi?id=28056

> 2. The removal of min- and max- prefixes for width and height, latest thread: [2]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24906

This is sort of why my editing work stopped, because it means going
back to the drawing board, at least for the meta viewport mappings.

> 3. Behavior when both width and height are specified, latest thread: [3]

>>> IE already mostly (fully?) supports this through @-ms-viewport
> IE only supports width and height on desktop, plus the user-zoom value on phone.  The lack of support for the zoom properties is primarily because we have a separate set of properties for constraining zoom which are applied at the element level instead of at the document level [4].  This allows an author to specify a particular element on the page as zoomable, which can also be used to control the zooming of the document by application to the top level element.  We'd generally prefer not to have duplicative entry points to this behavior for simplicity, and the element-level property offers more scenario flexibility.
>
> Other feedback while I'm at it:  This spec would also benefit from clarifying visual vs. layout viewport where applicable.  For instance, the "actual viewport" maps well to the layout viewport, but the zoom properties constrain the visual viewport.

if I interpret you correctly, you would like to have a definition of a
"visual viewport" in chapter 3, and explain that in relation to zoom
and vice versa?

> This spec would also benefit from exploring in more depth the different types of zoom and their motivations.  E.g. zoom for DPI adjustment, zoom for user setting, zoom for "scale to fit" behaviors, zoom through user interactions, zoom that is persisted across navigation, zoom that is reset across navigation...  In IE we found that getting behavior that is acceptable to the user requires some reasoning about these in the constraining procedure.

I don't think we need a separate description for DPI adjustment, but
if necessary, refer to the description in
http://www.w3.org/TR/css3-values/#reference-pixel

By scale-to-fit, do you mean the handling of an auto value for zoom:
http://dev.w3.org/csswg/css-device-adapt/#handling-auto-zoom
or restricting zoom to not zoom further out than fitting the actual
content to the visual viewport?

> [1] http://lists.w3.org/Archives/Public/www-style/2013Dec/0320.html

I don't agree with what I said about having to reset descriptors
explicitly. I think an @viewport rule should completely override any
preceeding rules. I've reported
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28055

> [2] http://lists.w3.org/Archives/Public/www-style/2013Dec/0288.html
> [3] http://lists.w3.org/Archives/Public/www-style/2014Feb/0456.html
> [4] https://msdn.microsoft.com/en-us/library/windows/apps/hh996914.aspx

-- 
Rune Lillesveen
Received on Thursday, 19 February 2015 10:10:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC