[webkit-dev] The SrcN responsive images proposal

[Tab Atkins Jr.]

On Thu, Nov 7, 2013 at 4:50 PM, Timothy Hatcher <timothy at apple.com> wrote:
> On Nov 7, 2013, at 4:28 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>
>> On Thu, Nov 7, 2013 at 3:43 PM, Timothy Hatcher <timothy at apple.com> wrote:
>>> On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>>> I have a serious suggestion - could we rename srcset to src-n
>>>> (literally, "src-n"), and then just ship it?  This puns in three
>>>> interesting ways:
>> [...]
>>>> This'll let us ship now, and then continue to discuss src-N for a
>>>> while, with whatever solution we land on still having a consistent
>>>> name. Win for authors no matter what the result is.
>>>
>>> No, you are just asking for support to muddy the waters and make the web your science project.
>>
>> I have no idea what this means.  Could you restate your objection in
>> some other way?  This is just a renaming request, mind, for an
>> unreleased feature; it's not unusual.
>
> Literally supporting "src-n" just to test the waters with the idea of introducing src-1..src-99 later is just an abuse of the HTML language and developers attention.

I still have no idea what you mean.  I think that "src-n" and "srcset"
are roughly synonymous as names.  Both seem to appropriately
communicate the semantic of "multiple sources".  It's convenient that
"src-n" puns with "src-1", and is itself a decent name for a concept
that would be useful to add to the src-N proposal, but all by itself,
even if we completely reject src-N, it's still a decent name for the
abilities currently packaged up in srcset.

> Design something right and support it forever.

If you read my proposal email, you'll see that this is an attempt to
design it right, and there is no intention to stop supporting it at
any time.


On Thu, Nov 7, 2013 at 4:34 PM, Benjamin Poulain <benjamin at webkit.org> wrote:
> This just sounds like a bad excuse.

I'd appreciate less hostility, please.

> As far as I know, no browser has shipped
> srcset.

Correct, but you can't say "eh, we can change it, it's not shipped
yet" and "we can't change it, it's already mature" at the same time.
An accurate assessment of srcset is that it's a mature proposal that
is not yet exposed to the web, and so can still be changed or replaced
safely if there is cause for it.


On Thu, Nov 7, 2013 at 4:45 PM, Timothy Hatcher <timothy at apple.com> wrote:
> On Nov 7, 2013, at 4:27 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> 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.

Actually, yes, it is a mental tax.  The reason is that the current
division of src-N attributes reflects a significant division in use -
each separate attribute represents a *distinct* image (a la Art
Direction, where different crops of an image may be used at different
sizes).  Within each attribute, the sources should be identical except
for density.

This is a helpful and significant distinction.  It's easy to
understand that all sources in a single attribute should be for the
same image.  Making the same distinction within the scope of a single
attribute is less obvious.

Additionally, I already talked about the strong visual separation of
separate attributes - it's easy to scan content and see the separate
attributes, but it's much more difficult when scanning to see the ||
separators.

> 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.

Apologies if you believed my response was flippant; it was short, but
serious and to the point.  I explained why the <path d> example wasn't
very good - it's a single (albeit way overcomplicated) list of
commands.  The src-N attributes already contain lists, so they're
comparable.  I'm objecting to combining the src-N attributes into a
single attribute because that produces a *list of lists*, which is a
significant step further in mental complexity.

~TJ