Re: Media Query Variables

On Mon, 16 Sep 2013 12:02:53 +0200, Kornel Lesiński <kornel@geekhood.net>  
wrote:

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

OK.


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

OK. I maintain that we should require on or the other, probably with the  
delaying logic.


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

OK. That's fine.

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

Right, and that's good.

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

I think the net effect on performance depends on how often it happens.

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

Yeah.

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

Fair enough.

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

I'm not convinced that it's irrelevant. If what you describe happens, and  
the main content images suffer from this problem, browsers could fill up  
the request queue with secondary images that don't, which would further  
delay the load of the main content images.

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

Yes, that's a good argument for allowing it in external CSS.

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

-- 
Simon Pieters
Opera Software

Received on Monday, 16 September 2013 13:21:09 UTC