[whatwg] add html-attribute for "responsive images"
dvdgoss at gmail.com
Wed Feb 8 02:24:57 PST 2012
On 8 February 2012 09:59, <whatwg-request at lists.whatwg.org> wrote:
> Date: Wed, 8 Feb 2012 10:59:34 +0100
> From: Anselm Hannemann - Novolo Designagentur <anselm at novolo.de>
> To: Bronislav Klu?ka <Bronislav.Klucka at bauglir.com>
> Cc: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] add html-attribute for "responsive images"
> Message-ID: <3DBE5A43-987B-47B3-8245-F11BC884396A at novolo.de>
> Content-Type: text/plain; charset=utf-8
> 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<anselm at 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.
I take your point about keeping it simple, but I'm still concerned
that the alt attribute being allowed on <source> at all might lead
people to think that the images don't have to be semantically the
same. Maybe this wording:
"The picture element must contain an alt attribute that accurately
describes the image from the src attribute and the images in all child
source elements. Authors may optionally add alt attributes to child
source elements to more specifically describe a variant of the image,
but the parent alt attribute must still be applicable as well."
>> 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" />
>> <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" />
>> <img src="blabla.png" alt="blabla" />
>> 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.
I share your skepticism. It would be nice and neat if there was a
<media> element with a common structure for images, video and audio,
but clearly the <video> and <audio> elements are too well established
already. No sense in rocking that boat now.
More information about the whatwg