Re: Media Query Variables

On 16 September 2013 09:23:50 "Simon Pieters" <simonp@opera.com> wrote:

> > These websites are already taking heavy performance hit on first load, 
> can't be accelerated with preload scanner, and have CSS loaded long before 
> final HTML markup is created, for example: http://m.flickr.com
>
> That page appears to be having the main image in the markup, so probably 
> not a good example.
>
Oops indeed. Actual user pictures are using "hashbang" URLs: 
http://m.flickr.com/#/photos/ironammonite/9759142801/in/explore-1379235420/

In that case you get markup of homepage with random irrelevant featured 
photo and meaningful markup is created by JS.


> > For ease of implementation I'm suggesting following simple algorithm that 
> IMHO makes behavior well-defined:
>
> It's not clear to me whether you are proposing the delaying to be optional 
> or not. We should choose one or the other and require it, or not support 
> declaring variables externally.

I mean it's optional for correctness (if you don't implement that part 
you'll still get right image eventually), but necessary to prevent wasted 
downloads when stylesheets are parsed asynchronously and authors use mix of 
externally defined variables and MQs without them.


> >
> >   if (child.getAttribute('type')) {
> >    if (!isSupportedMimeType(child.getAttribute('type'))) continue;
> >   }
>
> So this skips past <source>s that have an unsupported type="", but the 
> algorithm doesn't care if the returned image is unsupported.

Indeed. It's for quickly skipping WebP or JPEG-XR images in UAs that don't 
support them, and if authors mislabel types they'll get a broken image.
I haven't specced use of <source>s for recovery from errors to make 
selection algorithm run instantly without any long-term state that JS could 
mess with.


> > By mq.cannotFullyEvaluateYet I mean that the media query contains a MQ 
> variable that is not defined, or any other case when browser is not ready 
> to evaluate the media query yet (e.g. MQ refers to viewport size in an 
> iframe that has unknown size).
>
> The iframe problem already exists, so it might be good to delay for that 
> case. However, the variable-isn't-declared-yet problem doesn't exist today, 
> and we can avoid introducing it.

If you're supporting deferring decision in one case, support for the other 
looks like a tiny incremental change, so that's low cost and low complexity 
for implementors, but a big improvement for authors.


>
> This is an attractive property of your proposal, I think. It reduces the 
> complexity from what <video> does to be more like what <img srcset> does. 
> However, to keep this property, it can't support doing switching based on 
> whether the downloaded image is supported (like <video> does).

It doesn't indeed. It just looks at types declared in the markup, but not 
what actually is sent.

> > - pushing of CSS with HTML via SPDY/HTTP2 or inlining FEO proxies or page 
> preprocessors won't be common enough to mitigate this
>
> So let's say that in the future, the CSS file and HTML file will be 
> downloaded in parallel, and will be parsed in parallel as well. The HTML 
> parser still would not necessarily be able to resolve the MQ variable when 
> it reaches it if it can be declared in CSS.

That's just a matter of making threads coordinate the process (which can be 
done by asynchronous queues, not locks).

> > - affected pages won't be hiding image markup from preload scanner by 
> using JS-based templating ("MVC" JS apps) or overuse of Web Components 
> (<html><my-cool-app/></html>) 
> <http://tomdale.net/2013/09/progressive-enhancement-is-dead/>
>
> This assumes that such apps will wait with building their DOM until the CSS 
> is loaded. Otherwise, the problem is still there.

Strictly speaking yes, but in practice time required to load all JS is long 
enough to let CSS load, and if script reads any CSSOM AFAIK it'll be made 
to wait for CSS to load.

> Browsers go to great lengths to have the right set of images as ready as 
> possible when it is time for the first paint. That time is usually when the 
> external CSS is loaded. You're proposing that the browser can't even start 
> downloading the right image until then.

Yes, I'm proposing having ability to do that. However, that's an option. 
Authors may still inline markup for performance. And I think it's important 
they're not forced to always inline.

At cost of about 1 RTT latency it gives authors desirable separation of 
markup and presentation. Just like external CSS is a performance cost over 
inline style="".

Browsers already schedule images to load with low priority. If a page has 
other resources (JS, non-responsive images, frames/ads) to download it may 
even keep network busy for long enough for the delay to be irrelevant.

Also note that MQ variables ease maintenance even within stylesheets, even 
when not used for responsive images, so a <meta>-only solution wouldn't be 
good for uses within CSS. Combination of CSS-only variables and 
<picture>-only meta would require duplication of variables, and such things 
tend to annoyingly get out of sync.


> > I've meant <meta> syntax. Allowing some <meta>-based syntax first and 
> later adding a different, nicer syntax in external stylesheets would be 
> possible, but unnecessarily ugly.
>
> Yeah. (Such a thing has happened: <meta name=viewport> vs @viewport. Maybe 
> @viewport was a bad idea...)

Yes, that was very unfortunate. <meta> was the bad idea, because now I have 
to use User-Agent sniffing to insert "phone" or "tablet" meta rather than 
use <link media> to choose right viewport settings for the device size.

I think another duplication of syntax would be a failure. <meta viewport> 
is an antipattern. Let's bite the bullet and implement good CSS syntax from 
the start.

-- 
regards, Kornel

Received on Monday, 16 September 2013 10:03:16 UTC