On Fri, Nov 8, 2013 at 8:44 PM, Maciej Stachowiak <[email protected]> wrote:
> > On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. <[email protected]> wrote: > > > On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher <[email protected]> > 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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
