On Thu, Oct 24, 2013 at 7:06 PM, Maciej Stachowiak <m...@apple.com> wrote:
> > On Oct 23, 2013, at 11:24 PM, Yoav Weiss <y...@yoav.ws> wrote: > > > On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > >> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. <jackalm...@gmail.com>wrote: >> >>> On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto <koivi...@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.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev