[whatwg] So if media-queries aren't for determining the media to be used what are they for?

Wed May 16 12:09:13 PDT 2012

On Wed, May 16, 2012 at 12:07 PM, Odin Hørthe Omdal <odinho at opera.com>wrote:

> Matthew Wilcox <mail at matthewwilcox.com> wrote:
>
>  Odin wrote:
>>
>>> When I say find a way to defer it, I mean spec a way to do it, and
>>> implement that. Something like:
>>>
>>>   <img defer src="blabla.jpg">
>>>
>>> I understand the problem :-)
>>>
>>
>> Cool - so you're saying we have the option of being able to instruct
>> browsers *not* to perform prefetch in certain circumstances?
>>
>
> Uh, well, I'm saying I think it's something we can propose. For it to
> actually be an option, vendors would have to agree and also implement
> it.
>
> But, yes, I think it can be done. We already have @defer on <script>. If
> it's actually a bad idea, we'll hear about it - and look for an
> alternative way. I'm not yet able to see any big drawbacks though.
>
>
>  ... But it doesn't work. Please read my emails, and come with
>>> constructive technical feedback on why you think it *can* in fact work.
>>> I can not see a method where that would work in an non-broken way.
>>>
>>> Technical problems won't just magically go away by not acknowlegding
>>> them.
>>>
>>
>> I am unable to give technical feedback of the required level; I'm here
>> as an author to tell you this is how we build stuff and this is how
>> we'd want to use images - just like we do with CSS. Just as technical
>> problems won't go away, neither will authors use cases and
>> requirements :) And, unfortunately, I am not skilled enough with the
>> technical side to be able to give you answers to the problem. I'm just
>> stating that the problem is not one that can be ignored lightly
>> because it would mean that the proposed solution does not work with
>> how websites are being built today.
>>
>
> Yes, but the seperation between "before load" and "after load" is how
> *browsers* work today, and also are expected to work.
>
> Opera tried lazy loading on desktop and it caused all sorts of compat
> problems:
>
>  <http://lists.whatwg.org/**pipermail/whatwg-whatwg.org/**
> 2012-February/034846.html<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034846.html>
> >
>
> That weights very heavy with browser vendors.
>
>
> The technical problems I highlighted in lots of the different posts made
> in these threads. E.g.
>
>  <http://lists.whatwg.org/**htdig.cgi/whatwg-whatwg.org/**
> 2012-May/035886.html<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035886.html>
> >
>
> They should be quite readable for anyone, and if not, better ask on
> specifics.
>
>
> I have looked at the use cases, and I believe the use cases should be
> split into two different ones. And I prefer punting the one you're most
> interested in for later. That could be done with something akin to
> <picture>, although that has definite drawbacks as well.
>
> Anyway, I believe the solutions doesn't have to conflict, so that srcset
> would be able to exist just like it is now, and live besides a more
> higher level solution for "art direction" (load image after load)
> however that one might look in the future.
>
>
>  I'm not entirely convinced about this abstraction of model 1 and model
>> 2. <picture> is flawed anyway, and srcset in the same manner, by
>> baking the response tests into the mark-up. When it comes time to
>> re-design there will be new breakpoints and they are not likely to
>> match the one's in the <img> / <picture> tags. It's the major hold-up
>> I had with <picture> and why I suggested looking into abstracting
>> breakpoint conditions away from the responding element and into the
>> <head>.
>>
>
> That is a valid concern. But it's possible to have best practices so
> that you use @srcset in a more limited fashion than what is possible. So
> that you can always have "these and these" image sizes, and you will
> only use it to get different image sizes (not switch other stuff). And
> the viewport queries can only be the same width as the picture's
> intrinsic width.
>

Having standards in place helps a lot of things including how to grill a
hamburger.

What standards does not do in this situation is remove the actual work
effort in having to physically update each and every img's 'srcset' string
with new breakpoints during a redesign, no matter how terse the 'srcset'
string is.
You can have all the stanadrds in place you can muster to write, but the
physical work effort is not negated because of a list of guidelines that
lives in a document that rarely gets followed.

Another situation could involve adding an additional layer of support for
Televisions, in the middle of the lifecycle of a website.
srcset does not allow for a global update to all img's in a templated
fashion. The work effort would need be physically updating each and every
srcset across the site individually.

Not exactly the most efficient use of anyone's time. (picture also has this
as a downfall)

This is a much larger issue than people are willing to admit at this point.

D.

> Then you should be in a much easier place to redesign and change your
> breakpoints, or even add new ones. Resizing the images using CSS for the
> last mile of flexibility ofc.
>
>
> Anyway, that should be solvable down the road.
>
>
> --
> Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software,
> http://opera.com
>