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

Re: [css-device-adaptation] Progress?

From: Yoav Weiss <yoav@yoav.ws>
Date: Sun, 22 Feb 2015 18:37:46 +0100
Message-ID: <CACj=BEhtmYExw3qQShGspWCVyrTTSrB9QDT9h4cgcny4FoD9Qw@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
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>
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.
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.

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.


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


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


>
> 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.
>
Received on Sunday, 22 February 2015 17:38:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC