- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 17 Dec 2009 09:25:48 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238 Henri Sivonen <hsivonen@iki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hsivonen@iki.fi --- Comment #19 from Henri Sivonen <hsivonen@iki.fi> 2009-12-17 09:25:48 --- I think this bug should be resolved as WONTFIX. Principled arguments: * We are way past the feature freeze for HTML5. * I think HTML parsing shouldn't be changed to cater to any most-favored JavaScript library. Practical arguments: * Case fixups either bloat the data footprint of the HTML parser or cause more branching at run time. This is somewhat justified for SVG, because 3 out of the top 4 browsers already supported the above-DOM parts of SVG. However, when a vocabulary isn't already natively supported by browsers, we are in a position not to accept this complication again. * In the case of the HTML5 parser in Gecko, the most frequent complaints I get from other developers pertain to the large tables of named characters and to the large tables of known element and attribute names. Bloating those tables only to benefit a most-favored JS library (as opposed to catering to a new Gecko-native feature) seems unattractive. * The alternative tableless idea from http://lists.w3.org/Archives/Public/public-html/2009Nov/0206.html would require deoptimizing the tokenizer compared to what element and attribute name early interning and early case folding optimizations are now possible. I think it doesn't make sense to deoptimize anything in the parser just to cater to a most-favored JS library. * If X3D models tend to be large enough to make considering EXI relevant (see http://lists.w3.org/Archives/Public/public-html/2009Nov/0120.html), surely it doesn't make sense to inline the models (except for small demos) into text/html. When a JS library uses external models and renders them using WebGL, the library could retrieve the XML-serialized models using XHR without any need for changes in the HTML parser. (For example, you could use <canvas data-x3d-src='url-to-.x3d-file'>...</canvas> in markup and have the JS library activate when it finds data-x3d-src, retrieve the model using XHR and render to the canvas using WebGL.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 17 December 2009 09:25:50 UTC