Intent to Implement: @viewport

[David Bokan]

This is an unusual intent to implement in that the feature already has a working implementation in Chromium. It was implemented almost 2 years ago (before the OWP launch process) by Rune and Kenneth but it's been stalled since. We (myself on behalf of the input-dev team) would like to push this to completion as a rational and specified way to control the viewport on all platforms. I'm sending this out to give the community a chance to comment or raise objections before moving this forward.

Contact emails

bokan@, kenneth.r.christiansen@, rune@

Spec

http://dev.w3.org/csswg/css-device-adapt/

Summary

Allow authors to control the size of the initial containing block and viewport related properties using the CSS @viewport rule.

Motivation

Authors are currently required to use <meta name="viewport> tag which is quirky (http://www.quirksmode.org/mobile/metaviewport/) and unspecified. More importantly, it doesn't affect desktop browsers. @viewport is meant to apply to all browsers. e.g. crbug.com/455471

Compatibility Risk

Low. It's a new feature.

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug?

crbug.com/235457 tracks enabling @viewport but it's missing OWP labels.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4737164243894272

Requesting approval to ship?

No

[PhistucK]

Implemented - but not shipped, right?

And I think it was implemented as prefixed, but I am not sure.

This looks good to me. However, if Apple is not going to implement it, how is that any different than pointer events?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[David Bokan]

Right, we implemented it but didn't ship. Our implementation is unprefixed (MS currently ships a prefixed @-ms-viewport).

I think it differs from pointer events in that the implementation burden is much smaller and this can co-exist with viewport meta (we don't plan on removing viewport meta support). Viewport meta can be directly translated to @viewport and so they can use the same internal representation (in fact, that's what our implementation does.) 

[Chris Harrelson]

A couple of questions:

1. Is there any interesting new behavior that is not possible with the <meta name="viewport"> system?

2. Why exactly was <meta name="viewport> never specified? I guess the working group thought it was inferior to the @viewport approach?

[David Bokan]

A couple of questions:

1. Is there any interesting new behavior that is not possible with the <meta name="viewport"> system?

 

Yes. Interaction with the media query system and being able to load the rule from an external stylesheet are two things I know of. rune@ may know the details and differences better.

2. Why exactly was <meta name="viewport> never specified? I guess the working group thought it was inferior to the @viewport approach?

rune@ would have to comment on this since I wasn't involved at that point. That said, viewport meta would be impossible to enable on desktop browsers today since so many pages have placed them with the expectation that desktop browsers will ignore it.

[Chris Harrelson]

Thanks.

LGTM

[Philip Rogers]

Does this enable text autosizing on desktop browsers with @viewport?

[David Bokan]

No, I believe that's behind a separate flag.

[Philip Rogers]

I worry that we are further torturing web developers with the viewport / autosizing confusion because there's still no viewport configuration that will result in consistent rendering across desktop and mobile. This seems like an opportunity to fix that by enabling autosizing on desktop for the handful of edge cases where a viewport doesn't disable autosizing on mobile.

+cc johnme, skobes

[David Bokan]

I don't disagree, I meant in terms of implementation the two features aren't tied together and the decision to enable autosizing could be made separately. Is there any reason we would need to ship both at the same time?

[Steve Kobes]

I may be missing some context.  Why would we want text autosizing on desktop browsers, ever?

[Alexandre Elias]

I think pdr@ has a good point that text autosizing is one of the major remaining causes of platform-specific rendering differences.  There's no way to enable it on desktop, and the way to disable it on mobile is a bit implicit/magical (set viewport width=device-width, which on the surface doesn't seem related to font sizes).

