- From: Matt Rakow <marakow@microsoft.com>
- Date: Tue, 17 Feb 2015 18:42:43 +0000
- To: "Christiansen, Kenneth R" <kenneth.r.christiansen@intel.com>, David Bokan <bokan@chromium.org>, "www-style@w3.org" <www-style@w3.org>
- CC: Rune Lillesveen <rune@opera.com>
It's great to hear Chrome might be interested in this feature! >> I can't see a path where we could enable the viewport <meta> on the desktop since it would break a large chunk of the web. We found this too in our investigation. One pattern that stood out in particular was sites that would redirect "phone-like" browsers to an m.* site, but leave "tablet-like" browsers on the main content which had a <meta> viewport with width=1024. The implicit assumption was that most tablets would work well with 1024px layout width, and desktop browsers wouldn't be affected negatively since they don't support <meta> viewport. >> I am pretty happy with how the spec is right now and I am not aware of any major issues, so I assume that the IE/spartan team is happy with the spec as well. Please chime in here :-) On the whole yes, very happy with the functionality and general direction of the spec. In particular the interaction with media queries is very useful. There are a couple items of feedback that I've given over the past couple years that I'm still interested in resolving though. In particular: 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] 2. The removal of min- and max- prefixes for width and height, latest thread: [2] 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. 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. Thanks, -Matt [1] http://lists.w3.org/Archives/Public/www-style/2013Dec/0320.html [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 From: Christiansen, Kenneth R [mailto:kenneth.r.christiansen@intel.com] Sent: Tuesday, February 17, 2015 7:53 AM To: David Bokan; www-style@w3.org Cc: Matt Rakow; Rune Lillesveen Subject: RE: [css-device-adaptation] Progress? Hi there Bokan, I am pretty happy with how the spec is right now and I am not aware of any major issues, so I assume that the IE/spartan team is happy with the spec as well. Please chime in here :-) The reason why we didn´t attempt to ship it in Chrome originally was due to the fact that not all platforms (ie Linux/GTK – now replaced by Linux/Aura) supported scaling the content using the compositor, and I personally wanted to enable it on all platforms at the same time in order to avoid it turning into a new viewport <meta> which people would put on their page and then see it break when being turned on on desktop. Cheers Kenneth From: bokan@google.com [mailto:bokan@google.com] On Behalf Of David Bokan Sent: Tuesday, February 17, 2015 4:41 PM To: www-style@w3.org Cc: Matt Rakow; Christiansen, Kenneth R; Rune Lillesveen Subject: [css-device-adaptation] Progress? As far as I can tell this spec hasn't made any progress in well over a year. Is there any interest in moving this forward and out of ED? IE already mostly (fully?) supports this through @-ms-viewport and I think we'd be interested in shipping this in Chrome as well. All desktop browsers now support pinch-zoom but there's currently no way to limit/disable it (try pinch-zooming on Google Maps before the touch handlers are registered to see why this is a problem). I can't see a path where we could enable the viewport <meta> on the desktop since it would break a large chunk of the web. @viewport looks to me like the best way forward to give authors a rational way to control the viewport across the entirety of the web. I'm happy to help out here in any way I can. Thanks, David
Received on Tuesday, 17 February 2015 18:43:12 UTC