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

2012-05-17 Thread Kornel Lesiński
On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox  
m...@matthewwilcox.com wrote:


What solution do you have in mind that would let you add a 'tv'  
breakpoint site-wide for all images that have been prepared for it,  
without need to
update code that embeds those images? And is that really saving much  
effort?

Wouldn't you have to revisit every page anyway to test the new layout?


That following link does it:


[1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/


Sorry, you're right. I glanced over URI template and assumed it was for  
media=(case: breakpoint1) in source.


--
regards, Kornel Lesiński


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

2012-05-17 Thread Matthew Wilcox
On 17 May 2012 11:05, Kornel Lesiński kor...@geekhood.net wrote:
 On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox m...@matthewwilcox.com
 wrote:

 What solution do you have in mind that would let you add a 'tv'
 breakpoint site-wide for all images that have been prepared for it, without
 need to
 update code that embeds those images? And is that really saving much
 effort?
 Wouldn't you have to revisit every page anyway to test the new layout?


 That following link does it:


 [1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/


 Sorry, you're right. I glanced over URI template and assumed it was for
 media=(case: breakpoint1) in source.

 --
 regards, Kornel Lesiński

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.


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

2012-05-17 Thread Kornel Lesiński
On Thu, 17 May 2012 14:16:24 +0100, Matthew Wilcox  
m...@matthewwilcox.com wrote:



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.



What if you want to provide copypasteable code snippet with an adaptive  
image? (like W3C Validator badges)


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


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?


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)


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.


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?


--
regards, Kornel Lesiński


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

2012-05-17 Thread Matthew Wilcox
 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 copypasteable 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


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

2012-05-17 Thread Kornel Lesiński
On Thu, 17 May 2012 15:13:58 +0100, Matthew Wilcox  
m...@matthewwilcox.com wrote:



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.


I see. So we could proceed with the spec without it, and add it later.

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.


OK.

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?


What spec allows and what happens on the web are separate things :)

HTML needs to define all error cases and be prepared for markup to be  
abused (lots of such cases had to be defined already).


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.


Yes, you can. gravatar.com allows you to specify desired size:

gravarar.com/avatar/hash?s=40 # gives 40x40px image
gravarar.com/avatar/hash?s=80 # gives 80x80px image


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?


In my designs I use it mainly for components. I don't think of pages as  
separate phone/tablet/desktop designs, but as fluid designs which fold and  
unfold component by component.



Let's say my fancy header logo is quite tall, and that doesn't look well  
in landscape orientation, so I want to use short/wide version of the  
design in landscape orientation.


And I have a square illustration in my content. It doesn't flip on  
orientation, but I want it to be 500x500px on 1000px+ screens, and  
320x320px on smaller ones.


In some srcset-source pseudocode I'd say:

header
img src=logo-tall srcset=logo-short (orientation:landscape)
/header
acticle
	img src=illustration-big srcset=illustration-small  
(max-width:1000px)

/article

How would you do that with breakpoints?

--
regards, Kornel Lesiński


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

2012-05-16 Thread Chris Heilmann

On 16/05/2012 00:23, Kornel Lesiński wrote:
On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann code...@gmail.com 
wrote:


The fetish for brevity is something I never understood. More 
understandable code is faster to write than cryptic short code.


There is significant difference in verbosity for a *very common case* 
of serving images for high-dpi (Retina) display (which I suspect is 
only going to get more common):


img src=lowdpi srcset=hidpi 2x

vs

picture
source media=(min-device-pixel-ratio: 2) src=hidpi
img src=lowdpi
/picture


It will get tiring when it'll have to be used for every image on the 
page.


Authors couldn't be bothered to type extra markup for all vendor's 
prefixes in CSS. Nobody bothered with verbose SVG gradient syntax 
which was usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity 
matters.


Now there is a massive list of assumptions. People were happy for YEARS 
to do a:


object width=420 height=315param name=movie 
value=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0;/paramparam 
name=allowFullScreen value=true/paramparam 
name=allowscriptaccess value=always/paramembed 
src=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0; 
type=application/x-shockwave-flash width=420 height=315 
allowscriptaccess=always allowfullscreen=true/embed/object


For a video. You know why? Because it worked! SVG didn't work inside 
HTML for a long time that's why these gradients didn't work - not 
because it was too long. HTML5 Doctype may be loved but people even 
forget using that one (case in point - codecademy HTML classes totally 
forget about it - WHEN teaching new people how to write code for the web).


Tooling works around these issues, not making a language shorter. You 
learn that when you teach people to start using the web. Let's not get 
too excited about what the people writing specs use and like but see 
what makes a platform that is understandable and works.





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

2012-05-16 Thread Matthew Wilcox
Am i right in believing that the srcset attribute are limited to
pixels? A unit that's dying out in all responsive designs? Is it
extensible to em, % etc? Because that's what's used.

On 16 May 2012 08:39, Chris Heilmann code...@gmail.com wrote:
 On 16/05/2012 00:23, Kornel Lesiński wrote:

 On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann code...@gmail.com
 wrote:

 The fetish for brevity is something I never understood. More
 understandable code is faster to write than cryptic short code.


 There is significant difference in verbosity for a *very common case* of
 serving images for high-dpi (Retina) display (which I suspect is only
 going to get more common):

 img src=lowdpi srcset=hidpi 2x

 vs

 picture
 source media=(min-device-pixel-ratio: 2) src=hidpi
 img src=lowdpi
 /picture


 It will get tiring when it'll have to be used for every image on the page.

 Authors couldn't be bothered to type extra markup for all vendor's
 prefixes in CSS. Nobody bothered with verbose SVG gradient syntax which was
 usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters.

 Now there is a massive list of assumptions. People were happy for YEARS to
 do a:

 object width=420 height=315param name=movie
 value=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0;/paramparam
 name=allowFullScreen value=true/paramparam name=allowscriptaccess
 value=always/paramembed
 src=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0;
 type=application/x-shockwave-flash width=420 height=315
 allowscriptaccess=always allowfullscreen=true/embed/object

 For a video. You know why? Because it worked! SVG didn't work inside HTML
 for a long time that's why these gradients didn't work - not because it was
 too long. HTML5 Doctype may be loved but people even forget using that one
 (case in point - codecademy HTML classes totally forget about it - WHEN
 teaching new people how to write code for the web).

 Tooling works around these issues, not making a language shorter. You learn
 that when you teach people to start using the web. Let's not get too excited
 about what the people writing specs use and like but see what makes a
 platform that is understandable and works.




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

