[whatwg] add html-attribute for "responsive images"
Matthew Wilcox
mail at matthewwilcox.com
Tue Feb 7 06:00:01 PST 2012
I'm glad this is making a reasonable amount of sense to people :)
Please note however that this isn't just a case of "the image is cropped".
It could be an entirely different image *as long as* it still carries the
same semantic message. In that, the image in the About example is merely to
give a visual representation of someone. As long as all of the scaled
images do that, they do not need to be *the same image* re-cropped. In
fact, it would be better in this case to have different images. Hence why
it makes sense to have the ability to over-ride the alt attribute on each
source.
There's nothing to stop us saying that an alt attribute can be declared on
the default image, and is only over-written if the <src> contains a new alt
attribute?
-Matt
On 7 February 2012 13:42, Mathew Marquis <mat at matmarquis.com> wrote:
>
> On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote:
>
> On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote:
>
> Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
>> > To me this makes most sense /from an author perspective/ (I make no
>> claims as to how practical this really is):
>> >
>> > <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" />
>> >
>> > <!-- fallback for old browsers with no support for picture element)
>> -->
>> > <img src="default.jpg" alt="A photo of Bob Flemming" />
>> > </picture>
>> >
>> > The reason being:
>> >
>> > * it's easy to read
>> > * it uses familiar element structures and properties
>> > * it allows us to adjust to any given media requirement, not just
>> screen size (you could query bandwidth with this > syntax, though I contest
>> bandwidth is the domain of server side adaption rather than client side)
>>
>> This is a good solution except the fallback img element would be twice
>> loaded in your case which is not good.
>> There should be the img element containing the standard (normal) size and
>> src elements to add diff. other resolutions. With that the browser won't
>> load the resource twice.
>>
>
> Would it? I think Matthew's example implies that a supporting browser
> *wouldn't* load the src from the <img> unless none of the <source>s got a
> media match. Right?
>
>
> I’m not sure how it’s intended to work with <video> currently, but I
> believe the fallback is only loaded if <video> is unsupported—if none of
> the sources match, I believe nothing is displayed. I may be wrong, but that
> seems to be the most predictable behavior.
>
>
> The way I proposed it would have the same behaviour but have the <img> as
> the first child element of <picture>, making it more apparent that it's the
> default content as well as the fallback content. Also, it would contain
> important attributes like alt. So:
>
> <picture>
> <img src="default.jpg" alt="A photo of Bob Flemming" />
> <source href="small.jpg" alt="a headshot of Bob Flemming"
> media="min-width:320" />
> <source href="medium.jpg" alt="a head and shoulders shot of Bob
> Flemming" media="min-width:480" />
> <source href="large.jpg" alt="a full body portrait of Bob Flemming"
> media="min-width:640" />
> </picture>
>
> And:
>
> - unsupporting browsers would get default.jpg (but the author could
> implement some JS to run the <source> media queries and swap in the most
> appropriate image if desired)
> - supporting browsers narrower than 320px would also get default.jpg,
> because none of the <source>s would get a media match
> - supporting browsers 320px or wider would get the image from the last
> <source> to get a media match (because a 800px wide screen would match all
> 3 in this example)
>
> I'm not really sure whether <source> should get an alt attribute - my
> thinking is that if one alt attribute doesn't correctly describe all the
> <source>s then perhaps they are different content. Matthew's example does
> make sense, in that the extra alt attributes describe the way the image has
> been cropped (although it's still the same image). But maybe it would be
> better to only allow alt on the <img> to reinforce the idea that all the
> <source>s should basically be the same image albeit
> cropped/monochrome/whatever.
>
>
> I’m with you, here. I’m hesitant to have any logic hinge on the fallback
> img, though, as it wouldn’t be strictly required—the fallback content could
> be, say, descriptive text instead (Granted I wouldn’t do it, but just
> trying to keep things as flexible as possible). I do think all sources
> should be described by a single alt tag, though, possibly on <picture>
> itself?
>
>
> FWIW, whatever becomes of the discussion about sending media-query-like
> data in headers to the server (RWD Heaven: if browsers reported device
> capabilities in a request header), we need this responsive image markup
> regardless.
>
>
> Hear hear!
>
>
> Thanks
>
> David
>
>
>
More information about the whatwg
mailing list