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.
bokan@, kenneth.r.christiansen@, rune@
Allow authors to control the size of the initial containing block and viewport related properties using the CSS @viewport rule.
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
Low. It's a new feature.
Ongoing technical constraints
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
OWP launch tracking bug?
crbug.com/235457 tracks enabling @viewport but it's missing OWP labels.
Link to entry on the feature dashboard
Requesting approval to ship?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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?
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?
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.
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
With the proposal to remove min/max in favor of media queries,
@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.
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 ).
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?
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.