<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa <span dir="ltr">&lt;<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss <span dir="ltr">&lt;<a href="mailto:yoav@yoav.ws" target="_blank">yoav@yoav.ws</a>&gt;</span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><span style="color:rgb(80,0,80)">On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa </span><span dir="ltr" style="color:rgb(80,0,80)">&lt;<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>&gt;</span><span style="color:rgb(80,0,80)"> wrote:</span><br>


<div class="gmail_quote"><div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. <span dir="ltr">&lt;<a href="mailto:jackalmage@gmail.com" target="_blank">jackalmage@gmail.com</a>&gt;</span> wrote:</div>



<div class="gmail_extra"><div class="gmail_quote"><div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto &lt;<a href="mailto:koivisto@iki.fi" target="_blank">koivisto@iki.fi</a>&gt; wrote:<br>
&gt; Ignoring other aspects of this, the idea of making attribute name an<br>
&gt; enumeration is somewhat distasteful. It will require ugly special parsing.<br>
&gt; The platform has plenty of attribute values that are lists already.<br>
<br>
</div>The parsing aspect isn&#39;t particularly new - parsing data-* attributes<br>
presents the same problem.  You just need to filter the list of<br>
attributes on the element to look for things with a src- prefix.  I&#39;ve<br>
heard direct feedback from Yoav, implementing in Blink, that it&#39;s not<br>
a big problem.<br></blockquote><div><br></div></div><div>Just because it was not a big problem in one engine, it doesn&#39;t mean it won&#39;t be in other engines.</div><div>If we&#39;re supporting src-N attributes in WebKit, I&#39;d like to see N to have a small upper bound; e.g. 10.</div>





<div>so that we can enumerate all parsed attributes statically at the compilation time.</div></div></div></div></blockquote><div> </div></div></div><div>Out of curiosity, what would be the benefits of such a restriction? <br>


</div></div></div></div></blockquote><div><br></div></div><div>We&#39;re considering to implement an optimization that takes the advantage of parsed attributes being a finite set at the compilation time.</div><div><br></div>
<div>

Having this feature will make it much harder to implement such an optimization.  Note that data-* attributes don&#39;t need to be parsed since it doesn&#39;t synchronously update Element&#39;s internal states.</div><div>

<br>
</div><div>- R. Niwa</div></div></div></div></blockquote><div><br></div><div>Will setting the limit on the number of possible attributes at 99 still enable that optimization?</div><div>Many people (on the RICG&#39;s IRC and on Blink-dev) feel that setting the limit to 9, even if it&#39;d be enough today, leaves fairly little space for future evolution. Setting it to some random number between 10 and 99 feels arbitrary to me. So, will 99 be OK with you?</div>
</div><br></div></div>