Re: [whatwg] Features for responsive Web design

On Sep 4, 2012, at 3:47 PM, Ian Hickson wrote:
>> 
>> [...]
>> 
>>> On Thu, 24 May 2012, Florian Rivoal wrote:
>>>> 
>>>> <picture>
>>>>  <source srcset="normal.jpg 1x, highres.jpg 2x">
>>>>  <source media="(max-width:768px)" srcset="ipad.jpg 1x, ipad3.jpg 2x">
>>>>  <source media="(max-width:320px)" srcset="iphone.jpg 1x, iphone4.jpg
>>>> 2x">
>>>>  <img src="normal.jpg">
>>>> </picture>
>>> 
>>> I don't understand why this is better than:
>>> 
>>>    <img src="normal.jpg" srcset="highres.jpg 2x,
>>>                                  ipad.jpg 768w 1x, ipad3.jpg 768w 2x,
>>>                                  iphone.jpg 320w 1x, iphone4.jpg 320w 2x"
>>>         alt="...">
>>> 
>>> ...which as far as I can tell does exactly the same thing.
>> 
>> It is better because art direction and bandwidth use cases can be solved
>> differently in an appropriate manner:
>> - For the bandwidth use case, no MQ is needed, but only some information on
>> the sources available to let the UA decide which source to load.
>> - For the art direction use case OTOH, the <picture> element is more intuitive
>> to handle and also easier to script, as sources can be added or removed via
>> DOM.
> 
> I don't understand why it's more intuitive and easier. It seems way more 
> unwieldly.

I’m not sure how exactly to prove to you that developers find the extended syntax unintuitive apart from continuing to point out the things that developers themselves have said on the topic, and I’m still not certain how the way it “feels” trumps the sentiments that you’ve read for yourself. I suppose we’ve reached an impasse.

> 
> Whether it's easier for script is hard for me to say, because I don't 
> really understand what scripts are going to be doing here. Can you 
> elaborate? What will scripts need to do here?
> 
> If it is harder to script, we can always provide a dedicated API.
> 
> Manipulating <picture> from script would be a huge pain -- you'd have to 
> be manipulating lots of elements and attributes.
> 

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.

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.

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.