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

On Fri, Oct 4, 2013 at 2:37 PM, 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?

I don't know about any issues with width and height in Blink (or Presto :-/ ).

Mutliple zoom factors would be a fair amount of work, but I don't know
about any fundamental problems off the top of my head.

> 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.
>
> Would that be an acceptable compromise?

Yes. In fact the Conformance section already says that a UA can ignore
the resolved zoom values and still conform. A UA may for instance lack
zoom capabilities. It does however require that width and height is
applied. The current text may already be sufficient, or it needs to be
said explicitly that you could apply zoom in top level documents and
not iframes?

It would be good to hear from other implementors.

Iframes should most likely not have any UA styles, btw. Narrow iframes
have been used in desktop/traditional browsers for a long time with a
viewport given by the iframe size.

Regarding multiple zoom factors and user interaction, you already have
a solution to a similar issue with touch based interfaces and nested
scrollable containers. If you load [1] in a Blink-based browser, you
need to scroll through the whole inner div before you can reach the
end of the document. You could do something similar for zooming. If
you're zoomed in on an iframe, you'd have to zoom all the way out
before you start zooming out the top level document. But that topic
calls for another mail thread, I think.

[1] http://people.opera.com/rune/scroll.html

-- 
Rune Lillesveen

Received on Friday, 4 October 2013 13:40:50 UTC