[whatwg] add html-attribute for "responsive images"

Tim,

Very good suggestion. This would allow us to keep our markup clean and
stash these extra references elsewhere in the code as we see fit.

+1

-- 
Jordan Dobson ? Designer / Developer ? 425-444-8014 ? JordanDobson.com

On Thu, Feb 9, 2012 at 3:11 AM, Tim van Oostrom <tim at depulz.nl> wrote:

> I'm also late in this discussion but followed it globally. Maybe a
> structure like Microdata's itemref="" is an option too.
>
> You could do:
>
> <img src="default.jpg" alt="An image" srcref="placeholder img1-a img1-b
> img1-c">
> <img src="default2.jpg" alt="Another image" srcref="placeholder img2-a
> img2-b img2-c">
>
> <src href="placeholder.jpg" id="placeholder" media="max-width:320px">
>
> <src href="small.jpg" id="img1-a" media="min-width:320px">
> <src href="medium.jpg" id="img1-b" media="min-width:720px">
> <src href="large.jpg" id="img1-c" media="min-width:1200px">
>
> <src href="small2.jpg" id="img2-a" media="min-width:320px">
> <src href="medium2.jpg" id="img2-b" media="min-width:720px">
> <src href="large2.jpg" id="img2-c" media="min-width:1200px">
>
> This gives you the ability to share the sources with multiple img
> elements. For example when you have a placeholder image for devices that
> you do not support.
>
> Tim
>
>
>  On Feb 8, 2012, at 7:29 PM, Jason Grigsby wrote:
>>
>> On Feb 8, 2012, at 8:54 AM, FOUSHEE, SEAN wrote:
>>
>> I'm late to this discussion so pardon me if this has already been
>> discussed, by using the same logic as the<srclist>  why not just
>> create<figlist>  to go along with the<figure>  element?
>>
>>
>> When a bunch of us discussed this on an etherpad a while back, we
>> ruled<figure>  out because:
>>
>> * Completely redefines semantics and content model of an already new
>> element.
>> * Current use includes multiple images
>> * Current use includes non-images like code samples, video, etc.
>>
>> https://etherpad.mozilla.org/**responsive-assets<https://etherpad.mozilla.org/responsive-assets>
>>
>> Of course, this doesn?t mean we were right about ruling it out. :-)
>>
>> -Jason
>>
>>
>> Thanks for the clarification.
>>
>> The fact that the<figure>  element is structured to allow us to define
>> multiple images seems like a good fit for this approach, especially since
>> it's going to end up using the new tag(s) anyway if the page needs to group
>> multiple responsive images together:
>>
>> <figure>
>> <img src="default1.jpg" alt="" list="firstimage">
>> <srclist id="firstimage">
>> <source href="small1.jpg" media="min-width:320px">
>> <source href="medium1.jpg" media="min-width:720px">
>> <source href="fullsize1.jpg" media="min-width:1200px">
>> </srclist>
>> <img src="default2.jpg" alt="" list="secondimage">
>> <srclist id="secondimage">
>> <source href="small2.jpg" media="min-width:320px">
>> <source href="medium2.jpg" media="min-width:720px">
>> <source href="fullsize2.jpg" media="min-width:1200px">
>> </srclist>
>> <!-- etc etc etc -->
>> <figcaption>Multiple responsive images grouped in the figure
>> element</figcaption>
>> </figure>
>>
>> But I agree with David that this feels very bloated, and honestly I'd
>> hate to think of the things my students would throw at me if I were to
>> present this as the approach to handle responsive images in HTML. It's bad
>> enough we have to encode and serve up at least three different video
>> formats with a possible fallback just to utilize the<video>  tag, but to do
>> this for every image would be a nightmare.
>>
>> Sean Foushe?
>> Instructor, Graphic Communications
>> Tarrant County College, NE Campus
>> 828 Harwood Rd.
>> Hurst, TX 76054
>> (817) 515.6596
>> sean.foushee at tccd.edu<mailto:s**ean.foushee at tccd.edu<sean.foushee at tccd.edu>
>> >
>>
>>
>>
>

Received on Thursday, 9 February 2012 03:36:12 UTC