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<ans...@novolo.de>  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.

Reply via email to