My perspective on this topic is that we've been bikeshedding this topic for a long time. We should just ship srcset and be done with it. Having every browser ship srcset is much better for authors than waiting around for the best possible shade of blue.
If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10.so that we can enumerate all parsed attributes statically at the compilation time.
Adam wrote:
> If srcset addresses 80% of the use cases, then I think we should just ship srcset and worry about the rest of the use cases in the future.
The problem is srcset addresses only a small fraction of the use cases. I just looked through 40 random responsive designs on http://mediaqueri.es, and 88% of them featured images that were shown at different sizes depending on the viewport width. That's something the current DPR-switching-only srcset is incapable of handling; and the proposed 'w' unit for srcset, which is intended to address that use case, doesn't actually work for the subtle reasons I explained in http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/
Yoav wrote:
> it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)
I can imagine, that in a 12-column responsive grid, you might possibly end up needing 12 breakpoints. I don't feel particularly strongly about this; but if we must have a limit, would 99 still satisfy Ryosuke's performance goals?
I've discussed srcN with WebKit's kling on #webkit: http://pastebin.com/c5smGv6QHe (as well as rniwa in a previous discussion) seems supportive of the use cases. He will support the feature if it is limited to a small number of possible attributes, e.g. src1-src9.The RICG will be supportive of such a limitation, if it speeds up adoption, as it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)
On Mon, Nov 4, 2013 at 3:24 AM, Yoav Weiss <yo...@yoav.ws> wrote:
I've discussed srcN with WebKit's kling on #webkit: http://pastebin.com/c5smGv6QHe (as well as rniwa in a previous discussion) seems supportive of the use cases. He will support the feature if it is limited to a small number of possible attributes, e.g. src1-src9.The RICG will be supportive of such a limitation, if it speeds up adoption, as it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)That's not what I intended to say.
On Mon, Nov 4, 2013 at 11:39 PM, Ryosuke Niwa <rn...@chromium.org> wrote:
On Mon, Nov 4, 2013 at 3:24 AM, Yoav Weiss <yo...@yoav.ws> wrote:
I've discussed srcN with WebKit's kling on #webkit: http://pastebin.com/c5smGv6QHe (as well as rniwa in a previous discussion) seems supportive of the use cases. He will support the feature if it is limited to a small number of possible attributes, e.g. src1-src9.The RICG will be supportive of such a limitation, if it speeds up adoption, as it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)That's not what I intended to say.I meant to say you are supportive of the use cases. I didn't mean to imply you're supportive of the feature as is. Andreas Kling is the one that is supportive of it (as long as the number of attributes is upper bound). I apologize if i wasn't clear enough.
I agree with Adam, we've bikeshedded a long time.
srcset="... || ..." was thrown out as a possible extension on
webkit.org. Was that a serious answer to this problem? Is HTML
attribute parsing defined in such a way so that content with || could
be backwards compatible with engines which don't yet support it?
On Nov 5, 2013, at 9:16 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:Just as a reminder: Apple is shipping with this attribute for several weeks.
> In particular, since FF and Blink don't seem to have any technical
> problems with the unbounded attributes, I'm prepared to simply ignore
> secret feedback and let WebKit deal with webdev pressure to implement.
For what it's worth, I also think the multiple attribute syntax is ugly. More importantly, it's not so obviously better than the srcset syntax with a delimiter that it's worth the months of delay that arguing over this costs, IMHO.
On Wed, Nov 20, 2013 at 9:48 AM, Adam Barth <aba...@chromium.org> wrote:Ah, I'd missed that, and you didn't re-raise it for src-N, where it's
> Difficult for me to tell from that link, but does this new iteration of
> <picture> address the implementation issues I raised in
> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/MlE9vYVUlzg/lohBvySEIegJ>?
> Please note that we now actually do run the preload scanner on a background
> thread whereas at the time I wrote that email, we were only considering the
> possibility of running the preload scanner on a background thread.
equally problematic.
We'd need to ship information about MQs over to the preload scanner
thread. If necessary, we can define a subset that are recognized by
the preloader, such as just the "width" and "height" MQs. These are
no more problematic than the w/h descriptors in full srcset were. I
suppose 'resolution', too, since the preloader will need to know
resolution information *anyway* to make a decision among the
densities. We can see what else might be interesting and possible, as
there are several MQs that are good for accessibility.
I already have a PoC implementation of such "off the main thread" MQ evaluation inside the HTMLPreloadScanner (CL). The only thing holding it back is the fact that the CSS parser is not thread-safe, and in particular MediaQueryExp isn't. In the CL I've resolved it in a sub-optimal manner, but I'm certain that a better way can be found.
We won't be able to support those engineering constraints going forward. The state needed to evaluate media queries simply doesn't exist on the parser thread, and it certainly won't exist if we move the preload scanner into a future network process.
As discussed six months ago, we won't be able to support arbitrary media queries, which means we won't be able to implement <picture>.