W3C home > Mailing lists > Public > public-respimg@w3.org > September 2013

Re: srcN - Alternative to picture and srcset

From: Cory Brown <oh.wise.man@gmail.com>
Date: Fri, 27 Sep 2013 08:25:35 -0400
Message-Id: <3A6FD2DA-8E4D-4E8E-8D0A-DDBECD3C33C8@gmail.com>
Cc: Attiks <attiks@gmail.com>, Shane Hudson <Shane@shanehudson.net>, Marcos Caceres <marcos@marcosc.com>, "public-respimg@w3.org" <public-respimg@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
To: Robin Berjon <robin@w3.org>
> the algorithm does not in the least care that the numbers are sequential so long as they sort properly

It's not a deal breaker for me necessarily, but if the numbers serve no functional purpose other than to not have multiple indents ally named attributes, I'd like to see if we can work around that. The existence of the numbers could easily be misunderstood to have some priority value to them. 

> I wonder if Image.src should reflect the winning candidate (and if we should trigger an event when that changes).

I believe src can treated as an attribute where as currentSrc can be treated as a property, meaning it reflects actual state. 

> On Sep 27, 2013, at 8:00 AM, Robin Berjon <robin@w3.org> wrote:
> 
>> On 27/09/2013 13:14 , Attiks wrote:
>> I have to agree with Shane, it feels hacky to number them, also if you
>> want to remove one later, you'll have a gap, which does not look nice
>> and no idea how it's going to be handled.
> 
> It's handled well, the algorithm does not in the least care that the numbers are sequential so long as they sort properly.
> 
> In fact, just to make it easy to insert new values later without renumbering the best practice is probably to use larger increments, e.g. src5, src10, src15... Anyone who's ever had to code using GOTO <LINE> will be intimately familiar with what I mean.
> 
> I wonder if Image.src should reflect the winning candidate (and if we should trigger an event when that changes).
> 
> -- 
> Robin Berjon - http://berjon.com/ - @robinberjon
> 
Received on Friday, 27 September 2013 12:26:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:40 UTC