This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Earlier in the year, modifications were made to a section of the document that currently had an issue attached. To the best of my knowledge, the modification was not discussed in the HTML WG group, and the editor made the modification by filing his own bug[1] and then making his own edit[2]. The section under question is Section 2.2.2 titled Extensibility[3]. The issue impacting on that section, and on the entire concept, is Issue 41[4], currently undergoing an issue survey[5]. The original text included instructions to ensure no collisions between uses of an attribute or element. The new modification does not guarantee that some collisions won't take place. Further, the new modification has no conformance requirements, so that vendors can choose to either use a vendor specific prefix, or not[6]. A specification should be a model of precision--not a muddled mix of precise instructions detailing conformance combined with hopeful wishes that vendors will be good, and not muck everything up[6]. One of the other of the following will satisfy this bug: If the so-called "Zero edit" change proposal[7] _fails_ in the survey, and the section is replaced with new text from one of the other change proposals. -or- If the changes made in the original modification are completely reversed, returning the section to the original text. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9239 [2] http://html5.org/tools/web-apps-tracker?from=4938&to=4939 [3] http://dev.w3.org/html5/spec/infrastructure.html#extensibility [4] http://www.w3.org/html/wg/tracker/issues/41 [5] http://www.w3.org/2002/09/wbs/40318/issue-41-objection-poll/results [6] http://blogs.msdn.com/b/ie/archive/2010/09/13/interoperable-html-parsing-in-ie9.aspx [7] http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-41
A clarification based on confusion noted about this bug in the WhatWG IRC: I provided the link to Microsoft's "generic element" in the original bug filing as an example of poorly done extensibility.
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: Did Not Understand Request Change Description: no spec change Rationale: I have absolutely no idea what is being requested here.
(In reply to comment #2) > 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: Did Not Understand Request > Change Description: no spec change > Rationale: I have absolutely no idea what is being requested here. Your question is not specific enough in order to provide useful information. Regardless, the request is specific as to what changes can be made to satisfy this bug. To simplify the request, though, since you have control only over one aspect of this solution, return the section identified in the original bug request (2.2.2) to the original text, prior to your modifications made per bug also identified in original bug request. I believe you only need back out the changes in the source control, shouldn't require any edits at all.
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: Did Not Understand Request Change Description: no spec change Rationale: I don't understand. Why would we do this? What problem is there here?
(In reply to comment #4) > 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: Did Not Understand Request > Change Description: no spec change > Rationale: I don't understand. Why would we do this? What problem is there > here? Perhaps the co-chairs will have a better time explaining it to you, I can't seem to write in terms you understand. Am escalating.
As best I can discern, this seems to be covered by ISSUE-41: http://www.w3.org/html/wg/tracker/issues/41
(In reply to comment #6) > As best I can discern, this seems to be covered by ISSUE-41: > > http://www.w3.org/html/wg/tracker/issues/41 Well, not really. If the accepted change proposal for Issue 41 is the zero-change, then this bug asks that the section be returned to what it once was. If another change proposal is accepted, then this section is changed, anyway. Now, the editor can revert the changes now, and that would satisfy the bug regardless of what happens with Issue 41.
(In reply to comment #7) > (In reply to comment #6) > > As best I can discern, this seems to be covered by ISSUE-41: > > > > http://www.w3.org/html/wg/tracker/issues/41 > > Well, not really. > > If the accepted change proposal for Issue 41 is the zero-change, then this bug > asks that the section be returned to what it once was. > > If another change proposal is accepted, then this section is changed, anyway. > > Now, the editor can revert the changes now, and that would satisfy the bug > regardless of what happens with Issue 41. What happened is the situation was complicated when the editor made changes to the extensibility section without proposing the changes as an Issue 41 change proposal, and without waiting for Issue 41 to be resolved.
http://lists.w3.org/Archives/Public/public-html/2011Feb/0085.html
Google just released the code for their "+1" button (http://www.Google.com/webmasters/%2b1/button/) and after testing it (http://www.ExampleOnly.com/plusone/test.html), the W3C Markup Validation Service now reports errors where without the "+1 Button" code it was only reporting a warning. http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ExampleOnly.com%2Fplusone%2Ftest.html&ss=1 The code uses a Google-specific namespace and "g:" prefix: <g:plusone size="tall"></g:plusone> The "workaround", to use "document.write" does not work consistently across browsers (http://www.ExampleOnly.com/plusone/test2.html). And IMO, since it puts an "invalid" element in the DOM, should not be considered truly valid, even though it fools the validation service. I haven't been able to figure out how you notify Google about fixing that, however. Thanks.