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

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

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

Received on Friday, 4 October 2013 16:15:54 UTC