[webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Thu, Oct 24, 2013 at 7:06 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Oct 23, 2013, at 11:24 PM, Yoav Weiss <yoav at yoav.ws> wrote:
>
>
> 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.
>
>
> Your described strategy is both not quite correct (srcN attributes are not
> all attributes that start with "src-")
>

I left out the "followed by an integer" part. Obviously, that should be
part of the algorithm.


> and it's O(N^2) for srcN attributes added dynamically with script.
>

The typical case for dynamically added srcN attributes would be adding them
in order (since otherwise, a wasteful resource download might be
triggered). That is very similar to srcset, which when added dynamically,
must be added before the src attribute.
For that case, adding N dynamic attributes to the end of the vector would
have O(N) complexity.
The case for unordered addition can be optimized to O(NlgN) by replacing
the vector with a linked list and adding each new attribute in its order
using binary search.


>
> I think the authoring complexity is a more relevant consideration than the
> implementation complexity, though.
>

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