[webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Fri, Nov 8, 2013 at 8:44 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>
> > On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher <timothy at apple.com>
> wrote:
> >> As I replied before, there should only be one attribute — srcset.
> >
> > 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:
> >
> > 1. If src-N is never accepted, it's still an attribute that holds N
> > src values, so src-n works well.
> > 2. If src-N is accepted, but as a single attribute, src-n is just
> > named perfectly to match the proposal name.
> > 3. If src-N is accepted fully, the obvious ordering is clearly src-1,
> > src-2, src-3, ..., src-n, which matches the fallback we want.
> >
> > A guaranteed "last fallback" is legitimately useful for the full src-N
> > proposal, so I'm totally okay with integrating that into my proposal.
> >
> > 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.
>
> Further discussion will go to whatwg, which is a better place to discuss
> technical details of the src-N proposal, but I wanted to comment on this:
>
> (1) In the case that src-N is never adopted, or is adopted in
> single-attribute form, "srcset" matching the CSS image-set() function will
> be more useful than "src-n" matching a hypothetical proposal based on
> multiple attributes.
>
> (2) Neither "src-n" nor "srcset" is super-obvious as a final fallback, but
> either is a rule that could plausibly be learned.
>
> (3) In the absence of considerations about matching anything else, "source
> set" better conveys the idea of selecting from multiple sources than
> "source n", at least to me.
>
> So I don't think your proposal is super helpful to enable a future
> transition. What might be helpful:
>
> (A) Change srcset parsing in implementations now to be compatible to
> extension with an additional list level (for instance, drop everything
> after the first "||").
> (B) Remove support for the "w" and "h" specifiers from srcset
> implementations since no one loves those and they are apparently not really
> adequate to addressing their use case.
>

The "w" and "h" specifiers are not implemented in neither WebKit nor Blink,
so this is a non-issue.


> (C) Ship srcset with these two changes ASAP.
>
> This would leave the field open to either extending the microsyntax or
> adding more attributes or both. And authors will at least have a way to
> address the multi-resolution-only case, a case where I believe we have no
> substantial controversy about the right solution.
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131108/45604cf7/attachment.html>