W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] The src-N proposal

From: Marcos Caceres <w3c@marcosc.com>
Date: Mon, 18 Nov 2013 17:19:53 +0000
To: Jirka Kosek <jirka@kosek.cz>
Message-ID: <5DAAE6329774488CA1AA207FA33E81B4@marcosc.com>
Cc: whatwg@lists.whatwg.org, Simon Pieters <zcorpan@gmail.com>


On Monday, November 18, 2013 at 3:34 PM, Jirka Kosek wrote:

> On 18.11.2013 14:38, Marcos Caceres wrote:
>  
> > we really need to, srcset. The developer community already made
> > significant sacrifices in compromising on picture because of issues
> > that implementers raised about nested elements
>  
>  
>  
> Are those issues with nested elements described somewhere? I wasn't able
> to find anything and I would really like to know what the issue was.


Simon Pieters (cc'ed) can provide you with the details. He did most of the QA for video and the decision to drop picture was based mainly on his objections and feedback to the RICG.   
  
> > of constituencies. Let’s not further erode those principles for the
> > sake of markup aesthetics.
>  
>  
>  
> It's not just about aesthetics. From markup point of view src-n goes
> against common sense and principles. Existing APIs and languages for
> working with markup don't have easy way to access src-n attributes,
> especially if order based on "n" is significant. This is very different
> from nested elements where it's very easy to iterate over them.

Sure, but what’s the use case for accessing them? Also, given that we have `data-` already, we could look to that if we need some kind of API. This also doesn’t exclude matching on different attributes (class, id, etc.). But it really depends on what you are trying to do, and I don’t know what that is yet.   

Compare this to srcset also, which doesn’t provide any API at all. It’s the same mess - but there was no use case presented that required the need for such an API (the RICG also pointed this out in Bugzilla, and they were unable to come up with a use case - hence srcset provides not API for traversing sources).    
  
> Try to write JS+DOM, or XPath, or ... your preferred language here ...
> code for looping through src-n attributes in a right order. Compare it
> to the same code for subelements, which are ordered and have same name.
>  

Sure, it might suck, or I could write a little javascript to order them and return them with an iterator (won’t be as painful as it would be with srcset). But I’m still not sure what one would achieve with this once the elements have been processed and d/ls have started.  
Received on Monday, 18 November 2013 17:20:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC