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. 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