2012-05-16 Thread Odin Hørthe Omdal
On Wed, 16 May 2012 10:33:05 +0200, Matthew Wilcox  
m...@matthewwilcox.com wrote:

Am i right in believing that the srcset attribute are limited to
pixels? A unit that's dying out in all responsive designs? Is it
extensible to em, % etc? Because that's what's used.


I'm afraid you are confusing a lot of stuff together here.

You can use em and % freely in your stylesheets/CSS. The values from  
srcset is used to fetch the right resource during early prefetch, checked  
against the width and height of the viewport (and only that viewport).


Having ems or % would make no sense whatsoever there, because you don't  
know what they mean. 50% of what? The viewport size? You would basically  
make it always matching. Because 50% will always be half of whatever your  
viewport size is...


Say you writeimg srcset=mycoolpic.jpg 50%w, myotherpic.jpg 75%w

If viewport is  50px wide, mycoolpic will match   25px, myotherpic will  
match 37.5px, so it'll pick myotherpic.jpg
If viewport is  200px wide, mycoolpic will match 100px, myotherpic will  
match 150px, so it'll pick myotherpic.jpg
If viewport is  500px wide, mycoolpic will match 250px, myotherpic will  
match 375px, so it'll pick myotherpic.jpg
If viewport is 1000px wide, mycoolpic will match 500px, myotherpic will  
match 750px, so it'll pick myotherpic.jpg


See the pattern? It'll always pick the one closest to 100%, no matter  
what. It doesn't make sense.


Also note: the width of an image, and the value you write in srcset,  
doesn't need to have any connection at all. It's only used to match  
against the viewport to choose what picture the user agent will fetch.



This example will make your logo a smaller mobile version when your  
viewport width is 600 or smaller (you should also have some media queries  
in your stylesheet that change the layout at that stage):


  img src=fallback... srcset=logo-150px.jpg, logo-50px.jpg 600w

Here, the logo-50px.jpg will only be loaded if your viewport width is less  
than 600. It'll choose logo-150px.jpg for everything else.



CSS (and the domain media queries work in), and resource fetching that  
works with prefetching/-loading is two totally seperate things/problems.


If you make a solution that will support em/% in a meaningful way, you  
would have to wait for layout in order to know what size that means. So  
you will have slower-loading images, and ignore the we want pictures  
fast requirement.


--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com


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

2012-05-16 Thread Tim Kadlec
The lack of em support is a concern though I understand the complications you 
have brought up.

Using ems for media queries (which in turn dictate layout which in turn 
dictates the image I want to load) is increasingly looking like a much wiser 
decision than using pixels. A perfect example are devices such as the Kindle 
Touch which have a much higher default font size. A real world example, and 
case study, can be found here: 
http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/

Now suppose that for that layout displayed in their screenshot, the header 
image was changed to be a vertical oriented phone and the size was reduced. In 
that case, I would want srcset to kick in with a different image. It sounds 
like it would not be able to accomplish this right now?

Forgive me if I'm just missing something. It's early and my coffee hasn't 
kicked in quite yet. :)

-Tim

On May 16, 2012, at 4:07 AM, Odin Hørthe Omdal odi...@opera.com wrote:

 On Wed, 16 May 2012 10:33:05 +0200, Matthew Wilcox m...@matthewwilcox.com 
 wrote:
 Am i right in believing that the srcset attribute are limited to
 pixels? A unit that's dying out in all responsive designs? Is it
 extensible to em, % etc? Because that's what's used.
 
 I'm afraid you are confusing a lot of stuff together here.
 
 You can use em and % freely in your stylesheets/CSS. The values from srcset 
 is used to fetch the right resource during early prefetch, checked against 
 the width and height of the viewport (and only that viewport).
 
 Having ems or % would make no sense whatsoever there, because you don't know 
 what they mean. 50% of what? The viewport size? You would basically make it 
 always matching. Because 50% will always be half of whatever your viewport 
 size is...
 
 Say you writeimg srcset=mycoolpic.jpg 50%w, myotherpic.jpg 75%w
 
 If viewport is  50px wide, mycoolpic will match   25px, myotherpic will match 
 37.5px, so it'll pick myotherpic.jpg
 If viewport is  200px wide, mycoolpic will match 100px, myotherpic will match 
 150px, so it'll pick myotherpic.jpg
 If viewport is  500px wide, mycoolpic will match 250px, myotherpic will match 
 375px, so it'll pick myotherpic.jpg
 If viewport is 1000px wide, mycoolpic will match 500px, myotherpic will match 
 750px, so it'll pick myotherpic.jpg
 
 See the pattern? It'll always pick the one closest to 100%, no matter what. 
 It doesn't make sense.
 
 Also note: the width of an image, and the value you write in srcset, doesn't 
 need to have any connection at all. It's only used to match against the 
 viewport to choose what picture the user agent will fetch.
 
 
 This example will make your logo a smaller mobile version when your viewport 
 width is 600 or smaller (you should also have some media queries in your 
 stylesheet that change the layout at that stage):
 
  img src=fallback... srcset=logo-150px.jpg, logo-50px.jpg 600w
 
 Here, the logo-50px.jpg will only be loaded if your viewport width is less 
 than 600. It'll choose logo-150px.jpg for everything else.
 
 
 CSS (and the domain media queries work in), and resource fetching that works 
 with prefetching/-loading is two totally seperate things/problems.
 
 If you make a solution that will support em/% in a meaningful way, you would 
 have to wait for layout in order to know what size that means. So you will 
 have slower-loading images, and ignore the we want pictures fast 
 requirement.
 
 -- 
 Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com


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

2012-05-16 Thread Odin Hørthe Omdal

Tim Kadlec t...@timkadlec.com wrote:
The lack of em support is a concern though I understand the  
complications you have brought up.


