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

On Thursday 2013-10-03 14:23 +0200, François REMY 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.

I'm not convinced that this use case and having <meta viewport> in
CSS should be addressed by the same feature.  I think Rune's point
here:
> name=viewport> only apply to top level documents. It's straightforward
> to apply the width and height to frames and iframes, but it isn't
> obvious to me how independent pinch zoom for frames and the top level
> document should work. Discussion could be revived if there will be a
> level 2 of the spec.
seems like a real concern to me.  It seems like some of the features
of @viewport can work in subframes, but others can't.

I think there's also the concern that <meta viewport> is itself a
compatibility feature; it's essentially a way for pages to opt out
of the (necessarily) default assumption that the page wasn't
designed to work on small screens, or to modify (e.g., with a
different default width) the adjustments that implementations
perform (dual viewports, with pan and zoom linking them) that are
done so that users can view pages designed only for large screens on
small ones.  (It also covers up the fact that there isn't any other
pan-and-zoom primitive on the Web platform, something that's
probably worth rectifying on its own!)

I think the feature you're proposing makes sense on desktop browsers
as well, whereas a major reason for the existence of <meta viewport>
is that it *doesn't* work on desktop browsers.

Then again, it may be possible to combine all of these (having
@viewport rules that are mobile only and rules that are for all
screens, having @viewport rules for subframes that only support a
subset of features) into one spec in a reasonable way.  It sounds
like something that's worth trying, but I won't believe it until I
see it done.

On Thursday 2013-10-03 06:20 -0700, Sylvain Galineau wrote:
> On 10/3/13 5:56 AM, "Kenneth Rohde Christiansen" <kenneth.christiansen@gmail.com> wrote:
> >I think it is fine to push that to a level 2.
> 
> That was my first inclination but this is a constraint, not an additional
> feature. It's a lot easier to loosen a constrain in a future level than
> the reverse.

I'm having trouble telling whether Sylvain is agreeing or
disagreeing here, but either way I'd like to point out that relaxing
constraints can cause compatibility problems.  It's certainly less
risky than functional changes, but for features that have been
around a long time, the Web tends to end up with pages using
features in a way that doesn't do anything.  These are sometimes the
result of author attempts that didn't work, but weren't removed from
the page.  So making those things suddenly do something can break
pages.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)