This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Another section has been removed from the HTML5 specification, and placed into a document located outside of the W3C. I detailed the circumstances in this email to the HTML Comments email list http://lists.w3.org/Archives/Public/public-html-comments/2011Sep/0003.html Specifically, revert the following change http://html5.org/tools/web-apps-tracker?from=6531&to=6532
in the referenced email you state I don't believe there was even a bug report filed on this one, it was just removed[3][4]. In fact I believe that this action was at least partly as a result of (and certainly part of the successful resolution of) bug 11204
(In reply to comment #1) > in the referenced email you state > > I don't believe there was even a bug report filed on this one, it was just > removed[3][4]. > > > In fact I believe that this action was at least partly as a result of (and > certainly part of the successful resolution of) bug 11204 Thank you for identifying this bug. Since that bug wasn't specific to removing innerHTML et al from the HTML5 specification to a document hosted elsewhere, I don't believe this move was a result of a bug request. But at least we have something resembling a historical context for the move.
(In reply to comment #2) > (In reply to comment #1) > > in the referenced email you state > > > > I don't believe there was even a bug report filed on this one, it was just > > removed[3][4]. > > > > > > In fact I believe that this action was at least partly as a result of (and > > certainly part of the successful resolution of) bug 11204 > > Thank you for identifying this bug. > > Since that bug wasn't specific to removing innerHTML et al from the HTML5 > specification to a document hosted elsewhere, I don't believe this move was a > result of a bug request. But at least we have something resembling a historical > context for the move. Boris had extremely good points in that bug. This bug is focused on the move, but I do believe once the move is reverted, we also need to address the fact that the HTML WG is making changes to elements controlled by other working groups.
(In reply to comment #4) > This bug is focused on the move, but I do believe once the move is reverted, the section was removed as a result of a bug raised in the w3c html wg's bugzilla component by another w3c working group. I don't think that the move should be reverted on process grounds. If there is a technical issue with the specification of the methods moving from htmldocument then you are of course free to re-open bug 11204. > we also need to address the fact that the HTML WG is making changes to elements > controlled by other working groups. That may or may not be an issue in general but it certainly isn't an issue here. The issue was raised by me acting on behalf of the Math WG explicitly so that as far as possible all the elements in an HTML+SVG+MathML document have the same facilities with respect to DOM manipulation. The resolution was that the relevant methods should not be specified as HTML-specific. I don't read anything in to the fact that the editors draft (which is just a first draft) is currently hosted at any particular location. There is plenty of time to host a W3C version if that is thought desirable.
(In reply to comment #5) > (In reply to comment #4) > > > This bug is focused on the move, but I do believe once the move is reverted, > > the section was removed as a result of a bug raised in the w3c html wg's > bugzilla component by another w3c working group. I don't think that the move > should be reverted on process grounds. If there is a technical issue with the > specification of the methods moving from htmldocument then you are of course > free to re-open bug 11204. > > > we also need to address the fact that the HTML WG is making changes to elements > > controlled by other working groups. > > > That may or may not be an issue in general but it certainly isn't an issue > here. > The issue was raised by me acting on behalf of the Math WG explicitly so that > as far as possible all the elements in an HTML+SVG+MathML document have the > same facilities with respect to DOM manipulation. The resolution was that the > relevant methods should not be specified as HTML-specific. > > I don't read anything in to the fact that the editors draft (which is just a > first draft) is currently hosted at any particular location. There is plenty of > time to host a W3C version if that is thought desirable. David I don't believe that MathML is the only group using Element. And until such time as the document is hosted within the W3C, it should remain in the HTML5 specification. Or at least that's the reason why I submitted this bug.
> David > > I don't believe that MathML is the only group using Element. Only SVG and MathML occur in conforming HTML5 documents unless extended by applicable specifications. > > And until such time as the document is hosted within the W3C, it should remain > in the HTML5 specification. _where_ it is specified is important, but a minor issue compared to _what_ is specified. The technical issue with bug 11204 is that innerhtml (and similar methods) was not defined on a math element (which is a regression: if you used math with html4 it would be an unknown HTMElement and thus (as implemented commonly) acquire innerHTML). The resolution that was suggested by the editor (in this bugzilla, last December, so you were incorrect to suggest that the HTML WG had no notice of the change) was to not specify these methods in the html spec, so they would be available in a DOM spec to be defined for all applicable elements. If you are not happy with the resolution of that you should re-open bug 11204 and suggest a different resolution. > > Or at least that's the reason why I submitted this bug. You are of course free to raise whatever bugs you wish, although personally I believe this one ought be marked invalid as the suggestion that this change was not flagged in the appropriate W3C forum is invalid, although of course you are correct to point out that the editors draft isn't hosted at w3c. The public version of the editor's draft of MathML wasn't hosted at W3C either, Editor's drafts have no formal standing, they should be located wherever the editor finds convenient. If the draft is taken up there would I assume be a draft hosted by a suitable body, preferably w3c at some point.
David, where the document is hosted is extremely important. It is no longer a W3C document. Which means it is no longer covered by the W3C patent policy. It doesn't matter that there's some planned maybe possibly future date where it might make its way back to the W3C. Until it is in the W3C in some official capacity, then the text needs to be maintained in the HTML5 document. And all the people of the HTML WG group know of is the first bug report, which was not related to separating this section out into a document and hosting it within the WHATWG server. This was an additional activity beyond the original scope of the bug. Again, moving text out of a LC document within the W3C into a document that's not a W3C document is not something I would hope the W3C takes lightly. We'll have to disagree.
(In reply to comment #8) > David, where the document is hosted is extremely important. As I said, yes, but not as important as it being right. > > It is no longer a W3C document. Which means it is no longer covered by the W3C > patent policy. So you are free to ignore it until such time that it is so hosted if you wish. This would no no worse than html4 (and contemporary DOM specs) which did not define these methods and better than the initial html5 drafts which specified them in a way that was unhelpful for many uses. > > It doesn't matter that there's some planned maybe possibly future date where it > might make its way back to the W3C. Until it is in the W3C in some official > capacity, then the text needs to be maintained in the HTML5 document. See above. > > And all the people of the HTML WG group know of is the first bug report, which > was not related to separating this section out into a document and hosting it > within the WHATWG server. This was an additional activity beyond the original > scope of the bug. Not at all, the original bug report was that the section was wrong, the editor suggested removing it rather than fixing it, and that resolution was acceptable to the person who raised the bug. This is entirely in scope and proper. You are of course free to disagree with the outcome. The fact that the main list only sees initial bug reports and interested WG members have to opt in to following the details of specific bugs was a conscious decision of the WG. > > Again, moving text out of a LC document within the W3C into a document that's > not a W3C document is not something I would hope the W3C takes lightly. From a W3C process point of view the text is just removed. > > We'll have to disagree. OK:-)
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: Rejected Change Description: no spec change Rationale: no rationale provided