On Sep 6, 2012, at 7:26 AM, Simon Pieters wrote: > On Wed, 05 Sep 2012 19:45:41 +0200, Mathew Marquis <m...@matmarquis.com> > wrote: > >> I can say for my own part: manipulating strings is far more difficult than >> manipulating the value of individual attributes. It’s hard to imagine a >> situation where I’d prefer to muck through a space/comma separated string >> rather than a set of independent elements and attributes. Unless the plan is >> to include an API similar to classList, though it would then be occupied by >> a set of strings describing disparate information. > > The implementation complexity for multiple elements is much greater compared > to an attribute (or even several attributes, so long as it's just one > element) plus an API. See > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035784.html and > search for "it doesn't involve multiple elements." in > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html > for why. > >> Given `srcset="img2.jpg 2x 300w, img3.jpg 600w 2x"`, I can only envision a >> classList-style API returning something like one of the following: >> >> 1) [ "img2.jpg", "2x", "300w", "img3.jpg", "600w", "2x" ] >> This obviously isn’t ideal where authors will have no idea what information >> is being manipulated without keeping constant tabs on the current index as >> compared to the string in the markup. Even if the order of these separate >> concerns were normalized, the inclusion or omission of any individual aspect >> of a rule would mean a flurry of `console.log`s in order to figure out which >> index represented which concern — or careful counting of spaces in one’s >> markup, which certainly seems error-prone to me. I know I would certainly >> make mistakes, there. >> >> 2) [ "img2.jpg 2x 300w", "img3.jpg 600w 2x" ] >> We’re still left parsing space-seperated strings for relevant information, >> albeit smaller ones. > > 3) [ { src:"img2.jpg", x:2, w:300 }, { src:"img3.jpg", x:2, w:600 } ] > > Except as host objects so that setting the properties actually updates the > attribute. (src="" can also be exposed in the same API.) > >> I don’t feel there’s much of a case to be made in favor of writing regular >> expressions to parse and manipulate strings, rather than manipulating >> elements and attributes — though, as always, I’m happy to reach out to the >> author community and ask. If I’m completely off-base here — and I may well >> be — I’d certainly be interested in reading more about the plans for an API. > > (3) above doesn't need regexps.
After a quick read through the existing spec for `source`, it seems we wouldn’t be forced to manipulate `source` elements and attributes themselves in order to reevaluate the most appropriate `source` for a given `picture` element. We would instead be setting the `src` on the `picture` element itself. http://dev.w3.org/html5/spec/single-page.html#the-source-element Given the parity between JavaScript’s `matchMedia` and `media` attributes, and given `devicePixelRatio` for determining the appropriate resolution, it would make it simple to determine the most appropriate source before setting it on the `picture` element: then, we need only access one element in the DOM, set a relevant value within a single attribute, and we’re finished. This makes _setting_ values an equally trivial task with either solution—though if the author is inclined towards making layout decisions based on `em`s (an increasingly common practice), those values will have to be converted to pixel-based values in order to work with the extended `srcset` syntax. In terms of retrieving information from either element, the previous discussion stands: we’re left parsing a single string or tapping into a highly-specific API attached to `img` in the case of the extended `srcset` syntax, or accessing standalone elements and attributes in the case of `picture`. The latter certainly seems easier from an authorship perspective; I’m curious as to how much more complication is involved in implementing an API on `img`, to cater to the extended `srcset.` > > -- > Simon Pieters > Opera Software >
