Re: Media Query Variables

On Fri, 13 Sep 2013 12:55:53 +0200, Kornel Lesiński <kornel@geekhood.net>  
wrote:

> On 13 September 2013 11:18:24 "Simon Pieters" <simonp@opera.com> wrote:
>> On Fri, 13 Sep 2013 11:08:21 +0200, Kornel Lesiński  
>> <kornel@geekhood.net> wrote:
>>
>> > That case is suboptimal from performance perspective, since the last  
>> variant may be unnecessarily preloaded, but this wouldn't break the  
>> page.
>>
>> The performance problem is my concern.
>
> I think it's important that it can be used in preload scanner, but if  
> possible I'd rather not compromise a solution because there may be  
> suboptimal cases.
> For example preload scanner is irrelevant for JS applications, but  
> responsive images and ease of maintenance is important.

I don't understand what you mean by "JS applications" or why the issue is  
irrelevant for them. Note that the issue doesn't just surface for the  
preload scanner, the example I gave has the issue and doesn't use <script>  
so the preload scanner isn't involved. It's just that the parser gets to  
the <picture> (or whatever) before the external stylesheet is loaded.

>> This doesn't solve the problem. We should not add an ability to  
>> browsers that we don't want people to use. The only way to make people  
>> not use something is to not support it.
>
> The alternative may be having no solution that authors want to use and  
> they'll use hacks for responsive images that kill preload scanner in all  
> cases, not just when used against best practice.

No, that's not the only alternative.

>> We could have the at-rule but only support it in <style>, but that  
>> gives the expectation that it also works in external stylesheets. Maybe  
>> that's a good thing if we want to allow it in <style scoped> (and have  
>> it scoped).
>
> If this rule triggers syntax error in external stylesheets I think it  
> would be acceptable compromise, but it's not pretty :/

OK, good. I think that is acceptable also. It doesn't necessarily need to  
be a syntax error, it could be parsed fine but just have no effect, either  
way.

>> > 2. Browsers can postpone loading of the image when preload scanner  
>> encounters an unknown variable.
>>
>> Making the image load block on external stylesheets is not acceptable.  
>> I think we should design a solution that enables the browser to  
>> download the correct resource as soon as it sees it without blocking on  
>> another resource.
>
> This solution enables non-blocking loading. It just doesn't force it.

Behavior should be well-defined.

>> > The worst case of misuse is bandwidth waste. The right image will be  
>> displayed regardless - picture is not like video where you have to make  
>> the choice once and do it perfectly first time. It allows browsers to  
>> reevaluate options when conditions change.
>>
>> I think it is important to make the right choice for images on page  
>> load.
>
> I agree that's need in most cases, but due to technical constraints this  
> is in conflict with another strong case of separation of layout and  
> markup.

Yeah, that worries me that many are going to put it in external style  
sheet and browsers are left with the performance problem.

> I don't mind giving authors choice of losing preload scanner if they  
> prefer all media queries to be in stylesheets.

I do mind giving authors a subtle performance footgun.

> They do have an option of inlining for performance. Technically even  
> automatic optimizers like mod_pagespeed could do it for them.

If their pipeline inlines their styles, then only supporting it in <style>  
should be OK for them.


>> Do you want this proposal to have no effect for <video><source media>?  
>> How about <link rel=stylesheet media>?
>
> That's a very good question. I suppose it should work like media queries  
> work currently - affect <link> dynamically and <video> at time of  
> selection (or not at all if you prefer).

OK. I agree.

> It would cause race condition for video if browser isn't deferring  
> decision until CSS is loaded. OTOH I thought <video media> is being  
> dropped/at-risk due to lack of usage and adaptive streaming works better  
> for it than media queries, so it may never be a problem in practice.

There would be no race if we only allow <style>. You're right that it has  
been proposed to remove <source media>, which, if it happens, makes this  
irrelevant for <video>.

On Fri, 13 Sep 2013 13:30:00 +0200, Kornel Lesiński <kornel@geekhood.net>  
wrote:

> On 13 September 2013 12:05:13 David Newton <david@davidnewton.ca> wrote:
>>
>> +1 for using <meta>. I think this would solve many of the issues being  
>> discussed. Does anyone know why these variables can't or should be in  
>> the <head>, before <style>?
>
> 1. It makes a CSS feature use the HTML syntax.

I think this is a weak argument, and it's not obviously a "CSS feature"  
any more than e.g. media queries or selectors.

> 2. It closes door on using external file for breakpoints ever

No, it doesn't. We can still enable the feature in external files in the  
future.

> (unless you like having duplicate features). For example HTTP/2 Push  
> could make external stylesheet available before HTML is parsed. That  
> would be the holy grail - a single place for authors to manage  
> breakpoints and compatibility with the preload scanner.
>
> 3. Not all applications need preload scanner. For example app.ft.com is  
> a JS-based offline app. It needs responsive images, but not preload  
> scanner. It would be shame if it had to use worse syntax and less  
> maintainable solution to enable optimization it does not need.

As far as I can tell the issue can still happen for offline apps if it  
uses an external stylesheet.

4. It might be desirable to be able to declare scoped media query  
variables in <body> for components or something, which could piggyback on  
<style scoped>.

-- 
Simon Pieters
Opera Software

Received on Saturday, 14 September 2013 18:18:27 UTC