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

Thu May 17 07:13:58 PDT 2012

>> That particular solution is, to my mind, the most flexible and useful
>> implementation I've seen, because it's really about breakpoint
>> management and abstraction - which is what all responsive elements
>> need in order to work together well and be future-friendly.
>>
>> It does, no doubt, have some technical considerations and implications
>> I'm not aware of. I would love to see this worked on more, I don't
>> think there's much more I can add to it from my authors perspective,
>> it needs work from an implementor perspective. But as a pattern, it
>> has a lot of plus points going for it.
>
>
> I'm trying to figure out how it's going to work in other situations than the
> happy case.

That's cool, it needs that level of "how do I break it" thinking.

I'd also point out I'm not claiming this is a replacement for srcset
or <picture>. I think it's a useful additional tool for web
developers, but it is aimed at *site wide* generalised uses to make
life a lot easier - I can't see a way to make it also cater to
specific individual instances without fundamentally breaking the
benefits of the generalisation.

> What if you want to provide copy&pasteable code snippet with an adaptive
> image? (like W3C Validator badges)

That would not be a case this method could support fully.
Srcset and <picture> would offer full support for this use case.

That said, I'm not sure of the use case of pasting an adaptive image
into another domain; we're usually adapting the image to a design on a
given domain; any such image is unlikely to work properly in another
context anyway (because that other context has it's own measures at
that or other breakpoints).

> What if you're creating WYSIWYG editor for CMSes and want to have button for
> inserting adaptive images, but have no access to <head>?

This is not a valid use case (to my mind). You'd not be choosing
response points for individual pictures, it is the design that has
response points and it's the CSS (and JS/HTML) which fit into the
design's breakpoints.
All a CMS does is cater to the "upload a source image, create and/or
associate other images for the breakpoints".

> What if you want to insert a single image with custom/unique breakpoints
> (say an infographic prepared by an agency which used different breakpoints)
> on a website that already has its own breakpoints defined?

This is where <picture> and srcset are useful. However as I say: in
general breakpoints are a property of a design, they are not a
property of the content directly. You do present a valid case for when
a breakpoint may actually be based on the content rather than the
design: infographics are more sensitive to this than the general image
use case (which I believe are photographs or other graphic
illustration).

> I see no nice solution for case when authors put <meta breakpoint> in <body>
> — it'd either have re-evaluate and potentially reload images (wasted
> requests) or ignore the meta (annoying gotcha when HTML5 parser unexpectedly
> closes <head> or when people want to work around lack of access to the
> <head>)

This solution does not allow for <meta> in the body, and nor does the
HTML5 spec unless I'm mistaken?

> How do you work with URLs you have no control over? e.g. you'd have to name
> your breakpoints "40" and "80" to have adaptive size of gravatar.com URLs.

I'm not sure I understand this point. However you cook it, you have no
access to those images so you can't do anything with them regardless
of the method of adaption, be it this method, srcset, or <picture>.

> What do you do when you have only two breakpoints for sidebar, but more for
> the main content? (mostly fixed-width sidebar with fluid main column) or if
> your page header adapts to portrait orientation, but images in main content
> only adapt to width?

Breakpoints are not something that apply to individual components,
they apply to the page as a whole?

> --
> regards, Kornel Lesiński