[webkit-dev] The SrcN responsive images proposal

Tab Atkins Jr. jackalmage at gmail.com
Thu Nov 7 14:43:50 PST 2013

On Thu, Nov 7, 2013 at 2:31 PM, Noam Rosenthal <noam at webkit.org> wrote:
>> > 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.
>> Please don't try to use reducto ad absurdum; it usually gives absurd
>> results.  The reasoning for multiple attributes is not "because it's a
>> list", it's because it's a list of lists, and would require three
>> different delimiters.
> The "style" attribute is perhaps a better example, as it is in some cases a
> list of lists, e.g.
> <div style="transform: rotate() translate(); background: red
> url(foobar.png)" />
> A list of lists in markup is usually expressed as either sub-elements or as
> non-markup syntax inside an attribute; Enumerated attributes are highly
> unusual.

Yeah, that's a reasonable counter-example.  Note, though, that using
style='' for more than testing tweaks is terrible and warned against
by virtually every style guide.  If you're hand-authoring, using
<style> is virtually always easier and more readable.  If you're using
JS, using el.style is far simpler; literally manipulating the style
attribute's value from JS would be insane.  Using style='' from
server-side code is acceptable, but then all the complexity is hidden
from you anyway.

Translating this over to src-N, hand-authoring is a real use-case, so
it's important.  We don't yet have an API, but manipulating smaller
chunks in single attributes is likely easier than manipulating the
whole thing (but there are tradeoffs as well, so it may be a wash).
Server-side generation doesn't care either way, so that's a wash.

I'm pretty sure the argument is almost entirely around hand-authoring,
where experience with style='' shows that lists-of-lists are bad.


More information about the webkit-dev mailing list