Re: [css-device-adaptation] Progress?

Hi,

> On 18 Feb 2015, at 00:41, David Bokan <bokan@chromium.org> wrote:
> 
> 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.


At the time where Opera was most actively working on css-device-adaptation, it wasn't a priority for other vendors, and then it was the other way around, so it's been receiving quite a bit less attention that it deserves. But if we have enough interest from IE and Chrome, it would be great to drive it to completion.

As a co-editor of that spec, I haven't been able to prioritize working on it in a long time, but maybe now is a good time to shake off the dust and get it done. I'll try to see if I can free up time to get it moving again, and hopefully to CR before too long.

> On 18 Feb 2015, at 03:42, Matt Rakow <marakow@microsoft.com> wrote:
> 
> 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.

and

> From: Christiansen, Kenneth R [mailto:kenneth.r.christiansen@intel.com] 
> 
> 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.

I completely agree that viewport cannot be activated on desktop due to the large body of content that assumes it will only ever be activated on mobile/tablets, and that given that @viewport is designed to work well in any kind of browser, it would be a shame to get it locked in the same situation, so I am really happy that you refrained from releasing it for mobile only.

Maybe adding a warning in the spec to encourage all early implementors to be as careful would be a good idea.

> 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'll have to look into that some more before I can make an intelligent response.

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

I agree. Min- and max- have a slight readability advantage over combining with media queries, but the new MQ range syntax cancels this out partly, and this is probably not worth the extra complications anyway, given that it does not bring any new capability.

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

I'll have to look into that some more before I can make an intelligent response.

> 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.

Interesting. Have you proposed these properties for standardization, or talked about them to other vendors? Without having looked into this too much, I'd agree with your statement that we probably only want one set of constrain on zooming, but it would be disappointing if different vendors picked different mechanisms.

If we all agree on other descriptors, but still want to argue the zoom ones out, maybe we can postpone them to level 2, and get the rest out sooner.

> 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.

Point taken.

> 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.

If you've worked (some of) this out while working on your implementation, do you have it written up in a form that you could share? I think we're clearly at a stage when the CSS specs in general have to start being more specific about the various types of zooms and their impact on various features, and I'd be all for incorporating relevant implementation experience into css-device-adapt.

 - Florian

> [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

Received on Wednesday, 18 February 2015 15:16:30 UTC