Using ems for media queries (which in turn dictate layout which in turn  
dictates the image I want to load) is increasingly looking like a much  
wiser decision than using pixels. A perfect example are devices such as  
the Kindle Touch which have a much higher default font size. A real  
world example, and case study, can be found here:  
http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/


I don't think it is fit for this round of spec. It is in direct conflict
with preloading/prefetching. It's a different model and requires a
different fix.

Model 1, before load: do image decision, fetch image while loading the page
Model 2, after load: load page, do image decision after layout

srcset is using model 1, which is faster and in the same way images are
done today. I don't think you'll be able to convince vendors to ditch
that optimization.

media queries is doing model 2. I suggest we find a way to do that with
javascript. Maybe some form of deferring image loading at all, saying
that I will fetch image on my own. Then you can do the delayed image
loading that would need to happen in a media query world.

Having a fix for model 1, doesn't hinder something for model 2 to come
at a later point.

Now suppose that for that layout displayed in their screenshot, the  
header image was changed to be a vertical oriented phone and the size  
was reduced. In that case, I would want srcset to kick in with a  
different image. It sounds like it would not be able to accomplish this  
right now?


No, you're right about that. Or it could work in the current proposal,
but I don't really think it's worth it.

The spec does have an algorithm for updating the image that does a new
fetch and show, but it's not required to run it. So you can't really
depend on it. But it can work. If it has already fetched a bigger
image, and has that in cache, it might not want to fetch a smaller one
when you rotate though. Why show something of worse quality than what
you already cache?

If the intrinsic sizes are different, well, the user agent doesn't
know that until it has downloaded the image anyway.


IMHO that should rather be done with a model 2. That means, in the
short term: finding a way to solve it using client side javascript.


So in clear text: I don't think that should be supported by imgsrc.
That's a job for a media query. Model 2.


Forgive me if I'm just missing something. It's early and my coffee  
hasn't kicked in quite yet. :)


PS: I would be very happy if you didn't top-post, and also trimmed your
quotes so that it's easy to follow and read (I read email on my phone
when I'm out, and I love when people write emails that work nicely on
the phone).

--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com


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

2012-05-16 Thread Odin Hørthe Omdal

Oh, please do quote what you are answering. It's very hard to follow
such a conversation like this.

Matthew Wilcox m...@matthewwilcox.com wrote:

If there was a way to do this in JS, we'd have found it. Every time we
run up against the pre-fetch problem. In fact, it is only the
pre-fetch problem that causes responsive images to be an issue at all.
It'd be trivial to fix with JS otherwise.


I could be more clear. I believe this is what you are talking about:

I said:

media queries is doing model 2. I suggest we find a way to do that with
javascript. Maybe some form of deferring image loading at all, saying
that I will fetch image on my own. Then you can do the delayed image
loading that would need to happen in a media query world.


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 :-)


Also, i don't think non-pixel based layouts can be easily dismissed.
It's where the whole movement is going and already pixel based MQ are
described as limited and not a best practice.


... 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.


And I did find a way forward for the model 2, make a way to defer the
image load and find a way to load it. Maybe picture element should
always defer? It actually *has to* because it uses media queries, so in
fact, picture might be a solution for model 2 in the future.

But @srcset is solving the other part of the equation (model 1).
--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com


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

2012-05-16 Thread Matthew Wilcox
On 16 May 2012 14:30, Odin Hørthe Omdal odi...@opera.com wrote:
 Oh, please do quote what you are answering. It's very hard to follow
 such a conversation like this.


OK, I am not sure what format to reply to emails with - some people
complain when quotes are left out entirely, other people complain when
replies are in-line in the style you request, other people complain
unless the whole thread is included verbatim in any reply. What's the
actual WHATWG proscribed format for conducting conversations in email
format?


 Matthew Wilcox m...@matthewwilcox.com wrote:

 If there was a way to do this in JS, we'd have found it. Every time we
 run up against the pre-fetch problem. In fact, it is only the
 pre-fetch problem that causes responsive images to be an issue at all.
 It'd be trivial to fix with JS otherwise.


 I could be more clear. I believe this is what you are talking about:


 I said:

 media queries is doing model 2. I suggest we find a way to do that with
 javascript. Maybe some form of deferring image loading at all, saying
 that I will fetch image on my own. Then you can do the delayed image
 loading that would need to happen in a media query world.


 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?

 Also, i don't think non-pixel based layouts can be easily dismissed.
 It's where the whole movement is going and already pixel based MQ are
 described as limited and not a best practice.


 ... 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.


 And I did find a way forward for the model 2, make a way to defer the
 image load and find a way to load it. Maybe picture element should
 always defer? It actually *has to* because it uses media queries, so in
 fact, picture might be a solution for model 2 in the future.

 But @srcset is solving the other part of the equation (model 1).

 --
 Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

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.


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

2012-05-16 Thread Mike Taylor
On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox  
m...@matthewwilcox.com wrote:


What's the actual WHATWG proscribed format for conducting conversations  
in email

format?


See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F

--
Mike Taylor
Opera Software


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

2012-05-16 Thread Matthew Wilcox
Cheers :)

On 16 May 2012 15:05, Mike Taylor mi...@opera.com wrote:
 On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox m...@matthewwilcox.com
 wrote:

 What's the actual WHATWG proscribed format for conducting conversations in
 email
 format?


 See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F

 --
 Mike Taylor
 Opera Software


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

2012-05-16 Thread Philip Jägenstedt
On Wed, 16 May 2012 03:50:21 +0200, Silvia Pfeiffer  
silviapfeiff...@gmail.com wrote:


On Wed, May 16, 2012 at 9:20 AM, Odin Hørthe Omdal odi...@opera.com  
wrote:



I'm not sure. What do you think? As far as I've seen, you're highly
knowledgeable about video. Why do we have mediaqueries on video  
element?

Do we have a use case page?


Hehe, thanks. :-) But media queries were in video before I arrived,
so I missed the whole discussion around it and how it got there. Some
of the browsers that implement support for it should speak up.


