On Wed, 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?
>

We're considering to implement an optimization that takes the advantage of
parsed attributes being a finite set at the compilation time.

Having this feature will make it much harder to implement such an
optimization.  Note that data-* attributes don't need to be parsed since it
doesn't synchronously update Element's internal states.

- R. Niwa
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to