- 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