We have supported the media attribute since the first stable release with  
video (Opera 10.50) and Git blames me. However, I must say that I just  
added it because it was in the spec and don't remember any discussion  
about it. Some digging shows that it was added to the spec in  
http://html5.org/r/724, but I don't know why.


As far as I can tell, it's mostly useless and I've never heard of it  
actually being used. The correct way to handle different screen sizes and  
bandwidth constraints is adaptive streaming. Simon Pieters has suggested  
simply dropping the attribute and I would not object to that.


--
Philip Jägenstedt
Core Developer
Opera Software


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

2012-05-16 Thread Tab Atkins Jr.
On Wed, May 16, 2012 at 5:42 AM, Odin Hørthe Omdal odi...@opera.com wrote:
 Tim Kadlec t...@timkadlec.com wrote:

 The lack of em support is a concern though I understand the complications
 you have brought up.

 Using ems for media queries (which in turn dictate layout which in turn
 dictates the image I want to load) is increasingly looking like a much wiser
 decision than using pixels. A perfect example are devices such as the Kindle
 Touch which have a much higher default font size. A real world example, and
 case study, can be found here:
 http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/

 I don't think it is fit for this round of spec. It is in direct conflict
 with preloading/prefetching. It's a different model and requires a
 different fix.

Not really.  Media Queries allows 'em' to be used; it's just relative
to the initial font size (which is specified by the browser, not CSS),
rather than the font-size of any particular element.  Since the w/h
components of @srcset are basically MQs, it should work similarly.

~TJ


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

2012-05-16 Thread Kornel Lesiński
On Wed, 16 May 2012 20:09:13 +0100, D. Pitchford dpitchfo...@gmail.com  
wrote:


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.


The solution I've seen proposed[1] only aliases media query content, and  
works only on a per-page basis, so it doesn't allow automatic addition of  
a new image size site-wide, since you have to insert new source into  
every picture anyway.


To me it looks like about the same amount of work as inserting new pixel  
size into every srcset.



What solution do you have in mind that would let you add a 'tv' breakpoint  
site-wide for all images that have been prepared for it, without need to  
update code that embeds those images? And is that really saving much  
effort? Wouldn't you have to revisit every page anyway to test the new  
layout?



[1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/

--
regards, Kornel Lesiński


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

2012-05-16 Thread Matthew Wilcox
 The solution I've seen proposed[1] only aliases media query content, and
 works only on a per-page basis, so it doesn't allow automatic addition of a
 new image size site-wide, since you have to insert new source into every
 picture anyway.

That is not true. With that particular solution you would never alter
any mark-up inside the body, you would only ever need to alter the
meta variables in the head - which more often than not are in a
single server-side template for a website. That solution makes it
trivial to adjust, add, or subtract the breakpoints of a design, and
therefor images, site-wide under normal website conditions (i.e.,
you're using a CMS to output the website).

 To me it looks like about the same amount of work as inserting new pixel
 size into every srcset.

Completely not the case.

 What solution do you have in mind that would let you add a 'tv' breakpoint
 site-wide for all images that have been prepared for it, without need to
 update code that embeds those images? And is that really saving much effort?
 Wouldn't you have to revisit every page anyway to test the new layout?

That following link does it:

 [1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/

 --
 regards, Kornel Lesiński


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

2012-05-15 Thread Andy Davies
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.

Andy


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

2012-05-15 Thread Tab Atkins Jr.
On Tue, May 15, 2012 at 1:42 PM, Andy Davies dajdav...@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.

Are there good cases to use other types of media queries?  I never got
to join the CG, so I'm sure I missed out on lots of use-cases that
were presented.

~TJ


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

2012-05-15 Thread Bruce Lawson
On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. jackalm...@gmail.com  
wrote:



On Tue, May 15, 2012 at 1:42 PM, Andy Davies dajdav...@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



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

2012-05-15 Thread Tab Atkins Jr.
On Tue, May 15, 2012 at 2:46 PM, Bruce Lawson bru...@opera.com wrote:
 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)
[snip]
 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.

I think I more or less agree with you.  However, when you look at MQ,
literally the only things you want to decide on are width/height, and
*maybe* grayscale/color. You really don't need to be generic here, so
you might as well optimize the syntax to make it easier to type.

I think this is too much, personally.  I'd prefer more verbosity here, like:

img src=foo.jpg srcset=foo-big.jpg min-width:1000px, foo-...@2.jpg
min-width:1000px 2x

Importantly, I think I'd like to be able to use either min or max, but
@srcset's microsyntax only talks about min sizes. (I got it wrong in
my previous email.)

~TJ


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

2012-05-15 Thread Anne van Kesteren
On Tue, May 15, 2012 at 11:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Importantly, I think I'd like to be able to use either min or max, but
 @srcset's microsyntax only talks about min sizes. (I got it wrong in
 my previous email.)

Well, it's not a media query. It *describes* the size of the image. A
media query *evaluates* device capabilities. They are completely
different and allow for different resource selection algorithms.


-- 
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/


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

2012-05-15 Thread Tab Atkins Jr.
On Tue, May 15, 2012 at 3:01 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, May 15, 2012 at 11:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Importantly, I think I'd like to be able to use either min or max, but
 @srcset's microsyntax only talks about min sizes. (I got it wrong in
 my previous email.)

 Well, it's not a media query. It *describes* the size of the image.

No it doesn't.  Saying 600w next to a URL says nothing about the
size of the image, just that you claim that the image at that URL is
intended for screens at least 600px wide.

~TJ


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

2012-05-15 Thread Chris Heilmann

On 15/05/2012 22:46, Bruce Lawson wrote:
On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. 
jackalm...@gmail.com wrote:


On Tue, May 15, 2012 at 1:42 PM, Andy Davies dajdav...@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.


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.





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

2012-05-15 Thread Anselm Hannemann Web Development
Tab, maybe you think this is a good type to write the syntax but the majority 
of normal web developers are used to use common HTML syntax. This is why we 
proposed the picture element and normal attributes using media queries.
Of course this means we have lot more to write but at least this is intuitive 
and totally clear as it uses common structure of HTML. Do you agree with this?
I think it is more important that everyone understands the syntax and actually 
will use it instead of having a shorthand code that no one will use...?

-Anselm

