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



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
>documents
>|  2. <meta viewport> is very widely used
>|
>|  Thus saying the feature has too little value if constrained to
>top-level
>|  documents is demonstrably invalid.
>
>If I'm an author, why would I use @viewport if I can do the same using
>the 
>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
>viewport 
>width=480 media=(max-width:700px)><meta viewport width=800
>media=(max-width:1023px)><meta viewport width=device-width
>media=(min-width:1024px)>").

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
>but 
>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
>it 
>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
>already 
>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,
>already
>|  taken far too long given its prevalence. Delaying it further to extend
>its
>|  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
>to
>|  >take it, I just didn't find any other. If implementors are OK
>supporting
>|  >"(min-|max-)?(width|height)" in level 1 already, I think another such
>|  >option
>|  >would be "To the notable exception of the 'width' and 'height'
>properties
>|  >(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
>@viewport
>|  support in iframes is something that should be optional. It would also
>be
>|  my preference to see today's interop standardized quickly and then
>build
>|  on it.
>
>Well, as far as I know, the only 'latest released version' of a browser
>that 
>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