W3C home > Mailing lists > Public > www-style@w3.org > February 2015

Re: [css-device-adaptation] Progress?

From: Brad Kemper <brad.kemper@gmail.com>
Date: Thu, 26 Feb 2015 10:55:05 -0800
Cc: Rune Lillesveen <rune@opera.com>, Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>, Florian Rivoal <florian@rivoal.net>, Matt Rakow <marakow@microsoft.com>, David Bokan <bokan@chromium.org>, "www-style@w3.org" <www-style@w3.org>
Message-Id: <A628C49F-2984-45A6-A299-3325FD278831@gmail.com>
To: Yoav Weiss <yoav@yoav.ws>

> On Feb 26, 2015, at 8:52 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>> 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)

I still don't see the problem of just not loading the images until after the CSS has been parsed and cascaded. At that point, you would know which images to fetch. If you are pre-loading based on viewpoint assumptions, then just stop once the  assumptions prove false. 

PS: the length of the vw, vh, etc. units don't need to be resolved until after the cascade stage either. 

Adding a stylesheet via JavaScript or something after the page has loaded is more unusual, and will have performance implications regardless. 

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

Yes. I might want the viewport scaled somewhat for vary narrow screens (phones), but unscaled for iPads and desktop. I've personally run into this limitation of the meta tag, and it's frustrating. 

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

I think the restriction on @import was a mistake. Why am I allowed to do this:

<link href=a.css rel=stylesheet>
<style>body { color: green; }</style>
<link href=b.css rel=stylesheet>

But I can't do this:

@import "a.css";
body { color: green; }
@import "b.css";

I don't want a nanny WG to prevent me from supposedly shooting myself in the foot. 

Received on Thursday, 26 February 2015 18:55:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:51 UTC