Am 15.05.2012 um 23:56 schrieb Tab Atkins Jr.:

 On Tue, May 15, 2012 at 2:46 PM, Bruce Lawson bru...@opera.com wrote:
 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)
 [snip]
 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.
 
 I think I more or less agree with you.  However, when you look at MQ,
 literally the only things you want to decide on are width/height, and
 *maybe* grayscale/color. You really don't need to be generic here, so
 you might as well optimize the syntax to make it easier to type.
 
 I think this is too much, personally.  I'd prefer more verbosity here, like:
 
 img src=foo.jpg srcset=foo-big.jpg min-width:1000px, foo-...@2.jpg
 min-width:1000px 2x
 
 Importantly, I think I'd like to be able to use either min or max, but
 @srcset's microsyntax only talks about min sizes. (I got it wrong in
 my previous email.)
 
 ~TJ



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

2012-05-15 Thread Anselm Hannemann Web Development
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. jackalm...@gmail.com 
 wrote:
 
 On Tue, May 15, 2012 at 1:42 PM, Andy Davies dajdav...@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.

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

2012-05-15 Thread Chris Heilmann

On 15/05/2012 23:11, Anselm Hannemann Web Development wrote:

Tab, maybe you think this is a good type to write the syntax but the majority 
of normal web developers are used to use common HTML syntax. This is why we 
proposed the picture element and normal attributes using media queries.
Of course this means we have lot more to write but at least this is intuitive 
and totally clear as it uses common structure of HTML. Do you agree with this?
I think it is more important that everyone understands the syntax and actually 
will use it instead of having a shorthand code that no one will use...?



+1

The fetish for brevity is something I never understood. More 
understandable code is faster to write than cryptic short code.


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

2012-05-15 Thread Tab Atkins Jr.
On Tue, May 15, 2012 at 3:06 PM, Chris Heilmann code...@gmail.com wrote:
 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.

video is a special case, unfortunately.  It would be difficult to
avoid using source there, but we shouldn't look at it as a good
example in general.  Using source introduces a lot of problems that
would be good to avoid if possible.

 From a semantic point of view this is a terrible mix of everything -
 something that the picture proposal with multiple sources was not.

There's no semantics in here - this is all presentation and usability.
 This is just a very compact way to state the information that
picture presented more verbosely.

img srcset=foo.jpg 600w 2x is no more a terrible mix of everything than

picture
  source src=foo.jpg media=min-width:600px resolution=2
/picture

is.

 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.

We should take care not to be future-hostile, but designing for all
hypothetical futures just results in muddled, hard-to-use designs.
Among current MQs, there are 2/4 (depending on if you count min/max
separate) queries you definitely want to use, and one that *might* be
useful (and which can be added to the microsyntax cleanly).

I'm not aware of proposed future MQs that would be useful to tie into
this functionality, either.


 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.

See the blog post I wrote today so I'd have to stop giving this same
argument over and over again. ^_^ http://www.xanthir.com/blog/b4Hv0.
 You simply can't make a good decision about which resolution to send
to the user based on information from Media Queries.

~TJ


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

2012-05-15 Thread Odin Hørthe Omdal

Andy Davies dajdav...@gmail.com wrote:

Looking at the srcset proposal it appears to be recreating aspects of
media-queries in a terse less obvious form...

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...


Ah! What a truly great question, so simple.

The answer is: no, it is not media-queries although they look like it. A
big problem is that it's so easy to explain it by saying it's just like
media-query max-width, rather than finding the words to illustrate that
they are totally different.

The *limited effect* also feels similar which doesn't help the case at
all.

So, even though I have a rather bad track record of explaining any
thing, I'll try again:

Media queries come from the client side. They allow the author of a web
page to tell exactly how she want to lay out her design based on the
different queries. The browser *HAS* to follow these queries. And also,
I don't think (please correct me if wrong) the media query can be subset
to only the stuff that's really meaningful to do at prefetch-time.

The srcset proposal, on the other hand, are purely HINTS to the browser
engine about the resources. They are only declarative hints that can be
leveraged in a secret sauce way (like Bruce said in another mail) to
always optimize image fetching and other features. If you make a new
kind of browser (like e.g. Opera mini) it can have its own heuristics
that make sense *for that single browser* without asking _anyone_.
Without relying on web authors doing the correct thing, or changing
anything or even announce to anyone what they are doing. It's opening up
for innovation, good algorithms and smart uses in the future.


That's the basic difference, totally different. :-)


With mediaqueries, you don't know at the time when you're prefetching an
image, what box it is in. So many media queries will either not make
sense (so they won't work like authors intend them to), OR the browser
would have to wait until it has layout for it to start fetching images.
Neither of these two would actually be good, so they are in conflict.

I'd also like to give an example on the smart uses in the future for
imgsrc; right-click save could fetch the biggest quality image and save
that one instead of the one it has currently fetched.


Bruce Lawson bru...@opera.com skreiv Tue, 15 May 2012 23:46:44 +0200

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)


No. It only works on device-width also, and it's only a hint, so it's
actually part of your part 2:

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?


Yeah, sounds more like it. But it applies to the whole thing.

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.


Exactly.

But it doesn't seem necessary to saddle authors with (1) to acheive (2),  
as far as I can see.


It's heavily optimized for the usecase that will happen most often: for
retina type displays:

img src=odin-in-suit.jpg srcset=odin-in-s...@2.jpg 2x



bruce-speaking-for-myself-not-Opera


I'm not speaking for Opera either, but we do work for Opera, and it's
hard to disclaim everything always.


I hope it made sense.

--
Odin Hørthe Omdal (odinho/Velmont) · Opera Software


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

