W3C home > Mailing lists > Public > www-style@w3.org > October 2013

Re: [css-device-adapt] Apply @viewport to top-level documents only

From: Sylvain Galineau <galineau@adobe.com>
Date: Fri, 4 Oct 2013 10:48:01 -0700
To: François REMY <francois.remy.dev@outlook.com>
CC: www-style list <www-style@w3.org>
Message-ID: <CE744BE1.DC4C%galineau@adobe.com>

On 10/4/13 9:15 AM, "François REMY" <francois.remy.dev@outlook.com> wrote:

>|  Today, both the following are true:
>|  1. Implementations of <meta viewport> constrain it to top-level
>|  2. <meta viewport> is very widely used
>|  Thus saying the feature has too little value if constrained to
>|  documents is demonstrably invalid.
>If I'm an author, why would I use @viewport if I can do the same using
>meta tag? @viewport provides about the same feature set but will be
>supported on fewer browsers.
>My lecture of @viewport is that it is an improvement over the meta tag
>because (1) it will be standardized and (2) you can put it into an @media
>and use it for really-responsive web design (i.e. a sort of "<meta
>width=480 media=(max-width:700px)><meta viewport width=800
>media=(max-width:1023px)><meta viewport width=device-width

You've answered your own question :) And you've proven there is excellent
value for an L1 already.

Also, authors will also use it if that's the one that gets extended to
support sub-documents and who knows what else in the future.

>Granted, if that doesn't work in an iframe, that doesn't make the feature
>completely unusable because iframes have become less frequent over time
>it does make it impractical for some classes of use cases: (a) html
>presentations (b) fixed-aspect-ratio games (c) widgets. Right now, those
>rely on a JavaScript to apply a scale transform on the <body> element to
>make it fit the page so there's a way around the lack of the feature but
>is a script-based one.
>By the way, SVG documents support this kind of automatic rescaling by
>default, using their own "viewport" mechanism. It's quite clear that SVG
>often loads in IFRAMEs so the feature must be supported in some way
>by all browsers.

'In some way already' translates to 'yikes, it's not quite what we want'
more often than not.

Again, I am *not* arguing about feasibility. My only concern here is about
having optional behavior; that is usually a standard anti-pattern that is
best avoided in most cases. I do not yet see an argument that suggests
this should be an exception.

>|  In addition, documenting and standardizing this feature has, imo,
>|  taken far too long given its prevalence. Delaying it further to extend
>|  scope requires, I think, compelling use-cases and implementor interest.
>Width and height support in iframes requires no particular spec work,
>only a 
>tiny implementation effort.
>|  >If there's another option that satisfy this premise, I'm more than ok
>|  >take it, I just didn't find any other. If implementors are OK
>|  >"(min-|max-)?(width|height)" in level 1 already, I think another such
>|  >option
>|  >would be "To the notable exception of the 'width' and 'height'
>|  >(which must work anywhere), declarations in @viewport rules should be
>|  >applied on top-level documents only".
>|  Indeed, this is up to implementors. To be very explicit, I do not care
>|  whether this happens in L1, L2 or Lx. I just do not think having
>|  support in iframes is something that should be optional. It would also
>|  my preference to see today's interop standardized quickly and then
>|  on it.
>Well, as far as I know, the only 'latest released version' of a browser
>supports @viewport is IE, and it supports it in a prefixed fashion only.
>If the webkit and gecko implementation are made according to the spec and
>the spec requires "width" and "height" to work in iframes, and the next
>version of IE make the slight adjustement before unprefixing, the result
>will be that all unprefixed implementation will support
>@viewport{width/height} in iframes. If the effort required to support
>'width' and 'height' in iframes is small (I believe it is), this is maybe
>the best way forward.

"If.., if.., and if… If…" We should not write specs based on speculative
expectations of what implementors might do. 

Received on Friday, 4 October 2013 17:48:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:02 UTC