Re: [css-cascade][mediaqueries] Allow custom mq before @import?

On Thu, Apr 16, 2015 at 10:37 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

>
> >
> > I'm not sure there's a meaningful difference between @custom-media and
> > @viewport in this scenario.
> >
> > If this works
> >  <style>@viewport {width: 500px; }</style>
> >  <link rel="stylesheet" media="(max-width: 800px)" href="foo.css">
> >
> > Then this should work
> >  <style>@custom-media --foo true }</style>
> >  <link rel="stylesheet" media="(--foo)" href="foo.css">
>
> I'm not sure that @viewport is parsed for the preloader!  Yoav, any
> insight here?
>

No preloader today is parsing @viewport, and AFAIU, no preloader can do
that without invalidating responsive resources in case of cascaded
@viewport further down the CSS.

Since @viewport can be cascaded, browsers can't be certain of the actual
@viewport value until all the CSS was downloaded and parsed (so after style
calc). Any attempt to heuristically determine @viewport before that (or
ignore it, for that matter) can lead to huge performance losses in case a
different @viewport is defined down the line. (which is why I believe
@viewport in its current form is a performance anti-pattern, and should not
be shipped)

I agree that there's no meaningful difference here between @viewport and
@custom-media. I think both should follow the example of @import and have
very strict location at the top of the stylesheet where they can be defined.

WebKit and Blink's preloadScanners are digging up @import rules without
much trouble, even without a full CSS parser (currently only in inline
styles, but that's just an implementation issue).

I believe download performance critical CSS features should learn from that
example, and make it easier for the browser to optimize the download
process. It would also be great to have a markup equivalent for such
features, and since "Link" headers can also have media attributes in them,
also an HTTP header based equivalent.