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



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

>> 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?
>
>If the idea is to remove the restriction in level 2, this will happen
>anyway, won't it?

Sure, but so what?

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.

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.

Moreover, if there are compelling use-cases then making this extension
optional seems very awkward since authors will need to make these
use-cases work cross-browser; how will they achieve that?

>
>The issue here is that only "width" and "height" totally make sense for
>documents that are not top-level (and, I believe, are desired to make css
>device adaptation suitable for responsive web design) while the others
>may 
>require heavier specification and implementation work (and some like
>'orientation' just do not make sense at all in an iframe). The aim of my
>proposal is to make sure browsers can implement the much-desired "width"
>and 
>"height" support for (non-seamless) iframes while not being blocked by
>the 
>slow work on the other properties.

I am not concerned about browser vendors being 'blocked', I am concerned
about authors being blocked. Optional means 'some browsers will do it
while others will not' for some time to come yet everyone can claim
conformance. Such a situation is very author-unfriendly. We should
prioritize authors who build across browsers; can they work around this
incompatibility? If so, at what cost? If the cost is low, then they can do
it today and it need not bother us in L1. If it can't be done it all
depends on the use-cases and implementor interest.

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

Received on Friday, 4 October 2013 15:40:45 UTC