Re: [whatwg] Features for responsive Web design

On Sep 6, 2012, at 7:26 AM, Simon Pieters wrote:

> On Wed, 05 Sep 2012 19:45:41 +0200, Mathew Marquis <mat@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
>