Re: [css-device-adaptation] Progress?

On Thu, Feb 26, 2015 at 5:10 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
>
>
>
> On Feb 26, 2015, at 2:18 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>
> A standard based note is not likely to have high visibility. A console
> warning might be more effective.
>
>
>>
>> [...]
>
>
>>>
>> All in all, I see that there's a valid use case for permitting @viewport
> rules in external styles other than mere convenience.
> So, perhaps limiting @viewport rules to be one of the first rules in an
> external style (along with @charset and @import) would be enough,
>
>
> Well, let's see: since there could be more than one @media with @viewport
> inside it, your restriction could theoretically say that @viewport cannot
> appear outside a dimension-based or zoom-based @media (or similarly
> restricted linked style sheet in html) unless the @viewport came before
> that. And that @viewport would be invalidated by any 'image-set()' property
> (or html with image-set attribute) that came before it in the same level of
> @media embedding. Or something like that.
>
> But I don't think it's worth it to have such a complicated restriction,
> and too draconian to restrict it even more generally. It's just going to
> break the author's design in ways the author won't understand or
> appreciate.
>
> And I think the value of such restrictions would be pretty limited anyway.
> Image loading from image-set should happen after complete style sheet
> parsing and cascading anyway, and multiple width-based @media rules are
> already parsed and held in memory anyway on UAs that have resizable
> windows.
>
> At most, an author might defeat some small optimization in a mobile UA
> with only two default viewport sizes (one for vertical and one for
> horizontal). That UA might just have to hold onto the other @media blocks
> during the parsing stage, and at worst might pull in some more style sheets
> via @import inside @media. But that is no worse than letting an author
> include dozens of @import calls to the server in existing practice, or
> having a super large stylesheet full of countless overrides, neither of
> which is currently restricted by CSS.
>

Just so we're clear, the performance cost I'm talking about is not related
to image-set or to CSS background images. It's related to content images
(using srcset `w` and <picture>) and to a lesser extent, the style sheets
themselves. (And any future resource which loading would depend on viewport
dimensions)

Is there a particular use-case that mandates that @viewport must be
supported inside @media rules?

>From the spec, I see:
"It is recommended that authors do not write @viewport rules that rely on
media queries whose evaluation is affected by viewport descriptors. Is is
also recommended that the @viewport rule(s) is placed as early in the
document as possible to avoid unnecessary re-evaluation of media queries or
reflows."

Why not enforce it by rules similar to @import? (unless there are important
use-cases that I'm missing)


>
> if coupled with user agent scanning those files to extract these rules,
>
>
> Sure, but an optimization like that is beyond the authority of this
> working group.
>

Of course, as long as we make sure that it's feasible.


>
> along with console warnings of possible performance issues.
>
>
> That would be fine with me, or maybe it could be in something like YSlow
> or in the Audits panel of Chrome's developer tools frame, but I don't think
> we can mandate it.
>

Sure.