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.
--
Simon Pieters
Opera Software