Given that all the major mobile browsers have some concept of text autosizing, one idea would be to add a keyword to explicitly disable it in the @viewport spec, and also to spec out the cases where it will be implicitly disabled.  (I don't think we should add any method to explicitly *enable* it on desktop, because the usefulness is low, and I expect other vendors who have forked codebases would find that difficult to support.)

[Simon Pieters]

On Mon, 02 Mar 2015 19:51:49 +0100, Chris Harrelson
<chri...@chromium.org> wrote:

> 2. Why exactly was <meta name="viewport> never specified? I guess the
> working group thought it was inferior to the @viewport approach?

It's specified here:

http://dev.w3.org/csswg/css-device-adapt/#viewport-meta

(It's not normative but I think that is a spec bug, it should be normative
and required for browsers at least.)

--
Simon Pieters
Opera Software

[Yoav Weiss]

On Mon, Mar 2, 2015 at 8:21 PM, 'David Bokan' via blink-dev <blin...@chromium.org> wrote:

A couple of questions:

1. Is there any interesting new behavior that is not possible with the <meta name="viewport"> system?

 

Yes. Interaction with the media query system and being able to load the rule from an external stylesheet are two things I know of. rune@ may know the details and differences better.

 

I've raised my concerns with regard to both of these on the www-style list.

IMO, the ability to load rules from an external style can cause performance issues, since it can invalidate resources that were downloaded relative to the viewport dimensions (mostly <picture>/srcset based images) at a fairly late stage of the page's loading.

I believe that it'd be better to restrict them to the style's first set of rules (similarly to @charset and @import) at the very least. That would significantly reduce the chances of downloading the wrong image/style (and whatever future resources that we'd be downloading based on viewport dimensions).

With regard to reliance on MQs, I think the solution to the circularity issues (evaluate MQs with @viewport in them relative to the initial viewport) rather confusing as a user.

[Rune Lillesveen]

On Mon, Mar 2, 2015 at 8:21 PM, David Bokan <bo...@google.com> wrote:
>> A couple of questions:
>>
>> 1. Is there any interesting new behavior that is not possible with the
>> <meta name="viewport"> system?
>
>
> Yes. Interaction with the media query system and being able to load the rule
> from an external stylesheet are two things I know of. rune@ may know the
> details and differences better.
>
>> 2. Why exactly was <meta name="viewport> never specified? I guess the
>> working group thought it was inferior to the @viewport approach?
>
> rune@ would have to comment on this since I wasn't involved at that point.
> That said, viewport meta would be impossible to enable on desktop browsers
> today since so many pages have placed them with the expectation that desktop
> browsers will ignore it.

I don't remember exactly our rationale for not simply specify <meta
viewport>. The background was that we needed to support <meta
viewport> in Presto and documented the behavior, based on testing
Safari, for internal purposes. Then we proposed a css syntax for it.
I've tried to dig into old mail without finding a rationale. There was
already an @page doing something similar paged media, though.

Currently, as part of css-device-adapt, there is a specification for
<meta viewport> in terms of @viewport rules.

--
Rune Lillesveen

[Rune Lillesveen]

On Tue, Mar 3, 2015 at 2:08 AM, Yoav Weiss <yo...@yoav.ws> wrote:
>
> On Mon, Mar 2, 2015 at 8:21 PM, 'David Bokan' via blink-dev
> <blin...@chromium.org> wrote:
>>>
>>> A couple of questions:
>>>
>>> 1. Is there any interesting new behavior that is not possible with the
>>> <meta name="viewport"> system?
>>
>>
>> Yes. Interaction with the media query system and being able to load the
>> rule from an external stylesheet are two things I know of. rune@ may know
>> the details and differences better.

> I believe that it'd be better to restrict them to the style's first set of
> rules (similarly to @charset and @import) at the very least. That would
> significantly reduce the chances of downloading the wrong image/style (and
> whatever future resources that we'd be downloading based on viewport
> dimensions).

With the proposal to remove min/max in favor of media queries[1],
@viewport can be inside @media, and @media does not have to precede
style rules. We should take this discussion to www-style, though.

> With regard to reliance on MQs, I think the solution to the circularity
> issues (evaluate MQs with @viewport in them relative to the initial
> viewport) rather confusing as a user.

Do you have a better proposal for interpreting viewport-relative media
queries, or is this just an argument in favor of <meta viewport> and
dropping @viewport altogether?

Given that we drop min/max descriptors for @media, the currently
specified way of evaluating media queries is the way it has to be
done, I think.

[1] https://lists.w3.org/Archives/Public/www-style/2013Dec/0288.html

--
Rune Lillesveen

[Yoav Weiss]

On Tue, Mar 3, 2015 at 10:15 AM, Rune Lillesveen <ru...@opera.com> wrote:

On Tue, Mar 3, 2015 at 2:08 AM, Yoav Weiss <yo...@yoav.ws> wrote:
>
> On Mon, Mar 2, 2015 at 8:21 PM, 'David Bokan' via blink-dev
> <blin...@chromium.org> wrote:
>>>
>>> A couple of questions:
>>>
>>> 1. Is there any interesting new behavior that is not possible with the
>>> <meta name="viewport"> system?
>>
>>
>> Yes. Interaction with the media query system and being able to load the
>> rule from an external stylesheet are two things I know of. rune@ may know
>> the details and differences better.

> I believe that it'd be better to restrict them to the style's first set of
> rules (similarly to @charset and @import) at the very least. That would
> significantly reduce the chances of downloading the wrong image/style (and
> whatever future resources that we'd be downloading based on viewport
> dimensions).

With the proposal to remove min/max in favor of media queries[1],
@viewport can be inside @media, and @media does not have to precede
style rules. We should take this discussion to www-style, though.

Yeah, will do.

> With regard to reliance on MQs, I think the solution to the circularity
> issues (evaluate MQs with @viewport in them relative to the initial
> viewport) rather confusing as a user.

Do you have a better proposal for interpreting viewport-relative media
queries, or is this just an argument in favor of <meta viewport> and
dropping @viewport altogether?

Personally, I have to wonder if the complexity/foot-guns @viewport brings is worth its benefits.

But I also think that the MQ situation can be simplified.

 

I find that in examples like:

```

@media screen and (max-width: 400px) {

    @viewport {

        width: 500px;

    }

    background: red;

} 

```

on a 320px wide initial viewport, the fact that the background is not red, but the viewport rule is applied would surprise a lot of people.

OTOH, maybe if we turn that around and have MQs inside of @viewport, that would be less confusing, and allow us to force @viewport to be in a manageable (and more likely to be optimizable) place.

So we would do something like:

```

@viewport {

    @media screen and (max-width: 400px) {

        width: 500px;

    }

} 

```

We can then safely ignore irrelevant rules inside, and it'd be way easier to explain "MQs inside viewport are calculated differently" then the current situation.

 

Given that we drop min/max descriptors for @media, the currently
specified way of evaluating media queries is the way it has to be
done, I think.

[1] https://lists.w3.org/Archives/Public/www-style/2013Dec/0288.html

--
Rune Lillesveen

[Rune Lillesveen]

On Tue, Mar 3, 2015 at 4:41 PM, Yoav Weiss <yo...@yoav.ws> wrote:

> On Tue, Mar 3, 2015 at 10:15 AM, Rune Lillesveen <ru...@opera.com> wrote:

> So we would do something like:
> ```
> @viewport {
> @media screen and (max-width: 400px) {
> width: 500px;
> }
> }
> ```
> We can then safely ignore irrelevant rules inside, and it'd be way easier to
> explain "MQs inside viewport are calculated differently" then the current
> situation.

You'd still have to handle:

<style media="(max-width: 400px)">@viewport { width: 500px; }</style>

which is effectively the same as:

<style>@media (max-width: 400px) { @viewport { width: 500px; } }</style>

--
Rune Lillesveen

[Rick Byers]

To pop back up for a second here, I think the key trade off is between fully specifying and tweaking the existing ugly API we have (viewport meta tag) and implementing/advocating a transition to something new and more rational.  In this regard, it IS very similar to the pointer events debate (but please, let's not derail this thread).

The key question is what important scenario does a new API enable that can't be done reasonably via extensions to the old API.  The thing that pushes me over the edge into supporting @viewport here is: "give developers control over the pinch-zoom behavior on desktop".  Right now there's no great way to disable pinch-zoom on desktop Chrome.  We tried honoring the meta viewport tag on desktop, but anecdotaly found a lot of popular sites that would appear broken on desktop (due to assumptions that the viewport tag would be honored only on small-screen devices).  One could argue that we could collect more concrete data on this to more precisely quantify the issue (eg. perhaps we could find a subset of viewport values we could safely honor on desktop).  My gut instinct from the data I've seen is that meta viewport is probably too broken (mobile-only-assumptions, interop issues, confusing design points) to justify trying to improve/fix it, given the cost to developers supporting both APIs is relatively low (eg. the API is small and the relationship to meta-viewport clear enough).  I also trust the thought / research the IE team put into this decision (+Matt in case he wants to weigh in with concrete data).  But this is a tough tradeoff to evaluate.  If anyone has suggestions on concrete data we could gather to help decide (eg. perhaps we should get feedback from some framework authors), that could be helpful.

That's the main question I think we should focus on in this thread.  If we agree that a new API is better for the web than focusing on fixing the current one, then Dave and others can ramp up discussions on the relevant W3C list about the API details (outstanding issues, etc.) and circle back here when they're happy.  If not, then it's not worth having those discussions at all.

Related question: has anyone tried to polyfill @viewport?  Or, more realistically, write a library that provides a common API built on top of both @viewport and meta viewport?  If we decide a new API is justified, should we perhaps be considering a more primitive JS API on top of which @viewport could be implemented (eg. via CSS parser extension hooks)?

Rick

[L. David Baron]

On Monday 2015-03-02 14:21 -0500, 'David Bokan' via blink-dev wrote:
> >
> > A couple of questions:
> >
> > 1. Is there any interesting new behavior that is not possible with the <meta
> > name="viewport"> system?
> >
>
> Yes. Interaction with the media query system and being able to load the
> rule from an external stylesheet are two things I know of. rune@ may know
> the details and differences better.
>
> 2. Why exactly was <meta name="viewport> never specified? I guess the
> > working group thought it was inferior to the @viewport approach?
> >
>
> rune@ would have to comment on this since I wasn't involved at that point.
> That said, viewport meta would be impossible to enable on desktop browsers
> today since so many pages have placed them with the expectation that
> desktop browsers will ignore it.

I'm a little concerned about hearing that it's going to be enabled
in desktop browsers -- or at least that it's going to be enabled
there without prose in the spec explaining what it's supposed to do
on desktop browsers. My original understanding of the spec was that
it was supposed to be a better replacement for <meta viewport>,
i.e., something to to control behavior that would only happen in
pan-and-zoom UIs on devices where the CSS viewport and the viewing
area were different.

I suppose on desktop Chrome the CSS viewport and the viewing area
can be different after the user has pinch-zoomed, but I don't think
they're *initially* different right now. Is this intended to change
that on desktop so that they sometimes start off different when the
page loads? (If so, what happens if the desktop browser doesn't
have pinch-zoom, or if the user doesn't know that it does or doesn't
have a device that makes it usable? And what's the defining
difference between desktop and mobile anyway?) It would be good for
the spec to say one way or another whether that's the case.

I think it would be helpful if the spec had more description about
how different sorts of implementations (e.g., mobile browsers with
pinch-zoom, desktop browsers with pinch-zoom, desktop browsers
without pinch-zoom) are expected to implement the spec, and if that
description had a chance to be discussed a little more among browser
vendors (before we end up with yet another viewport-specification
mechanism that we can't change). The spec currently feels a little
light to me on definitions of what's actually supposed to happen
when the spec's features are used in different situations, and that
seems to be a risk to future interoperability.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Rick Byers]

If we agree we want to restart investment in a new API like @viewport, then I agree these are really good questions to be discussing and gaining consensus on before anyone ships support for the (unprefixed) API.

My personal opinion is that we should be shifting from thinking in terms of desktop / mobile to thinking in terms of window size.  Eg. is there any good reason why Chrome's viewport behavior on a phone should be different from that in a phone-sized window on a desktop (especially when "pinch-zoom" functionality is available via a touchpad or touchscreen)?  We're making good progress towards pinch-zoom as the primary scaling mechanism across platforms (eg. our touchscreen pinch-zoom viewport behavior is now consistent across all platforms, and we recently updated Mac touchpad pinch-zoom to use the exact same code path), so increasingly it's the viewport meta tag that's the wart in the system.

The main reason to do @viewport IMHO is to have a chance to define something rational for any form factor, rather than rely on assumptions about mobile vs. desktop.  I can imagine applying some form-factor-specific defaults for compatibility though (eg. maybe you have to use @viewport to opt-in to viewport scaling on desktop, even though that's the default on mobile).

[Yoav Weiss]

+Ilya

I agree that the distinction between mobile and desktop is blurring and likely to get blurrier, so I'm all for addressing the "viewport directives for desktops" case (In a well-defined way that would alleviate David's concerns). I'd love for that to happen without introducing performance footguns though.

Furthermore, I think it'd be performance beneficial if the mechanism to do that will not be in CSS at all. I realize people have put a lot of effort into the device-adaptation spec, but I'd like us to rethink if CSS is indeed the right place for such directives before shipping anything.

For example, if we want to be able to control Resource-Hints and Preload using the `media` attribute (in both their markup and Link: header variants), we want this mechanism to be defined as an HTTP header (with a <meta http-equiv> for markup based control).

[Matt Rakow]

Re: “Can we fix up <meta> viewport” – we didn’t go that route in IE because we found that we couldn’t enable it on desktop without breaking a significant number of sites.  The primary blocker is fairly widespread usage of static widths on desktop sites.

 

We did a scan for <meta> viewport usage on the top 5k desktop sites almost a year ago.  We found ~1k of those sites had a <meta> viewport tag and ~200 were specifying some static width (which of course tends to get ridiculous on a desktop browser window that can be resized).  Of these static widths, about ~130 were in the range of 960-1024 with most of the remainder being values larger than 1024.

 

The common pattern that these sites seemed to be expecting was:

·         Phone users would be redirected to an m.* site

·         Desktop users would stay on the primary site, but wouldn’t be affected by the <meta> viewport

·         Tablet users would stay on the primary site, and get a “width=1024” viewport or similar.  This allowed the site developer to gloss over the slight discrepancies in tablet layout sizes since most tablets are in that ballpark.

o   Some would do further processing in script to fix layout breakages that the viewport rule incurred, but only if the UA string matched iPad, etc.

 

There were also a handful of sites that would get weird behaviors due to unusual usage of minimum/maximum/initial scale, though these were less prevalent (~20 of the top 5k).

 

Re: disabling pinch zoom, I’d rather do this through a separate property that can be controlled on a per-element basis (alluded to this in my last response to the thread on www-style [1]).

 

Thanks,

-Matt

 

[1] http://lists.w3.org/Archives/Public/www-style/2015Feb/0364.html

[Rune Lillesveen]

On Tue, Mar 3, 2015 at 2:08 AM, Yoav Weiss <yo...@yoav.ws> wrote:

> I've raised my concerns with regard to both of these on the www-style list.
> IMO, the ability to load rules from an external style can cause performance
> issues, since it can invalidate resources that were downloaded relative to
> the viewport dimensions (mostly <picture>/srcset based images) at a fairly
> late stage of the page's loading.

Should <picture>/srcset really depend on the actual viewport? Given a
case where you have:

Initial viewport width css px: 320
Initial viewport width physical px: 640

If you specify an actual viewport width with meta or @viewport, should
it matter if you use 2000px or 5000px?

Shouldn't 640px be the interesting number here?

--
Rune Lillesveen

[Rune Lillesveen]

I think I misunderstood. This is more of a layout issue where images
are picked to match the rest of the layout, typically influenced by
@media queries in the stylesheets as well.

--
Rune Lillesveen

[Yoav Weiss]

On Wed, Mar 11, 2015 at 4:59 AM, Rune Lillesveen <ru...@opera.com> wrote:

On Wed, Mar 11, 2015 at 11:51 AM, Rune Lillesveen <ru...@opera.com> wrote:
> On Tue, Mar 3, 2015 at 2:08 AM, Yoav Weiss <yo...@yoav.ws> wrote:
>
>> I've raised my concerns with regard to both of these on the www-style list.
>> IMO, the ability to load rules from an external style can cause performance
>> issues, since it can invalidate resources that were downloaded relative to
>> the viewport dimensions (mostly <picture>/srcset based images) at a fairly
>> late stage of the page's loading.
>
> Should <picture>/srcset really depend on the actual viewport? Given a
> case where you have:
>
> Initial viewport width css px: 320
> Initial viewport width physical px: 640
>
> If you specify an actual viewport width with meta or @viewport, should
> it matter if you use 2000px or 5000px?
>
> Shouldn't 640px be the interesting number here?

Interesting point. It's true that @viewport/<meta> viewport changes also result in inverse DPR changes, so as long as we take both into account, the actual images picked for srcset's 'w' descriptors won't change.

srcset x descriptors OTOH will download images with half the desired DPR, which may result in quality issues (rather than performance issues).

I think I misunderstood. This is more of a layout issue where images
are picked to match the rest of the layout, typically influenced by
@media queries in the stylesheets as well.

Exactly. In these cases the browser will have to double download.

Another potential issue is with <link media> that would get wrongly prioritized.