On Thu, Nov 7, 2013 at 4:50 PM, Timothy Hatcher <timo...@apple.com> wrote: > On Nov 7, 2013, at 4:28 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > >> On Thu, Nov 7, 2013 at 3:43 PM, Timothy Hatcher <timo...@apple.com> wrote: >>> On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. <jackalm...@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 <benja...@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 <timo...@apple.com> wrote: > On Nov 7, 2013, at 4:27 PM, Tab Atkins Jr. <jackalm...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev