Re: [whatwg] Simplified <picture> element draft

On Wed, Jan 8, 2014 at 10:05 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Jan 8, 2014 at 9:47 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>> On Wed, Jan 8, 2014 at 6:18 PM, Maciej Stachowiak <mjs@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.

The way we'd likely implement this feature in Blink is in couple
stages.  In the first stage, we'd implement the portions of the
specification that don't involve media queries because we'll be able
to provide developers a high-quality implementation of that part of
the spec, including preload scanning.  In the second stage, we'd
implement the parts of the specification that relate to media queries.
 We'll likely wait to implement the second stage until we're able to
provide a high-quality implementation, which means waiting until we're
able to parse and process media queries in the preload scanner without
joining the main thread.

Adam

Received on Wednesday, 22 January 2014 23:55:16 UTC