W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] Features for responsive Web design

From: Mathew Marquis <mat@matmarquis.com>
Date: Wed, 5 Sep 2012 13:45:41 -0400
Message-Id: <4D057C84-ED11-4275-A2C2-BD7D403D35E8@matmarquis.com>
To: Ian Hickson <ian@hixie.ch>
Cc: WHATWG List <whatwg@whatwg.org>, public-respimg@w3.org

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.

Im 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 Im still not certain how the way it feels trumps the sentiments that youve read for yourself. I suppose weve 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. Its hard to imagine a situation where Id 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 isnt 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 ones 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" ]
Were still left parsing space-seperated strings for relevant information, albeit smaller ones.

I dont feel theres 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, Im happy to reach out to the author community and ask. If Im completely off-base here  and I may well be  Id certainly be interested in reading more about the plans for an API.
Received on Wednesday, 5 September 2012 17:46:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC