- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Nov 2010 18:59:39 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11204 --- Comment #12 from David Carlisle <davidc@nag.co.uk> 2010-11-03 18:59:39 UTC --- (In reply to comment #11) > David, seems to me like the right thing to do here from MathML's point of view > is to just define that MathML elements have a .innerHTML and say that the > algorithm in the HTML5 spec is used for that, no? Henri's proposal may work as > well. Though moving innerHTML from HTMLElement to Element might also break > pages, note.... Copying might be ok. Henri's comment in #10 would seem preferable to me actually. I don't really want to say that every mathml implementation using a DOM has to implement innerHTML (which is I think what you are saying) I just want to say that if a MathML element is being represented by a DOM node whose parent supports innerHTML then it should too. MathML doesn't have any mathml-specific script requirements, so there isn't really any need for MathMLElement to be any different (in a mathml-in-html context) to HTMLElement, Or the html5 spec could just say that HTMLElement should be used for mathml elements anyway. The whole idea surely of having a unified parse specification and unified internal DOM model is to allow for seamless integration of the mathematics with the surrounding text. Why do we need to put up artificial barriers in the DOM access based on historic working group organisation? (perhaps I should mention again that this whole thread is a personal action) -- 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 18:59:41 UTC