[webkit-dev] The SrcN responsive images proposal

[Timothy Hatcher]

On Nov 7, 2013, at 4:27 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher <timothy at apple.com> wrote:
>> On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>> srcset's parsing algorithm *cannot* be extended in the future.  I gave
>>> an example of how it would fail over on blink-dev; I can reproduce it
>>> here if necessary.
>> 
>> I don't subscribe to blink-dev. The WebKit community are the ones you need to convince.
> 
> A simple "Yes" would have sufficed.  I was just asking if I needed to
> demonstrate it.  Take this markup:
> 
> <img srcset="foo 1x, bar 2x || baz 1x, qux 2x">
> 
> You expect this to break into two lists, "foo 1x, bar 2x" and "baz 1x,
> qux 2x", which are then each split as currently proposed.
> 
> However, by the current parsing algorithm, || is read as an
> unsupported descriptor, so it just breaks them into "foo 1x", "bar 2x
> || baz 1x", and "qux 2x".  The middle one is thrown away, because of
> the duplicate x descriptor, and so the whole thing is just parsed to
> the same value as "foo 1x, qux 2x", which is completely wrong.

Good point. Thanks for the example. Luckily no one has shipped srcset, so it could be changed.

>>>> 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.
>> 
>> Three whole delimiters. What a crime against humanity!
> 
> I'm not sure why you're being sarcastic and hostile.  Three delimiters
> is a rather large mental tax for developers.  Being dismissive of
> mental complexity isn't very friendly to authors.  It's not the
> be-all-end-all, but it is important.


And that is more of a mental tax than managing multiple attributes? Developers already understand boolean logic. They don't already understand multiple stringed together attributes.

A proposal for a new paradigm of using multiple attributes deserves some resistance, careful consideration and exploration of alternatives. I feel my factual example of <path d> was flippantly tossed aside. So I responded in jest.

— Timothy Hatcher