[whatwg] The src-N proposal
w3c at marcosc.com
Mon Nov 18 09:19:53 PST 2013
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.
More information about the whatwg