[webkit-dev] The SrcN responsive images proposal

[Maciej Stachowiak]

On Oct 24, 2013, at 1:35 AM, Michael[tm] Smith <mike at w3.org> wrote:

> Ryosuke Niwa <rniwa at webkit.org>, 2013-10-23 13:22 -0700:
> 
>> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
>>> On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto <koivisto at iki.fi> wrote:
>>>> Ignoring other aspects of this, the idea of making attribute name an
>>>> enumeration is somewhat distasteful. It will require ugly special
>>>> parsing.
>>>> The platform has plenty of attribute values that are lists already.
>>> 
>>> The parsing aspect isn't particularly new - parsing data-* attributes
>>> presents the same problem.  You just need to filter the list of
>>> attributes on the element to look for things with a src- prefix.  I've
>>> heard direct feedback from Yoav, implementing in Blink, that it's not
>>> a big problem.
>> 
>> Just because it was not a big problem in one engine, it doesn't mean it
>> won't be in other engines.
>> 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.
> 
> If you're going to do that, and especially if seems like other engines
> might end up doing that for similar reasons, it seems like we'd be better
> off dispensing with the N part of the proposal and instead have the spec
> just define a discrete set of attribute names, e.g., just src1 to src9.
> 
> A recent discussion thread on the public-respimg at w3.org list suggests that
> in practice even 10 would be higher than the high end of what sites would
> currently actually use:
> 
>  http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0019.html
> 
> Most sites that were looked at just use 2 image source alternatives, and
> the two sites found with the highest number of alternatives just used 6.
> 
> Doing discrete src1 to src9 would still be ugly but it seems less ugly for
> everybody overall than src-N.

It did seem gratuitous to me that the proposal in principle requires sorting of arbitrary-precision decimal integers when there is no obvious use case that requires it. (Fortunately you can probably fake it by doing a length comparison and then a string comparison, but still.)

Regards,
Maciej



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131024/deae8d3f/attachment.html>