This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11204 - Defer to DOM Parsing for innerHTML et al
Summary: Defer to DOM Parsing for innerHTML et al
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All Windows NT
: P3 normal
Target Milestone: ---
Assignee: Sam Ruby
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: WGDecision
Depends on:
Blocks: 12584
  Show dependency treegraph
 
Reported: 2010-11-03 00:06 UTC by David Carlisle
Modified: 2012-09-21 17:47 UTC (History)
19 users (show)

See Also:


Attachments

Description David Carlisle 2010-11-03 00:06:35 UTC
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.
Comment 1 Boris Zbarsky 2010-11-03 02:01:05 UTC
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...
Comment 2 Ms2ger 2010-11-03 07:51:58 UTC
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.
Comment 3 Anne 2010-11-03 08:03:48 UTC
Hey, that is my vague plan!
Comment 4 David Carlisle 2010-11-03 09:19:49 UTC
(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.
Comment 5 Michael Kay 2010-11-03 11:01:54 UTC
Looks like it's following the usual rule that the architecture of the software mirrors the architecture of the organization that created it.
Comment 6 Boris Zbarsky 2010-11-03 14:18:39 UTC
> 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.
Comment 7 David Carlisle 2010-11-03 15:10:30 UTC
(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.
Comment 8 Boris Zbarsky 2010-11-03 15:57:18 UTC
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?
Comment 9 David Carlisle 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.
Comment 10 Henri Sivonen 2010-11-03 17:51:50 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.

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.
Comment 11 Boris Zbarsky 2010-11-03 18:29:44 UTC
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.
Comment 12 David Carlisle 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)
Comment 13 Anne 2010-11-08 14:28:01 UTC
Comment 2 has been executed: http://html5.org/specs/dom-parsing.html
Comment 14 Ian 'Hixie' Hickson 2010-12-29 08:27:48 UTC
Once that spec is more stable I'll drop innerHTML and friends from the HTML spec.
Comment 15 David Carlisle 2010-12-29 11:06:39 UTC
(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.
Comment 16 Ian 'Hixie' Hickson 2011-07-22 14:22:01 UTC
Any news on this? Anne? Ms2ger?
Comment 17 Anne 2011-07-22 14:59:15 UTC
The innerHTML bits are stable. It is just not hosted at an ideal location currently.
Comment 18 Ms2ger 2011-07-22 18:01:49 UTC
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.
Comment 19 Ian 'Hixie' Hickson 2011-07-22 19:00:50 UTC
Ok, sounds good.
Comment 20 Michael[tm] Smith 2011-08-04 05:14:49 UTC
mass-move component to LC1
Comment 21 Ian 'Hixie' Hickson 2011-08-14 06:45:45 UTC
Anne, ping me on IRC about the hosting situation.
Comment 22 Ian 'Hixie' Hickson 2011-09-04 17:29:15 UTC
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.
Comment 23 contributor 2011-09-04 17:30:26 UTC
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
Comment 24 David Carlisle 2011-09-04 17:45:18 UTC
(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.
Comment 25 Tony Ross [MSFT] 2012-01-15 03:00:51 UTC
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.
Comment 26 Sam Ruby 2012-01-15 22:06:48 UTC
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).
Comment 27 Ms2ger 2012-01-16 13:59:03 UTC
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.
Comment 28 David Carlisle 2012-01-16 14:49:54 UTC
(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.
Comment 29 Tony Ross [MSFT] 2012-01-16 19:16:10 UTC
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.
Comment 31 Aryeh Gregor 2012-01-17 16:26:45 UTC
Perhaps this could be moved to a CG, a la the editing spec.
Comment 32 Sam Ruby 2012-01-18 01:38:45 UTC
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.
Comment 33 Michael[tm] Smith 2012-01-21 03:26:10 UTC
(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.
Comment 35 Edward O'Connor 2012-05-11 12:08:12 UTC
Am I reading this right? The decision is to change a working reference link to one that 404s?
Comment 36 Ms2ger 2012-05-11 12:08:44 UTC
Correct.
Comment 37 Ian 'Hixie' Hickson 2012-07-12 19:41:58 UTC
...how does this block bug 12584?
Comment 38 contributor 2012-07-18 07:30:21 UTC
This bug was cloned to create bug 17991 as part of operation convergence.
Comment 39 Ms2ger 2012-08-15 17:13:43 UTC
Filter on [Idon'tcareaboutHTMLWGbugspam].
Comment 40 Travis Leithead [MSFT] 2012-08-28 20:00:04 UTC
Assigning to myself, as I have the task of prepping the DOM Parsing and Serialization spec for the WebApps WG.
Comment 41 Travis Leithead [MSFT] 2012-08-30 00:09:09 UTC
Fixed in change:
https://github.com/w3c/html/commit/6f9ffe8706188d8f011125123e67e0565c7f428e
Comment 42 Ms2ger 2012-08-30 08:02:58 UTC
I formally object to this change: the Change Proposal clearly required linking to "http://www.w3.org/TBD".
Comment 43 Travis Leithead [MSFT] 2012-09-07 23:09:53 UTC
(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 :)
Comment 44 Ms2ger 2012-09-15 19:42:24 UTC
(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.
Comment 45 Travis Leithead [MSFT] 2012-09-20 16:50:57 UTC
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
Comment 46 Ms2ger 2012-09-20 16:54:24 UTC
(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.
Comment 47 David Carlisle 2012-09-20 18:54:26 UTC
(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.
Comment 48 Ms2ger 2012-09-20 19:53:39 UTC
(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.
Comment 49 David Carlisle 2012-09-20 20:48:29 UTC
(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.
Comment 50 Karl Dubost 2012-09-20 20:52:20 UTC
As an attempt for a compromise. Would that help?

http://www.w3.org/wiki/ToBeDecided
Comment 51 Matthew Turvey 2012-09-20 21:44:54 UTC
(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
Comment 52 Sam Ruby 2012-09-21 13:03:51 UTC
editors: do it as two commits.  If MS2Ger wishes to Formally Object to the second commit, we will dutifully forward his concerns to Director.
Comment 53 Sam Ruby 2012-09-21 17:06:22 UTC
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.
Comment 54 Ms2ger 2012-09-21 17:09:06 UTC
(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.
Comment 55 Sam Ruby 2012-09-21 17:24:05 UTC
(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
Comment 56 Sam Ruby 2012-09-21 17:47:50 UTC
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.