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

Re: [css-device-adaptation] Progress?

From: Yoav Weiss <yoav@yoav.ws>
Date: Thu, 26 Feb 2015 21:00:00 +0100
Message-ID: <CACj=BEjU8pbyy5Mj=q_sQ62hUkWujM32tyBB4FJZym00L=iDnQ@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 Thu, Feb 26, 2015 at 7:55 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

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

Waiting until all the page's CSS would be downloaded, parsed and cascaded
before starting to download images would cause prohibitive page load time
as well as visual speed regressions. That's not how browsers load images
today, and we've went through great lengths to make sure that they won't
have to start doing that when responsive images were introduced.


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

That is far from being true. `vw` units are used in `sizes` in order to
determine the image density regardless of the external CSS downloaded. They
can also be used in Media Queries inside `media` attributes.


>
> 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 20:00:28 UTC

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