Re: [css-device-adaptation] Progress?

On Wed, Feb 25, 2015 at 6:12 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

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

OK. I see the use case now.


>
> 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
> <http://dev.w3.org/csswg/selectors-4/#profiles>, 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).
>

That depends on where authors have placed their styles, where they placed
the @viewport rules in them, etc.
Currently only Blink and WebKit scan for @import rules in inline styles.
That can be extended to external styles as well, and for @viewport rules.


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

A standard based note is not likely to have high visibility. A console
warning might be more effective.


>
> 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.
>>
>
> 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, if
coupled with user agent scanning those files to extract these rules, along
with console warnings of possible performance issues.

Rune, Florian - WDYT?