- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Nov 2010 15:10:31 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11204 --- Comment #7 from David Carlisle <davidc@nag.co.uk> 2010-11-03 15:10:30 UTC --- (In reply to comment #6) > Michael, you're right. But the reason this happens is pretty simple. There > are more DOM consumers than just HTML. So HTML can't unilaterally dictate what > all DOM consumers must do. In particular, taken at face value this bug > requires that all DOM processors implement .innerHTML on any DOM nodes they > support. That's a core DOM change that needs to be figured out in a wider > context, and with more input, than just HTML. there must be scope way to limit the scope here. The feedback we had (especially from browsers) was that MathML didn't need a special DOM as it could be handled as xml using the browser's xml dom. HTML5 for the first time specifies MathML (and SVG) in _HTML_ under the influence of the HTML DOM so where do you think these methods should be defined? Currently HTML specifies that the innerHTML of <span><math>...</math></span> is the html fragment linearisation of <math>...</math> (something defined in html5) but that the innerHTML of the math element is undefined. Clearly in order to implement this the browser has to implement everything needed to implement innerHTML on math, except for exposing the actual method. It is not, as your comment would suggest, imposing some new implementation burden on implementations. HTML5 explicitly does _not_ try to be completely general with respect to any kind of element node tree: it special cases three specific vocabularies html,mathml,svg, but parses then into a single unified tree. -- 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 Wednesday, 3 November 2010 15:10:33 UTC