[webkit-dev] The SrcN responsive images proposal

Timothy Hatcher timothy at apple.com
Thu Nov 7 09:24:24 PST 2013


On Nov 6, 2013, at 4:26 PM, John Mellor <johnme at chromium.org> wrote:

> I've suggested before that the attributes could be combined if that's considered simpler. My only concern is that most developers aren't used to putting line breaks in html attributes, so might feel obliged to put all the alternatives on one line, harming readability. But as long as the developer documentation encourages line breaks, that could be fine...

As I replied before, there should only be one attribute — srcset. Given that your micro format extends around parts of the existing micro format of srcset, it just makes sense to reuse the same attribute. Wishing srcset didn't exist doesn't make it go away. Tweaking it is more approachable and should get better support from the WebKit community and likely other venders who are now stalled because of this proposal. Especially since the current viewport syntax in srcset has little-to-no support or implementations. Also if srcset is the attribute, the CSS function srcset() should support the same micro format.

Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one "d" attribute for <path>. Following the your logic, it should be d-N. Sure, <path d="…"> is primarily meant to be written by software. Though, as responsive designs get more complex, people are going to rely on software to generate these src strings too. I surely don't want to be micromanaging the intrinsic widths in a <viewport-urls> set if I need to change the width and export again from Photoshop. Some workflow tool is likely going to generate these and having them in one attribute makes them infinitely easier for a script to manage. (And easier for humans too if things need reordered, as I mentioned earlier.)

— Timothy Hatcher

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131107/8d027a6a/attachment.html>


More information about the webkit-dev mailing list