Re: SVG Feedback on HTML5 SVG Proposal

On Mar 23, 2009, at 20:17, Anne van Kesteren wrote:

> On Mon, 23 Mar 2009 18:53:39 +0100, Henry S. Thompson  
> <ht@inf.ed.ac.uk> wrote:
>> Ian wrote:
>>> My understanding is that doing this would introduce an unacceptable
>>> performance penalty for implementations.
>>
>> So, I'm perplexed.
>>
>> All the browsers I'm familiar with (I haven't installed Chrome yet)
>> support XML+XSLT via the xml-stylesheet processing instruction.
>>
>> So they all have case-preserving tokenizers whose performance is
>> acceptable for the people who serve and read XML+XSLT.
>>
>> Who then has ruled that a case-preserving tokenizer "imposes an
>> unacceptable performance penalty", and on the basis of what evidence?
>
> Henri elaborates that in the very next e-mail of that thread (and  
> has elaborated on it in the past as well):
>
>  http://lists.w3.org/Archives/Public/public-html/2009Mar/0240.html
>
> (Second instance of "Indeed" has the details.)

I should add that the pre-interned well-known token objects also carry  
a carefully chosen integer that the tree builder switches on to decide  
which behavior case to run for a start or end tag token. Having  
integers like this on the tokens was one reason for the pre-interned  
token object design.

See for example:
http://hg.mozilla.org/users/mrbkap_mozilla.com/html5parsing/file/6611e8bac15f/content/html/parser/src/nsHtml5ElementName.cpp#l251
http://hg.mozilla.org/users/mrbkap_mozilla.com/html5parsing/file/6611e8bac15f/content/html/parser/src/nsHtml5TreeBuilder.cpp#l893

In the future, I intend to[1] add DOM node creation function pointers  
to the token objects to avoid a later lookup when the right  
constructor needs to be called to create right class instances for  
nodes that have element-specific subclasses in the DOM implementation.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=483155
-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 24 March 2009 12:08:29 UTC