On Nov 15, 2013, at 3:00 PM, Tab Atkins Jr. <[email protected]> wrote:
> On Fri, Nov 15, 2013 at 12:39 PM, Adam Barth <[email protected]> wrote: >> Do you have an alternative proposal aside from src-N? Recall that >> src-N has been rejected by WebKit and therefore is no longer viable. > > Hey, WebKit, what's your answer if we just take src-N and use a || > separator to cram them all into a single attribute? Otherwise > identical proposal; none of this "gradually expand srcset" thing. > > I think this is a terrible idea, and plenty of actual authors agree > with me, but if multiple attributes is the one thing that's acting as > a deal-killer for implementors, then screw it, we can mitigate the > pain with an OM later. May god have mercy on our souls, etc. I can't speak for all WebKit developers or even all with an interest in this, but my thoughts are as follows: The src-n proposal with the following changes seems likely reasonable: - In a single attribute (ideally named "srcset" to avoid gratuitous renaming) with || or some other separator - viewport-urls syntax removed or changed to be more human-understandable The latest style-based <img>/content proposal seems reasonable if the following issues could be addressed: - Always loads src per current browser behavior (might be fixable by omitting 'src' attribute). - Not obvious if preload scanning can reasonably be expected to resolve CSS selectors (hopefully parser/preloading experts can weigh in). I personally somewhat prefer the style-based proposal if the issues are addressed, as it has less surface syntax. It would probably also have to be combined with vanilla x-only srcset to do resolution scaling combined with art direction, without forcing sizes to be set explicitly. Regards, Maciej
