[whatwg] Features for responsive Web design

[Simon Pieters]

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

-- 
Simon Pieters
Opera Software