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



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

>> > I don't think this is a good idea. I think one of the main use case of
>> > @viewport is to be embedded into @media to fallback to a known amount
>>of
>> > fixed-size layouts even under any real pixel size as viewport, or for
>> > slide
>> > decks this is a way to make sure your content is always rendered
>>under a
>> > fixed-size resolution and "scaled-to-fit" into the user browser.
>> > Documents
>> > inside an iframe totally want this behavior to continue to work.
>>
>> There is no "continue to work" here as this has not been supported by
>> implementations before AFAIK (meta viewport or prefixed @viewport).
>> I'm worried about the progression of the spec and the implementations.
>> So my proposal is to postpone to a level 2.
>
>Wouldn't it be better to simply fix the implementations? Just to
>understand 
>the concerns, how hard would that be?
>
>If I have a look at the samples at [1] which is the reference of the
>@viewport at-rule, I'm afraid to say any website relying on any of those
>@viewport examples will break in an iframe. This is a huge fail according
>to 
>me.  If the goal is to provide an alternative to <meta viewport> that is
>not 
>more reliable than <meta viewport> (i.e. that is unsuitable for any RWD
>purpose), as a web author I think this is kinda sad.
>
>If the concern is the impossibility to make the spec progresses further
>down 
>the standardization track because of lack of implementation supporting
>this 
>feature right now, would it be possible to rewrite the statement as a MAY?
>
>-- User agents MAY not apply certain @viewport declarations
>-- on non-top-level documents, at the UA discretion. It is
>-- however recommended to support the "width" and "height"
>-- properties even in those documents.
>
>This makes it possible for browser to support "width" and "height" only
>without being in contradiction with the spec, while still making the
>feature 
>optional which enables to count current implementation in the
>standardization track.

Optional support effectively makes UA incompatibility conformant. It
doesn't mean we shouldn't do it but aside from assertions of a 'huge fail'
I do not think it's clear why the benefits are worth the potential compat
pain for authors?

Received on Friday, 4 October 2013 14:30:35 UTC