- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 23 Mar 2009 14:14:31 -0400
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
- CC: public-html@w3.org
Henry S. Thompson wrote: > 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. Which is, in the grand scheme of things, pretty much no one. Also, if you're using client-side XSLT performance on the browser is not at the top of your concerns (if it were you'd be doing the transform once on server-side), nor is web page responsiveness (e.g. no incremental rendering with XSLT). > Who then has ruled that a case-preserving tokenizer "imposes an > unacceptable performance penalty", and on the basis of what evidence? Last I heard, browser parser developers; they have presumably done some measurements. I can tell you for a fact that using a case-preserving tokenizer in the HTML parser in Gecko (the current one, not the new one based on HTML5 that's being worked on) would be quite noticeable; there were measurements done on the performance impact before switching to the current model, where tag and attribute names are interned as early as possible and the difference was quite noticeable. -Boris
Received on Monday, 23 March 2009 18:15:30 UTC