2012-05-15 Thread Silvia Pfeiffer
On Wed, May 16, 2012 at 8:37 AM, Odin Hørthe Omdal odi...@opera.com wrote:
 Andy Davies dajdav...@gmail.com wrote:

 Looking at the srcset proposal it appears to be recreating aspects of
 media-queries in a terse less obvious form...

 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...


 Ah! What a truly great question, so simple.

 The answer is: no, it is not media-queries although they look like it. A
 big problem is that it's so easy to explain it by saying it's just like
 media-query max-width, rather than finding the words to illustrate that
 they are totally different.

 The *limited effect* also feels similar which doesn't help the case at
 all.

 So, even though I have a rather bad track record of explaining any
 thing, I'll try again:

 Media queries come from the client side. They allow the author of a web
 page to tell exactly how she want to lay out her design based on the
 different queries. The browser *HAS* to follow these queries. And also,
 I don't think (please correct me if wrong) the media query can be subset
 to only the stuff that's really meaningful to do at prefetch-time.

 The srcset proposal, on the other hand, are purely HINTS to the browser
 engine about the resources. They are only declarative hints that can be
 leveraged in a secret sauce way (like Bruce said in another mail) to
 always optimize image fetching and other features. If you make a new
 kind of browser (like e.g. Opera mini) it can have its own heuristics
 that make sense *for that single browser* without asking _anyone_.
 Without relying on web authors doing the correct thing, or changing
 anything or even announce to anyone what they are doing. It's opening up
 for innovation, good algorithms and smart uses in the future.


 That's the basic difference, totally different. :-)

If that's the case, would it make sense to get rid of the @media
attribute on source elements in video and replace it with @srcset?

Silvia.


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

2012-05-15 Thread Odin Hørthe Omdal
Silvia Pfeiffer silviapfeiff...@gmail.com skreiv Wed, 16 May 2012  
00:57:48 +0200



Media queries come from the client side. They allow the author of a web
page to tell exactly how she want to lay out her design based on the
different queries. The browser *HAS* to follow these queries. And also,
I don't think (please correct me if wrong) the media query can be subset
to only the stuff that's really meaningful to do at prefetch-time.

The srcset proposal, on the other hand, are purely HINTS to the browser
engine about the resources. They are only declarative hints that can be
leveraged in a secret sauce way (like Bruce said in another mail) to
always optimize image fetching and other features. If you make a new
kind of browser (like e.g. Opera mini) it can have its own heuristics
that make sense *for that single browser* without asking _anyone_.
Without relying on web authors doing the correct thing, or changing
anything or even announce to anyone what they are doing. It's opening up
for innovation, good algorithms and smart uses in the future.

That's the basic difference, totally different.


If that's the case, would it make sense to get rid of the @media
attribute on source elements in video and replace it with @srcset?


Video is at least a bit different in that you don't expect it to be fully  
loaded and prefetch at such an early stage as img. But I've been thinking  
about that since I read something like we already have media queries in  
source for video, but it's not really implemented and used yet.


I'm not sure. What do you think? As far as I've seen, you're highly  
knowledgeable about video. Why do we have mediaqueries on video element?  
Do we have a use case page? Doing the same as whatever img ends up doing  
might be a good fit if the use cases are similar enough. Would be nice to  
be consistent if that makes sense.


--
Odin Hørthe Omdal · odinho / Velmont · Opera Software


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

2012-05-15 Thread Jeremy Keith
Odin wrote:
 It's heavily optimized for the usecase that will happen most often: for
 retina type displays:
 
img src=odin-in-suit.jpg srcset=odin-in-s...@2.jpg 2x

Okay. This is also what Ted said about the srcset proposal and it makes a lot 
of sense for that use case.

But it seems far less suited to the use-case of art-directed image decisions 
i.e. allowing the author to specify which image should be displayed (based on 
some criteria, possibly the viewport size).

Jason does a good job of differentiating both use-cases here:

http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/

 1. How do we enable authors so that they can display different images under 
 different conditions based on art direction?

 2. Enabling authors to provide different resolutions of images based on a 
 variety of conditions.

The srcset proposal that has been thrown into the spec looks like a good answer 
for that second use-case but it doesn't attempt to tackle the first use-case.

Now ideally we'd find one solution that solves both use-cases but after the 
discussion here and in IRC I think that's looking increasingly unlikely.

So if we can agree that srcset is a good solution for handling retina 
displays and other secret sauce conditions (like bandwidth, as Tab blogged 
about), can we move on to trying to find a different solution for the other use 
case?

I *suspect* that the solution for the art-direction use-case could look almost 
exactly like media queries (because the use-case is so similar to common 
use-cases for media queries).

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/




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

2012-05-15 Thread Kornel Lesiński
On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann code...@gmail.com  
wrote:


The fetish for brevity is something I never understood. More  
understandable code is faster to write than cryptic short code.


There is significant difference in verbosity for a *very common case* of  
serving images for high-dpi (Retina) display (which I suspect is only  
going to get more common):


img src=lowdpi srcset=hidpi 2x

vs

picture
source media=(min-device-pixel-ratio: 2) src=hidpi
img src=lowdpi
/picture


It will get tiring when it'll have to be used for every image on the page.

Authors couldn't be bothered to type extra markup for all vendor's  
prefixes in CSS. Nobody bothered with verbose SVG gradient syntax which  
was usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters.


--
regards, Kornel Lesiński


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

2012-05-15 Thread Kornel Lesiński
On Tue, 15 May 2012 23:57:48 +0100, Silvia Pfeiffer  
silviapfeiff...@gmail.com wrote:



Media queries come from the client side. They allow the author of a web
page to tell exactly how she want to lay out her design based on the
different queries. The browser *HAS* to follow these queries. And also,
I don't think (please correct me if wrong) the media query can be subset
to only the stuff that's really meaningful to do at prefetch-time.

The srcset proposal, on the other hand, are purely HINTS to the browser
engine about the resources. They are only declarative hints that can be
leveraged in a secret sauce way (like Bruce said in another mail) to
always optimize image fetching and other features. If you make a new
kind of browser (like e.g. Opera mini) it can have its own heuristics
that make sense *for that single browser* without asking _anyone_.
Without relying on web authors doing the correct thing, or changing
anything or even announce to anyone what they are doing. It's opening up
for innovation, good algorithms and smart uses in the future.


That's the basic difference, totally different. :-)


If that's the case, would it make sense to get rid of the @media
attribute on source elements in video and replace it with @srcset?


I think something like that would be perfect.

In fact, I'd keep @media, because it serves some cases very well (I see  
dpi/bandwidth optimisation as a problem orthogonal to layout adaptation:  
http://geekhood.net/MediaQuery-vs-PerfQuery.png)



