This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 11204 as part of operation convergence. Originally filed: 2010-11-03 00:06:00 +0000 Original reporter: David Carlisle <davidc@nag.co.uk> ================================================================================ #0 David Carlisle 2010-11-03 00:06:35 +0000 -------------------------------------------------------------------------------- http://dev.w3.org/html5/spec/Overview.html#innerhtml describes innerHTML (and outerHTML and related methods) in terms of Element, as do the underlying XML/HTML fragment parsing/serialization algorithms. As such it might be expected (and would certainly be desirable) if these methods applied to MathML and SVG elements. Certainly mathml and svg elements need to take part in the fragment parsing/serialization algorithms so that the innerHTML of an html element containing foreign content may be manipulated. However innerHTML is apparently specified here http://dev.w3.org/html5/spec/Overview.html#htmlelement and (I think) MathML and SVG elements are not HTMLelement. If innerHTML isn't defined then it can be approximated by taking the innerHTML of a (possibly specially generated) parent html element and manipulating it accordingly but this appears to be a needless restriction. The specification should make it clear that these methods are intended to apply to MathML and SVG. ================================================================================ #1 Boris Zbarsky 2010-11-03 02:01:05 +0000 -------------------------------------------------------------------------------- It's really not the HTML spec's place to add new methods on Element (much less directly on SVGElement), as far as I can tell... ================================================================================ #2 Ms2ger 2010-11-03 07:51:58 +0000 -------------------------------------------------------------------------------- Note that there are vague plans to move innerHTML/outerHTML into a "DOM Parsing and Serialization" spec that also defines DOMParser, XMLSerializer, and Range.createContextualFragment. Once that happens, innerHTML/outerHTML will probably end up on Element. ================================================================================ #3 Anne 2010-11-03 08:03:48 +0000 -------------------------------------------------------------------------------- Hey, that is my vague plan! ================================================================================ #4 David Carlisle 2010-11-03 09:19:49 +0000 -------------------------------------------------------------------------------- (In reply to comment #1) > It's really not the HTML spec's place to add new methods on Element (much less > directly on SVGElement), as far as I can tell... pre html5 if you used <math> in html (and for example styled it with css) then innerHTML and friends would work, but HTML5, as a side effect of specifying <math> explicitly is in "foreign content" has apparently stopped this working. Why should the user care in which room at tpac each element was originally defined, getElementById for example returns any element whether it's html or mathml or svg, but then if you use innerHTML on the returned node it either works or returns undefined, depending. ================================================================================ #5 Michael Kay 2010-11-03 11:01:54 +0000 -------------------------------------------------------------------------------- Looks like it's following the usual rule that the architecture of the software mirrors the architecture of the organization that created it. ================================================================================ #6 Boris Zbarsky 2010-11-03 14:18:39 +0000 -------------------------------------------------------------------------------- > getElementById for example returns any element Any element with that ID. HTML, MathML, SVG all define an "id" attribute of type ID. Elements in other namespaces do not, and would not be returned by getElementById just because they have an attribute named "id". 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. ================================================================================ #7 David Carlisle 2010-11-03 15:10:30 +0000 -------------------------------------------------------------------------------- (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. ================================================================================ #8 Boris Zbarsky 2010-11-03 15:57:18 +0000 -------------------------------------------------------------------------------- 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. 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 would be up to those working groups, no? ================================================================================ #9 David Carlisle 2010-11-03 16:51:33 +0000 -------------------------------------------------------------------------------- (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. ================================================================================ #10 Henri Sivonen 2010-11-03 17:51:50 +0000 -------------------------------------------------------------------------------- (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. We could add .innerHTML on Element in Web DOM Core, so non-browser DOM implementations (i.e. Java server-side stuff) wouldn't need to care. ================================================================================ #11 Boris Zbarsky 2010-11-03 18:29:44 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #12 David Carlisle 2010-11-03 18:59:39 +0000 -------------------------------------------------------------------------------- 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) ================================================================================ #13 Anne 2010-11-08 14:28:01 +0000 -------------------------------------------------------------------------------- Comment 2 has been executed: http://html5.org/specs/dom-parsing.html ================================================================================ #14 Ian 'Hixie' Hickson 2010-12-29 08:27:48 +0000 -------------------------------------------------------------------------------- Once that spec is more stable I'll drop innerHTML and friends from the HTML spec. ================================================================================ #15 David Carlisle 2010-12-29 11:06:39 +0000 -------------------------------------------------------------------------------- oh that sounds like a good resolution to this bug thanks. meanwhile, to any browser implementers reading this _please_ implement innerhtml and friends on mathml elements. However that now seems to be an implementation issue not a spec one, so happy for ian to close this once he enacts the action noted above. ================================================================================ #16 Ian 'Hixie' Hickson 2011-07-22 14:22:01 +0000 -------------------------------------------------------------------------------- Any news on this? Anne? Ms2ger? ================================================================================ #17 Anne 2011-07-22 14:59:15 +0000 -------------------------------------------------------------------------------- The innerHTML bits are stable. It is just not hosted at an ideal location currently. ================================================================================ #18 Ms2ger 2011-07-22 18:01:49 +0000 -------------------------------------------------------------------------------- I don't think there's anything in particular I need to do about the parts I copied from HTML. The spec is pretty low priority for me, so the rest won't move forward particularly fast. ================================================================================ #19 Ian 'Hixie' Hickson 2011-07-22 19:00:50 +0000 -------------------------------------------------------------------------------- Ok, sounds good. ================================================================================ #21 Ian 'Hixie' Hickson 2011-08-14 06:45:45 +0000 -------------------------------------------------------------------------------- Anne, ping me on IRC about the hosting situation. ================================================================================ #22 Ian 'Hixie' Hickson 2011-09-04 17:29:15 +0000 -------------------------------------------------------------------------------- Status: Partially Accepted Change Description: see diff given below Rationale: I've moved innerHTML, outerHTML, and insertAdjacentHTML out of HTML altogether, so this is now out of scope. ================================================================================ #23 contributor@whatwg.org 2011-09-04 17:30:26 +0000 -------------------------------------------------------------------------------- Checked in as WHATWG revision r6532. Check-in comment: Remove bits now specced in DOMPARSING spec. http://html5.org/tools/web-apps-tracker?from=6531&to=6532 ================================================================================ #24 David Carlisle 2011-09-04 17:45:18 +0000 -------------------------------------------------------------------------------- (In reply to comment #22) > Status: Partially Accepted > Change Description: see diff given below > Rationale: I've moved innerHTML, outerHTML, and insertAdjacentHTML out of HTML > altogether, so this is now out of scope. This is as discussed in earlier comments; closing, thanks. ================================================================================ #25 Tony Ross [MSFT] 2012-01-15 03:00:51 +0000 -------------------------------------------------------------------------------- I'd like the change enacted as a result of this bug reconsidered. I'm not opposed to defining innerHTML and friends in another spec, but I'm concerned because the actual edit moved the definition of these APIs outside of the W3C entirely. Such a change is notable because it removes patent policy obligations from working group members in relation to these APIs. This protection is important to Microsoft as it helps ensure specifications can be implemented on a royalty-free basis. I'm aware that DOM Parsing and Serialization has since been approved for addition to the Web Apps WG charter and this may ultimately resolve my concerns. However that spec has not yet been published within the W3C. At the moment HTML5 continues to normatively reference an external specification for these APIs that does not have a patent policy in place. ================================================================================ #26 Sam Ruby 2012-01-15 22:06:48 +0000 -------------------------------------------------------------------------------- From the original resolution: if you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug (done), and suggest title and text for the tracker issue (still needed). ================================================================================ #27 Ms2ger 2012-01-16 13:59:03 +0000 -------------------------------------------------------------------------------- FWIW, since making this change to the W3C specification would mostly affect Microsoft, I support their request. I hope we can handle this without escalating to the WG. ================================================================================ #28 David Carlisle 2012-01-16 14:49:54 +0000 -------------------------------------------------------------------------------- Since I opened this bug, I'll note that I certainly wouldn't want the resolution of this to cause legal problems for implementations. I'd have no objection to the text being pulled back into the html spec until such time that there is somewhere else for it to go that is covered by the relevant patent protection. (I don't know how long it would take to get a version of the DOM parsing spec under the patent protection policy) If it is pulled back into html it would be good if there is at least a non normative note saying that the specification of innerHTML is defined on HTMLelement but that it is planned to move it to Element, and implementations should make it available on MathML and SVG elements as well as HTML. ================================================================================ #29 Tony Ross [MSFT] 2012-01-16 19:16:10 +0000 -------------------------------------------------------------------------------- Apologies for not correctly following the process here. I think this is worth discussing with the working group, not because of challenges solving this particular issue, but so we can agree on how changes like this should be handled in the future. For the tracker issue I propose the following... Title: Ensure innerHTML and related APIs are subject to the W3C patent policy Text: Given innerHTML, outerHTML, etc. were previously defined in HTML5 before being relocated to an external specification, we should ensure the W3C patent policy continues to apply to the definition of these APIs. We should also consider how we want to handle similar changes in the future. For these particular APIs I propose resolving the issue by finishing the process to get the DOM Parsing and Serialization spec up and running within the W3C. I appreciate the work Ms2ger has put in to create this specification and I'd prefer not to regress that effort. ================================================================================ #30 Sam Ruby 2012-01-16 23:03:39 +0000 -------------------------------------------------------------------------------- https://www.w3.org/html/wg/tracker/issues/198 ================================================================================ #31 Aryeh Gregor 2012-01-17 16:26:45 +0000 -------------------------------------------------------------------------------- Perhaps this could be moved to a CG, a la the editing spec. ================================================================================ #32 Sam Ruby 2012-01-18 01:38:45 +0000 -------------------------------------------------------------------------------- Returning to RESOLVED/FIXED. Prior to the January 14th deadline for escalations, we had asked that ONE of REOPENED or TrackerRequest be applied to any given bug. Since this was escalated prior to the deadline, we have processed the TrackerRequest. Note: this is in no way intended to preclude resolving this by Amicable Consent. ================================================================================ #33 Michael[tm] Smith 2012-01-21 03:26:10 +0000 -------------------------------------------------------------------------------- (In reply to comment #31) > Perhaps this could be moved to a CG, a la the editing spec. Yeah, that would certainly make a lot of sense, for the short term at least -- since as Ms2ger has pointed out, the plan of record is to eventually make this a WebApps WG deliverable. But getting it to actually be an official WebApps deliverable is another case of built-in W3C process delays getting in our way. It is going to be months, literally, before we have the WebApps WG rechartered with this as one of its deliverables. So in the near term, it would make a lot of sense to put together a CG for working on this and maybe for working on some related things (e.g., the current URL spec). I am happy to work with others on helping put that together -- not speaking as W3C team member, since CGs don't need any team involvement, but just speaking as somebody who would like to have get this resolved so that we can better focus on the actual technical word we need to get done together. ================================================================================ #34 Sam Ruby 2012-05-11 11:57:01 +0000 -------------------------------------------------------------------------------- Change Proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/Reference_a_W3C_version_of_DOM_Parsing_and_Serialization Decision: http://lists.w3.org/Archives/Public/public-html/2012May/0074.html ================================================================================ #35 Edward O'Connor 2012-05-11 12:08:12 +0000 -------------------------------------------------------------------------------- Am I reading this right? The decision is to change a working reference link to one that 404s? ================================================================================ #36 Ms2ger 2012-05-11 12:08:44 +0000 -------------------------------------------------------------------------------- Correct. ================================================================================ #37 Ian 'Hixie' Hickson 2012-07-12 19:41:58 +0000 -------------------------------------------------------------------------------- ...how does this block bug 12584? ================================================================================
This bug was fixed long ago.