Re: Media Query Variables

On Sun, Sep 15, 2013 at 12:59 PM, Kornel Lesiński <kornel@geekhood.net> wrote:
> On Sun, 15 Sep 2013 20:32:02 +0100, Simon Sapin <simon.sapin@exyr.org>
> wrote:
>> Le 14/09/2013 20:17, Simon Pieters a écrit :
>>> There would be no race if we only allow <style>.
>>
>> Although it doesn’t right now, Servo will probably want to parse
>> stylesheets (including <style>) in parallel with the rest of the HTML. I
>> would rather have features added that requires blocking on stylesheet
>> parsing.
>
> Media query variables don't require browser to block. They're basically
> event-based.
>
> You can parse <style> asynchronously, and trigger <picture> source selection
> algorithm (asynchronously as well) at any time when you encounter MQ
> variable definition.

No, you really can't.

Obviously, multiple sources can match at any given time.  Because of
this, you'll have some way of choosing between multiple valid sources.
 This method is almost certainly not stable to additions - adding more
choices might mean that it's the new option that gets chosen.

A custom MQ is, at first, an invalid MQ, which doesn't match.  As you
parse in definitions, some of them become valid, which means that the
set of valid sources might grow.  This means that the "best" choice
might change as parsing happens.

This means you have a few choices:

1. Make a choice as soon as you finish parsing the image's element,
based on whatever information is available at that time, and never
change.
2. Don't make any choice until *all* of the valid-but-unknown MQs are
defined, which might be never, and then choose the best option.
3. Make your choice at some arbitrary point in the middle, which by
necessity means exposing race conditions in some circumstances, and
always slows things down at least somewhat.
4. Make a choice at some point, but be willing to abandon an ongoing
request in favor of a better choice exposed at a later point.

#2 is unworkable, because it implies an arbitrary and potentially
infinite delay.

#4 kinda sucks, because it wastes bandwidth, which is part of the
whole point of this in the first place.

#3 is okay if your make a choice like "after the document fires its
load event", but it means that you've completely defeated the preload
scanner, and force delays on every image load.

#1 is the best choice here imo, despite the fact that it limits our
options on how to expose the custom MQs.

~TJ

Received on Monday, 16 September 2013 00:00:31 UTC