W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2010

[Bug 11204] innerHTML on MathML elements

From: <bugzilla@jessica.w3.org>
Date: Wed, 03 Nov 2010 16:51:33 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PDgYf-0000xE-U7@jessica.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 November 2010 16:51:42 GMT