- From: Miguel Garcia <magarcia2@me.com>
- Date: Wed, 05 Sep 2012 13:09:59 -0500
- To: Mathew Marquis <mat@matmarquis.com>
- Cc: WHATWG List <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, "public-respimg@w3.org" <public-respimg@w3.org>
>> 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? >> >> Manipulating <picture> from script would be a huge pain -- you'd have to >> be manipulating lots of elements and attributes. No more than the already accepted syntax and structure for video. Not that one would really be manipulating tons of elements and attributes but swapping out sources for things like a photo gallery and the like are things that will happen. We should expect the general use cases for script manipulation that exist today for img will naturally migrate to picture if it indeed becomes the new standard. Picture is going to broaden device support scope. If the functionality exists with img as it stands, those use cases should be at least considered in part or in whole for the base scope for picture. As a developer, I cannot stress enough the wasted time that would result from the act of parsing through the srcset syntax. Even with library support, understanding and properly manipulating to initiate a change for something like a photo gallery is unnecessary when compared to the proposed specs inspiration, the video element. I would think it is easier for the js library folks and purists alike to deal with a set of child nodes in js than bloated property lists where additional parsing requirements will result in additional script that ultimately negatively affects bandwidth on lower bandwidth devices. Trading one evil for another isn't in my opinion the goal of the proposed picture element.
Received on Wednesday, 5 September 2012 18:10:30 UTC