- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Nov 2010 16:51:33 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11204 --- Comment #9 from David Carlisle <davidc@nag.co.uk> 2010-11-03 16:51:33 UTC --- (In reply to comment #8) > There's no new burden on _browser_ implementations. But if you require that > all Elements support innerHTML, that requires all DOM implementations, > including ones that have nothing to do with HTML, to support it. that as you say is a wider question and probably out of scope for this bug. > > Maybe that's desirable, but that needs to be discussed in a wider setting than > just the HTML working group. > > If you're saying that we should just add .innerHTML to SVGElement and > MathMLElement, That effectively is what I'm saying yes. > that would be up to those working groups, no? I didn't really address the issue of which WG controlled which bit, but especially in MathML's case the details of the internal model basically defer to the host environment and in this case that is the HTML DOM. the HTML5 spec is the spec that defines the "html fragment serialisation algorithm" so it seems (to me) the natural spec to say "innerHTML on a math element is the result of applying that serialization. If we, the Math WG, were to go off and spec some completely different serialization of mathml elements, then you may (if that were actually implemented) get strange effects where the innerhtml of a node wasn't a substring of the innerhtml of a parent. this needs to be consistently specified (ideally by it just being specified in one place) HTML5 spec currently defines 10.3 Serializing HTML fragments as "The algorithm takes as input a DOM Element, Document, or DocumentFragment" Note this is element not HTMLElement. all I'm saying (whichever spec is best for saying that) is that if a DOM implements this algorithm and furthermore exposes that algorithm as .innerHTML on the majority of its element nodes, it's inconvenient if it doesn't expose the algorithm on the remaining element nodes. I would not wish to say anything (here) about any other DOM implementation which isn't already in the scope of HTML5's section 10.3. But this is essentially a "user request" rather than a request from a "mathml spec editor" and I'd rather leave it to people more close to DOM specifications to say best how to arrange the specifications such that the end result is that if mathml is a descendent of an html element then innerhtml should work. -- 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 16:51:42 UTC