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-") and it's O(N^2) for srcN attributes added dynamically with script. It's likely not the best way to implement the feature. I think the authoring complexity is a more relevant consideration than the implementation complexity, though. Cheers, Maciej > 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? > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
