Am 08.02.2012 um 10:43 schrieb Bronislav Klučka: > On 8.2.2012 10:18, David Goss wrote: >> On 8 February 2012 07:42, Anselm Hannemann<[email protected]> wrote: >>> I'd love to have *ability* (just for future use-cases which might come up >>> and I already would have some for tablet-devices and smartphones) to add >>> different media. >>> e.g. we could offer a cropped image for smartphone users which has another >>> context (maybe missing important parts of the img due to crop but it's >>> better for smartphone usage and still has it's right to be there as an >>> diff.image). >>> Would love to hear what you all think about that? >> We're thinking along the same lines here. What I was getting as >> yesterday was that the different<source>s shouldn't necessarily have >> to be *literally* the same image but resized. They could be >> derivatives of the image (your example of cropped is good). The rule I >> suggest is that you must be able to successfully describe all the >> images with the same alt text (which goes on<picture>), so although >> the images are not visually identical they are semantically the same. >> >> The question is whether the<source>s can have optional alt attributes >> themselves so authors can more specifically describe that particular >> variant of the image. My hesitation only comes from wanting to keep it >> clean and simple, and from wanting to reinforce the requirement that >> the images be semantically the same.
Okay but I don't see a problem to offer this as feature. The spec could say: Initially the alt-text of the <picture> element is applied to all derivates. You can set own (different) alt-attributes to a specific derivate if there's the need to do that. If not set, standard alt-attribute is applied. Same goes for other image attributes like title, etc. You don't have to set this (as you specify in parental picture-alement) but you are able to do. I think we shouldn't limit ourselves just to keep it simple. And of course it's the developer's choice to keep it simple. > Hi, > I think that while talking about responsive image, introducing element that > would choose image based on media-query, we should explore more generic > approach... any media > > <media media="all"> > <video media="support: video"> > <source src="blabla.ogg" type="video/ogg" media="min-resolution: 300dpi" /> > <source src="blabla_small.ogg" type="video/ogg" media="max-resolution: > 150dpi" /> > <source src="blabla.mp4" type="video/mp4" media="min-resolution: 300dpi" /> > <source src="blabla_small.mp4" type="video/mp4" media="max-resolution: > 150dpi" /> > </video> > > <picture> > <src href="small.jpg" alt="a headshot of Bob Flemming"media="min-width:320" > /> > <src href="medium.jpg" alt="a head and shoulders shot of Bob Flemming" > media="min-width:480" /> > <src href="large.jpg" alt="a full body portrait of Bob Flemming" > media="min-width:640" /> > </picture> > > <img src="blabla.png" alt="blabla" /> > </media> > > I can imagine e.g. car presentation using this approach, with preferences > based on tree position of media content. > > BTW adding media attribute to video (video -> source) element might be useful > as well... type tells a lot, but not all regarding responsive media content Why do we actually need this new wrapper element? I don't see any reason for this. And what should support: media be? A new media query? Then this is up to CSS. And as far as I understood you correct you want the video to those who support video (btw which device wouldn't as it's only about the tag, not the feature itself?) and a fallback responsive image? If you have a bit more detailed valid approach where and why to use so, I think we can discuss further. But I think this would be a new topic.
