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

Re: [css-device-adaptation] Progress?

From: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
Date: Wed, 18 Feb 2015 16:06:53 +0000
Message-ID: <CAEC208usS2yzs2A0qieqoQtJa=F0Z8zSKh1Jzp45P47jBDmBeA@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>, Matt Rakow <marakow@microsoft.com>
Cc: David Bokan <bokan@chromium.org>, "www-style@w3.org" <www-style@w3.org>, Rune Lillesveen <rune@opera.com>
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. "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.


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


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


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 16:07:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:51 UTC