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

Am 16.05.2012 um 00:06 schrieb Chris Heilmann:

> On 15/05/2012 22:46, Bruce Lawson wrote:
>> On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 
>>> On Tue, May 15, 2012 at 1:42 PM, Andy Davies <dajdavies@gmail.com> wrote:
>>>> Looking at the srcset proposal it appears to be recreating aspects of
>>>> media-queries in a terse less obvious form...
>>>> 
>>>> <img src="face-600-200 at 1.jpeg" alt=""
>>>>       srcset="face-600-200 at 1.jpeg 600w 200h 1x,
>>>>               face-600-200 at 2.jpeg 600w 200h 2x,
>>>>               face-icon.png       200w 200h">
>>>> 
>>>> We've already got media queries so surelt we should be using them to
>>>> determine which image should be used and if media-queries don't have
>>>> features we need then we should be extending them...
>>>> 
>>>> I'd like to see media-queries extended to support bandwidth, svg etc.,
>>>> then we give developers the option to detected features and choose
>>>> media types appropriately.
>>> 
>>> The "600w 200h" bit can be directly translated into a media query -
>>> it's equivalent to "(max-width: 600px) and (max-height: 200px)".  It's
>>> collapsed into a custom syntax for terseness.
>> 
>> Just so I understand
>> 
>> 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal)
>> 
>> 2) The new bit is the descriptors of pixel density (1x 2x etc). This isn't "media queried" because the precise mechanism by which one image is chosen over the other is left to the UA to decide based upon heuristics. Those heuristics may be secret sauces that give a browser a competitive advantage over another; they may be based on data the browser has accumulated over time (On my current "Bruce's bedroom WiFi"  I know I have medium network speed but very low latency so I will tend to favour images with characteristic X) and so which aren't available to query with MQs because MQs are stateless; they may be based upon certain characteristics that could conceivably be available to MQs in the future (Do I support JS? Am I touch enabled?) but aren't yet.
>> 
>> Is that accurate?
>> 
>> I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing.
>> 
>> But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see.
>> 
>> bruce-speaking-for-myself-not-Opera
>> 
>> 
> I also wonder what we do with videos? Surely they have the same issues and there is no proposal for changing the syntax there. I do not like the syntax of this. Yes it is more terse but it smacks of the horrible syntax of window.open properties and other comma separated visual attributes.
> 
> From a semantic point of view this is a terrible mix of everything - something that the picture proposal with multiple sources was not.
This is what I think, too.
> Let's not forget that this is a new use case - one that might get more complex with more UA changes in the future. Maybe we have holographic images soon with a X Y and Z position. Shoehorning this into the IMG element doesn't make much sense to me.
> 
> embed is the fallback to video with various sources. img is the fallback to embed. I'd like to see picture - done like video for consistency as it is a new use case for images. Old browsers could disregard them and new ones can use mediaqueries to apply the different sources as needed. Yes, mediaqueries do not all the things we need here and browsers have bugs loading various sources instead of only one but these are things to fix in the browser engines, not add an extra use case in the spec.
And that is a reason why picture is (imo) the better option. It is far more flexible to future changes of media.
I also don't think we need a now working solution but a solution that work for the next couple of years (maybe 10yrs or more). I also won't say picture is the best way to go but it is far better than the proposal that made it in some "draft" earlier this day.

-A.

Received on Tuesday, 15 May 2012 22:14:43 UTC