Re: [css-device-adaptation] Progress?

Hi there,

On Wed Feb 18 2015 at 4:20:08 PM Florian Rivoal <florian@rivoal.net> wrote:

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

That sounds good!


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


> > 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 guess we could discuss these issues in Bugzilla (or GitHub as other newer
specs). As vw/vh becomes relative to the actual viewport they might be
confusing, even if they are relative to the initial viewport. I guess that
is the same for %.


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

Right

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

This is also super confusing with viewport meta, so we better get it right.


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

How does that work together with the viewport meta constraints then?


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

Are they as easy to integrate with media queries and do you have examples
on how they integrate with @viewport (and MQ?)


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

We also want to remove orientation which is already covered by the Screen
Orientation API + Web App Manifest (which can set default orientation)


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

+1

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

Add fixed-sized games. Aspect ratio?

Kenneth

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