It may be enough to add another attribute that describes image properties,  
and can be used either alone or with conjunction with MQs:


picture
source scale=1 src=low
source scale=2 src=high
/picture

would be equivalent to:

img srcset=low 1x, high 2x

(I've proposed that in the RespImg community group)


And combination of the two opens new possibilities:

picture
source scale=1 src=low-narrow media=(orientation:portrait)
source scale=2 src=high-narrow media=(orientation:portrait)
source scale=1 src=low-wide media=(orientation:landscape)
source scale=2 src=high-wide  media=(orientation:landscape)
/picture

--
regards, Kornel Lesiński


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

2012-05-15 Thread Tab Atkins Jr.
On Tue, May 15, 2012 at 4:23 PM, Jeremy Keith jer...@adactio.com wrote:
 Odin wrote:
 1. How do we enable authors so that they can display different images under 
 different conditions based on art direction?

 2. Enabling authors to provide different resolutions of images based on a 
 variety of conditions.

 The srcset proposal that has been thrown into the spec looks like a good 
 answer for that second use-case but it doesn't attempt to tackle the first 
 use-case.

 Now ideally we'd find one solution that solves both use-cases but after the 
 discussion here and in IRC I think that's looking increasingly unlikely.

Hm, I'm confused.  The NNNw and NNNh parts of the microsyntax are
precisely intending to solve the (1) case.  They're more-or-less
equivalent to using min-width and min-height Media Queries.

Looking through the list of Media Queries, it seems that the only
useful ones for art-direction style changes are the width/height ones,
and maybe the monochrome or color ones.  We can always add the latter
to the microsyntax if necessary (their syntax in MQ is pretty weird).

I'm not aware of any plans for future MQs that would be very useful here either.

~TJ


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

2012-05-15 Thread Boris Zbarsky

On 5/15/12 7:33 PM, Kornel Lesiński wrote:

In fact, I'd keep @media, because it serves some cases very well (I see
dpi/bandwidth optimisation as a problem orthogonal to layout adaptation:
http://geekhood.net/MediaQuery-vs-PerfQuery.png)


@media on video source is terrible for layout adaptation: it's only 
considered when selecting a source.  So if you load the page, then turn 
your device so it's in landscape mode (or resize your browser window or 
whatever), the source won't change, even though which source matches the 
medium might have just changed.


Is the expectation that device-adapting images will reload from the new 
URI in cases like the above?  Or not?  Both answers have some problems.  :(


-Boris


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

2012-05-15 Thread D. Pitchford

On 2012-05-15, at 7:23 PM, Kornel Lesiński wrote:

 On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann code...@gmail.com wrote:
 
 The fetish for brevity is something I never understood. More understandable 
 code is faster to write than cryptic short code.
 
 There is significant difference in verbosity for a *very common case* of 
 serving images for high-dpi (Retina) display (which I suspect is only going 
 to get more common):
 
 img src=lowdpi srcset=hidpi 2x
 
 vs
 
 picture
 source media=(min-device-pixel-ratio: 2) src=hidpi
 img src=lowdpi
 /picture
 
 
 It will get tiring when it'll have to be used for every image on the page.
 
 Authors couldn't be bothered to type extra markup for all vendor's prefixes 
 in CSS. Nobody bothered with verbose SVG gradient syntax which was usable 
 before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters.
 
 -- 
 regards, Kornel Lesiński


This brings up a very good point: multiplying the number of images.

I'll go one step further and suggest a hypothetical (which is not really a 
hypothetical):
- Build out either proposals to include more sources so each are maxed out for 
all breakpoints, resolutions, etc. which have propagated throughout a large 
website.
- The time has come for a redesign, and based on the new design, all 
breakpoints have changed from 768px to 800px, a 3x resolution has been 
introduced by 'X Company' and add in X as an additional workflow variable.

As an author, am I to assume that I now need to manually update each and every 
srcset or picture to align with the new design?
With either proposal this does not seem like the most efficient way for anyone 
to spend their time, and is opening a door to a *huge* maintenance issue.

I dread the day when I have to dig through, possibly hundreds of pages, with 
multiple images per, to update the breakpoints and resolutions.
Surely there's a better way to manage breakpoints on a global level rather than 
burying the specifics within the elements or attributes themselves.

See the thread here: 
http://www.w3.org/community/respimg/2012/04/26/syntax-issue-with-displaying-high-resolution-images-in-the-picture-element-how-a-mole-hill-could-turn-into-a-mountain/
See example here from Brett Jankord: https://gist.github.com/2509534

I would hope than any solution to responsive images takes maintenance a little 
more serious than it has up to this point, as it seems more of an afterthought 
than anything.
Both proposals at this point regardless of semantics, syntax, verbosity or 
terseness will do no one any favours, and will have huge ramifications in areas 
nobody is talking about.

Copy/Paste from the example gist above, which I can very much see in happen in 
the wild:

picture alt=Alt tag describing the image represented 
!--source src=photo-s.jpg/--
source src=photo-s.jpg/ 
source src=phot...@2x.jpg 
media=-webkit-min-device-pixel-ratio:2,-moz-min-device-pixel-ratio:2,-o-min-device-pixel-ratio:
 2/1,min-device-pixel-ratio:2/ 
!--source src=photo-m.jpg media=min-width:321px/--
source src=photo-m.jpg media=min-width:321px/ 
source src=phot...@2x.jpg media=min-width:321px and 
-webkit-min-device-pixel-ratio:2,-moz-min-device-pixel-ratio:2,-o-min-device-pixel-ratio:
 2/1,min-device-pixel-ratio:2/ 
!--source src=photo-l.jpg media=min-width:641px/--
source src=photo-l.jpg media=min-width:641px/ 
source src=phot...@2x.jpg media=min-width:641px and 
-webkit-min-device-pixel-ratio:2,-moz-min-device-pixel-ratio:2,-o-min-device-pixel-ratio:
 2/1,min-device-pixel-ratio:2/ 
