Re: [css-device-adaptation] Progress?

On Feb 22, 2015, at 9:37 AM, Yoav Weiss <yoav@yoav.ws> wrote:
> 
> 
>> On Sat, Feb 21, 2015 at 12:20 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> On Feb 20, 2015, at 8:16 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>>> 
>>>> On Thu, Feb 19, 2015 at 11:45 AM, Rune Lillesveen <rune@opera.com> wrote:
>>>> On Wed, Feb 18, 2015 at 10:45 PM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>> > My main problem with the device-adaptation spec and the `@viewport` rule is
>>>> > that it enables external style sheets to impact the viewport dimensions.
>>>> > That can introduce issues around viewport dimensions based resource loading
>>>> > (so both <link media> based CSS and `srcset`/`<picture>` based responsive
>>>> > images).
>>>> >
>>>> > One way to solve this would be to limit `@viewport` inline styles in the
>>>> > document's head, and add smarts to the UAs parsing mechanisms so that they
>>>> > can apply those rules when kicking off loading of viewport-dimensions based
>>>> > resources.
>>>> 
>>>> I agree the UA should be allowed to resolve the viewport based on
>>>> inline styles in head, and it should be established as a "best
>>>> practice", but I'm not sure we need to disallow authors to shoot
>>>> themselves in the foot. Do we have other examples in CSS where we
>>>> handle rules differently based on their origin?
>>>> 
>>> 
>>> Well, @import only works if it's placed before any other rule.
>>> And, since it's a major performance foot gun, I think @import would also make sense as an "inline-only" rule, but that ship has long sailed.
>>> 
>>> @viewport is worse than @import in the sense that it can impact and invalidate or make redundant many other resources that were already download, at least partially. 
>>> 
>>> Since this foot gun has no visual implications when developing locally, I'm afraid that when using @viewport, authors would shoot themselves in the foot more often than not. 
>> 
>> Please don't make it inline only. For some of us, external style sheets are the only opportunity we have to add this sort of thing to some sites. It is a major weakness of the current situation that a meta has to be hard coded into the html of each page instead of having it as part of a coo on CSS file. 
>> 
>> I am currently working on a project where I even have to resort to adding a meta via JavaScript after the page has been laid out, because broad support for @viewport doesn't yet exist, and because editing the html is not an option, but it is still better than nothing. 
> 
> While I agree that support for a "CSS zen garden"-like approach is valuable, performance shouldn't suffer. And while there are cases where such an approach is an absolute necessity, I would assume that's not the majority case.

I think it is probably much more common than you think. Or maybe you know it would be popular, or else you wouldn't be concerned about people using it this way occasionally. Basically, what you are saying is, "don't allow it this way, because authors will really want to use it this way sometimes." Personally, I think it might be a minority case, but not a tiny minority. For myself, it would be an extremely important need, something I have been waiting a long time for, in order to provide a mobile optimized view in cases where it was previously impossible.

It isn't just for theoretical "CSS zen garden" cases. It is for very common white labeling cases.

> For the minority case, you'd still have the possibility of using JS in order to shoot yourself (and your user's performance) in the foot.

That is not necessarily true. For my work, it is common that I can provide a CSS file without providing JS. And sneaking in the meta tag through JS in a custom html header or footer snippet (in the body) is going to hurt performance more than a highly-placed @viewport in one of the first CSS file to load.

> All in all, I believe most authors expect CSS features to be fast by default, without them needing to understand browser internals in order to avoid hurting the page's performance in a significant way. That's the reason (I believe) that we have selectors fast profile, where `:has()` is not present, because it cannot be fast enough. According to the same reasoning, we could have relied on authors to avoid adding `:has()` selectors to their pages, and only use them in scripts, since that's the best practice. We didn't.

This would not have anywhere near the performance impact as ':has()'. You don't have to know the whole element tree for matching, the way you do for  ':has()'. The UA can handle it very early in the parsing stage, maybe even pre scanning all the external and embedded style sheets for @-rules (I imagine it might do this already). 

Also, limiting use of @viewport to head-embedded CSS would only be affective if it was embedded before there were any links to external CSS, but that is a far more unusual pattern. So, while authors can't even remember/learn if CSS files are supposed to come before JS files or the other way around, you would have a super useful feature be broken by design unless the author arranges things in an unusual way, with the embedding before the linking. And does it i every single page of the site. 

Many sites only have one or two CSS files, shared by nearly all pages, and authors are likely to include a document-centric @rule early in their CSS file anyway, since the rules generally proceed from general to specific.

>>  I think it is good enough to add a note about best practice: to either include the @viewport in the head directly and early, or include it near the top of one of the first loaded external style sheets (with a non-restrictive media type).
> 
> 
> Best practices are rarely enough without enforcement.

Enough for who? I am very capable of making decisions for myself, without a nanny or totalitarian CSS cop taking that away from me. A warning is more than enough.

>> And yes, I have also used @import within an external style sheet before, after weighing the alternatives, and it worked well, without any major injury or complaints or the world coming to an end. 
> 
> There are multiple case studies where an extra RTT added to rendering time results in a non-negligible percentage of users leaving your site, or simply hate using it. The fact none of them complained out loud doesn't mean that the extra RTT the use of `@import` inflicted on them had no negative implications.

I've only done that sort of thing in certain places, when I felt the benefits outweighed the costs. Where I work, we do regular surveying of our visitors and customers, and we get complaints about some things, but not about speed specific to where where I've done that. In fact, I did it in a way and place where the negative effect would be negligible. Even if we did get complaints about it, I would still add that to the "costs" side and reevaluate, because it is our site and we can make that sort of decision on our own.

I never said use of @import had no negative implications. Just that I can balance positive vs negative on my own, and be responsible for my own decisions. I also have to deal with vendors who link to a couple dozen or more different JS and CSS files in random order throughout the page, each one with its hit on speed. CSS and HTML doesn't restrict that, but I can pick my own battles.

>> Not everyone would  make the same decisions as  I do, but they are my decisions and I don't regret them, even if someone else is characterizing it as shooting myself in the foot.
>