[webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> 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.
>
>
Out of curiosity, what would be the benefits of such a restriction?

When thinking about the feature's implementation for Blink, I found it
easier to iterate once over the element's attribute, create a vector
containing all the srcN attributes (so all attrs that start with "src-"),
sort it according to attribute numeric order, and return that vector when
the srcN attributes are requested from the element. For the
HTMLPreloadScanner, I'd probably need to create a similar vector attribute
by attribute, sort it at the tag's end, and send it to the main thread.

Wouldn't a similar approach work for WebKit?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131024/05d32433/attachment.html>