!--source src=photo-xl.jpg media=min-width:1281px /--
source src=photo-xl.jpg media=min-width:1281px / 
source src=photo...@2x.jpg media=min-width:1281px and 
-webkit-min-device-pixel-ratio:2,-moz-min-device-pixel-ratio:2,-o-min-device-pixel-ratio:
 2/1,min-device-pixel-ratio:2 / 
noscriptimg src=photo-s.jpg //noscript 
/picture

//Notes
//--
Markup based off of Scott Jehl's picturefill example.
Added commented source elements (needed for IE9, Android 2.1-2.3 and iOS 4.3 
Safari) 
to demonstrate how a real life cross-browser implementation might look like. 
15 lines of code for 1 image :( 



Granted this may be better aligned to a separate topic unto itself, but thought 
it needed to be documented.

Cheers,
D.





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

2012-05-15 Thread Silvia Pfeiffer
On Wed, May 16, 2012 at 9:20 AM, Odin Hørthe Omdal odi...@opera.com wrote:
 Silvia Pfeiffer silviapfeiff...@gmail.com skreiv Wed, 16 May 2012 00:57:48
 +0200

 Media queries come from the client side. They allow the author of a web
 page to tell exactly how she want to lay out her design based on the
 different queries. The browser *HAS* to follow these queries. And also,
 I don't think (please correct me if wrong) the media query can be subset
 to only the stuff that's really meaningful to do at prefetch-time.

 The srcset proposal, on the other hand, are purely HINTS to the browser
 engine about the resources. They are only declarative hints that can be
 leveraged in a secret sauce way (like Bruce said in another mail) to
 always optimize image fetching and other features. If you make a new
 kind of browser (like e.g. Opera mini) it can have its own heuristics
 that make sense *for that single browser* without asking _anyone_.
 Without relying on web authors doing the correct thing, or changing
 anything or even announce to anyone what they are doing. It's opening up
 for innovation, good algorithms and smart uses in the future.

 That's the basic difference, totally different.


 If that's the case, would it make sense to get rid of the @media
 attribute on source elements in video and replace it with @srcset?


 Video is at least a bit different in that you don't expect it to be fully
 loaded and prefetch at such an early stage as img. But I've been thinking
 about that since I read something like we already have media queries in
 source for video, but it's not really implemented and used yet.

Some browsers support @media in video for min/max width and height
specifications. But I believe the use case is more like the one we are
trying to solve with @srcset than a traditional media queries use
case.


 I'm not sure. What do you think? As far as I've seen, you're highly
 knowledgeable about video. Why do we have mediaqueries on video element?
 Do we have a use case page?

Hehe, thanks. :-) But media queries were in video before I arrived,
so I missed the whole discussion around it and how it got there. Some
of the browsers that implement support for it should speak up.


 Doing the same as whatever img ends up doing
 might be a good fit if the use cases are similar enough. Would be nice to be
 consistent if that makes sense.

I'm not 100% sure I grok the difference between media queries and
@srcset. I threw this question into the mix to see the reaction -
maybe we need both? What would that even mean?

In addition, I wonder about the adaptive streaming case where byte
ranges from different files are being switched to dynamically during
playback because of bandwidth change. For video, the solution seems to
be: use a manifest file in your @src (such as DASH) and rely on the
browser to pick between the files. Or you use javascript:
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
. An attribute like @srcset would allow listing the alternative files
directly in the HTML file. That may be preferable?

More questions than answers right now, but we should think
consistently between audio, video and images.

Cheers,
Silvia.


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

2012-05-15 Thread Anselm Hannemann Web Development
You might remember about my proposal 9 months ago. If not you can see it here: 
https://gist.github.com/1158855

img src=http://cdn.url.com/img/myimage_xs.jpg; 
media-xs=(min-device-width:320px and max-device-width:640px) 
media-xs-src=http://cdn.url.com/img/myimage_xs.jpg;  
media-m=(min-device-width:640px and max-device-width:1024px) 
media-m-src=http://cdn.url.com/img/myimage_m.jpg;  
media-xl=(min-device-width:1024px) 
media-xl-src=http://cdn.url.com/img/myimage_xsl.jpg;


img src=http://cdn.url.com/img/myimage_xs.jpg; 
media-xs-src=http://cdn.url.com/img/myimage_xs.jpg;  
media-m-src=http://cdn.url.com/img/myimage_m.jpg;  
media-xl-src=http://cdn.url.com/img/myimage_xsl.jpg;


This is between the @srclist and the picture-element. It has MQ (which are 
optional imo, of course the browser should have a standard MQ (how ever this 
can look like and might feature bandwidth also)) and a sourcelist. And it 
features a html-common usage while being shorthand.
I also believe that if the developers should ever be provided with a bandwidth 
API this could be handled via media-queries.

The first example shows that a developer wants to specifically target specific 
screen sizes with a MQ while in the second it is up to the browser which one is 
used.
At least the normal src= is thought as fallback behavior for older browsers.

 Doing the same as whatever img ends up doing
 might be a good fit if the use cases are similar enough. Would be nice to be
 consistent if that makes sense.
 
 I'm not 100% sure I grok the difference between media queries and
 @srcset. I threw this question into the mix to see the reaction -
 maybe we need both? What would that even mean?

I don't know if we need both. Why should we? Because @media-query features are 
currently not enough? Standard behavior which is build in a browser won't need 
any of these solutions, right? Also the picture-element does not *require* a 
MQ. It can also be used to just serve a list of sources and let it up to the 
browser what to fetch.

 In addition, I wonder about the adaptive streaming case where byte
 ranges from different files are being switched to dynamically during
 playback because of bandwidth change. For video, the solution seems to
 be: use a manifest file in your @src (such as DASH) and rely on the
 browser to pick between the files. Or you use javascript:
 http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
 . An attribute like @srcset would allow listing the alternative files
 directly in the HTML file. That may be preferable?

This sounds good but too complicated for a normal developer and you have to see 
that we also should respect CMS implementations.
I don't know (but probably only don't understand the technique correct) if this 
is not too complicated?

 More questions than answers right now, but we should think
 consistently between audio, video and images.

That is what I totally support except there are already adaptive streaming 
technologies for video-formats but not for pictures (which is another topic I 
came up against a brick-wall).
-Anselm