[whatwg] Simplified <picture> element draft

[Tab Atkins Jr.]

On Wed, Jan 8, 2014 at 9:47 AM, Yoav Weiss <yoav at yoav.ws> wrote:
> On Wed, Jan 8, 2014 at 6:18 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> - It seems this draft allows arbitrary media queries, with only a subset
>> expected to give best performance (by correctly informing the preload
>> scanner). In my opinion, this is worse than the alternative of only
>> supporting the media queries that could plausibly be integrated with preload
>> scanning. Creating a programming interface with a "performance cliff" - a
>> point beyond which performance suddenly gets significantly worse for what
>> seems like a small incremental change - is generally a bad idea. And the use
>> cases for fully general media queries seem much more speculative than the
>> ones for the simplified subset.
>
> I'm not opposed to having a white-list of "performance-safe" authorized
> media queries, and extending that list in the future if necessary, but we
> need to make sure that it's extensible without causing the content to break
> in browsers where the new MQs are not supported. As far as I can tell, the
> current syntax can support this.

Right.  We can't just ignore the MQ, as that's unfriendly.  We could
maybe ignore the <source>, but that feels like too much.  Having it
evaluated on the main thread is slower, but it's guaranteed to *work*
in older browsers, which is nice.  And, as previously stated, *every*
MQ beyond "resolution" is preloader-unfriendly in at least some cases.

I'd like to avoid making this complicated for authors as much as
possible.  Having to worry about if legacy browsers will display an
image more slowly is much less troublesome than wondering if legacy
browsers will display it at all; in most cases, you don't have to
worry about it at all, because preloading is a nice benefit but not a
necessity.

Note, too, that though the full set of MQs is only for niche cases, I
can certainly come up with reasonable cases nonetheless, particularly
as we introduce new device-capability MQs.  For example, you could
switch from a GIF to a still picture based on the "updates" MQ that
we're considering adding, or use a higher-contrast version based on
whatever MQ we end up developing for detecting high-contrast needs.
Disallowing these entirely just means that either devs will use JS to
switch their images (then why did we spend all this effort on a
markup-based solution?) or they just won't cater to those needs at
all.

~TJ