This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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...
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.
Hey, that is my vague plan!
(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.
Looks like it's following the usual rule that the architecture of the software mirrors the architecture of the organization that created it.
> 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.
(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.
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?
(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.
(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.
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.
(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)
Comment 2 has been executed: http://html5.org/specs/dom-parsing.html
Once that spec is more stable I'll drop innerHTML and friends from the HTML spec.
(In reply to comment #14) > Once that spec is more stable I'll drop innerHTML and friends from the HTML > spec. 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.
Any news on this? Anne? Ms2ger?
The innerHTML bits are stable. It is just not hosted at an ideal location currently.
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.
Ok, sounds good.
mass-move component to LC1
Anne, ping me on IRC about the hosting situation.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html 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.
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
(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.
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.
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).
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.
(In reply to comment #27) > 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. 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.
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.
https://www.w3.org/html/wg/tracker/issues/198
Perhaps this could be moved to a CG, a la the editing spec.
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.
(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.
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
Am I reading this right? The decision is to change a working reference link to one that 404s?
Correct.
...how does this block bug 12584?
This bug was cloned to create bug 17991 as part of operation convergence.
Filter on [Idon'tcareaboutHTMLWGbugspam].
Assigning to myself, as I have the task of prepping the DOM Parsing and Serialization spec for the WebApps WG.
Fixed in change: https://github.com/w3c/html/commit/6f9ffe8706188d8f011125123e67e0565c7f428e
I formally object to this change: the Change Proposal clearly required linking to "http://www.w3.org/TBD".
(In reply to comment #42) > I formally object to this change: the Change Proposal clearly required linking > to "http://www.w3.org/TBD". Presumably you don't mean the literal URL: "http://www.w3.org/TBD" I suppose we can wait for a FPWD copy to post to www.w3.org/TR/DOMParsing/ (or similar link :)
(In reply to comment #43) > (In reply to comment #42) > > I formally object to this change: the Change Proposal clearly required linking > > to "http://www.w3.org/TBD". > > Presumably you don't mean the literal URL: "http://www.w3.org/TBD" I most definitely do.
Alright, I can't in good conscious leave the ref to a 404: (http://www.w3.org/TBD) Instead, we can link to the new WebApps WG deliverable: http://www.w3.org/TR/DOM-Parsing/ See commit: https://github.com/w3c/html/commit/6c55b5b94ab78e600080ac3957a7441cfc4ecda2
(In reply to comment #45) > Alright, I can't in good conscious leave the ref to a 404: > (http://www.w3.org/TBD) Your conscience is not relevant in this process. The WG has decided on a 404. As an editor in the HTML WG, your job is do apply whatever ridiculous decisions the WG makes. I repeat my Formal Objection to your change.
(In reply to comment #46) > (In reply to comment #45) > > Alright, I can't in good conscious leave the ref to a 404: > > (http://www.w3.org/TBD) > > Your conscience is not relevant in this process. The WG has decided on a 404. > As an editor in the HTML WG, your job is do apply whatever ridiculous decisions > the WG makes. I repeat my Formal Objection to your change. I'm not sure where this TBD reference is? I looked at the change proposal http://www.w3.org/html/wg/wiki/ChangeProposals/Reference_a_W3C_version_of_DOM_Parsing_and_Serialization and it just says Publish DOM Parsing and Serialization as currently defined at http://html5.org/specs/dom-parsing.html in the HTML WG. Then update the current DOM Parsing and Serialization reference in HTML5 to point to the new spec. which appears to be what is being done. Any reference to "TBD" that does exist is clearly intended as a meta-variable to be filled in To-Be-Decided. The document can not be published anyway with a 404 link as that's clearly against pubrules.
(In reply to comment #47) > (In reply to comment #46) > > (In reply to comment #45) > > > Alright, I can't in good conscious leave the ref to a 404: > > > (http://www.w3.org/TBD) > > > > Your conscience is not relevant in this process. The WG has decided on a 404. > > As an editor in the HTML WG, your job is do apply whatever ridiculous decisions > > the WG makes. I repeat my Formal Objection to your change. > > > I'm not sure where this TBD reference is? I looked at the change proposal > > http://www.w3.org/html/wg/wiki/ChangeProposals/Reference_a_W3C_version_of_DOM_Parsing_and_Serialization > > and it just says > > Publish DOM Parsing and Serialization as currently defined at > http://html5.org/specs/dom-parsing.html in the HTML WG. Then update the current > DOM Parsing and Serialization reference in HTML5 to point to the new spec. > > which appears to be what is being done. Any reference to "TBD" that does exist > is clearly intended as a meta-variable to be filled in To-Be-Decided. The > document can not be published anyway with a 404 link as that's clearly against > pubrules. It says <del>[http://html5.org/specs/dom-parsing.html DOM Parsing and Serialization], Ms2ger. html5.org.</del> <ins>[http://www.w3.org/TBD DOM Parsing and Serialization], Ms2ger. W3C.</ins> If this is in disagreement with pubrules, that's unfortunate, but it doesn't allow the editor to override a clear WG decision.
(In reply to comment #48) > If this is in disagreement with pubrules, that's unfortunate, but it doesn't > allow the editor to override a clear WG decision. Sorry I looked at the text didn't see the link directly. What is clear is that "TBD" is a standard English acronym for "To Be Decided" and most (but clearly not all as you are an exception) people reading that will take TBD to be a placeholder for a URL to be filled in once the actual URL is known. So your statement that there was a clear WG decision to use a url ending literally in TBD is I would say false. I was not involved in drafting that text, but that is how I (and I would think most people) understood it. You are of course free to object to anything but I would be staggered if this objection were upheld.
As an attempt for a compromise. Would that help? http://www.w3.org/wiki/ToBeDecided
(In reply to comment #50) > As an attempt for a compromise. Would that help? > > http://www.w3.org/wiki/ToBeDecided See http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#reopening
editors: do it as two commits. If MS2Ger wishes to Formally Object to the second commit, we will dutifully forward his concerns to Director.
Travis, don't spend any more time on this bug. The following literally implements the decision as stated: https://github.com/w3c/html/commit/e60c49b12aa2302945466951aacbdb33d6964001 The following updates that link to point to the current location: https://github.com/w3c/html/commit/30f530989e9d28255a149d5db52ad28b09f44863 If MS2GER wishes to Formally Object to the subsequent change, such objection will be noted and forwarded to the director for consideration before we make transition to CR.
(In reply to comment #53) > Travis, don't spend any more time on this bug. > > The following literally implements the decision as stated: > > https://github.com/w3c/html/commit/e60c49b12aa2302945466951aacbdb33d6964001 > > The following updates that link to point to the current location: > > https://github.com/w3c/html/commit/30f530989e9d28255a149d5db52ad28b09f44863 > > If MS2GER wishes to Formally Object to the subsequent change, such objection > will be noted and forwarded to the director for consideration before we make > transition to CR. Thank you. Please do note my Formal Objection.
(In reply to comment #54) > > Thank you. Please do note my Formal Objection. Recorded: http://dev.w3.org/html5/status/formal-objection-status.html#ISSUE-198
For future reference, using decisions as starting points for amicable collaboration on improvements is not unique to this issue. A recent example: http://lists.w3.org/Archives/Public/public-html/2012Sep/0183.html I'll further note that nobody has identified any reason to indicate that the replacement URI currently in the working draft is inferior to the one identified in the original change proposal that was adopted by amicable resolution.