This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
in URL: http://www.w3.org/html/wg/drafts/html/master/syntax.html#elements-0 defining the contents of normal elements is says: "Normal elements can have text, character references, other elements, and comments, but the text must not contain the character "<" (U+003C) or an ambiguous ampersand. Some normal elements also have yet more restrictions on what content they are allowed to hold, beyond the restrictions imposed by the content model and those described in this paragraph. Those restrictions are described below." This makes reference that "comments" are permitted within elements. However, it says that the text must not contain the character "<". in URL: http://www.w3.org/html/wg/drafts/html/master/syntax.html#syntax-comments it states: Comments must start with the four character sequence U+003C LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS (<!--). Following this sequence, the comment may have text, with the additional restriction that the text must not start with a single ">" (U+003E) character, nor start with a U+002D HYPHEN-MINUS character (-) followed by a ">" (U+003E) character, nor contain two consecutive U+002D HYPHEN-MINUS characters (--), nor end with a U+002D HYPHEN-MINUS character (-). Finally, the comment must be ended by the three character sequence U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN (-->). This statement indicates that comments must start with "<!--" which means that elements cannot have comments! since the "<" is not permitted. I know the QND solution will be to modify the documentation to eliminate comments from the allowed content, but I don't think the original language designers had that intention. The real problem is: To get around the lack of comments within an element, programmers misspell attribute names to hide the attribute values during debugging. This leads to a potential error situation. If I create a custom element that has attribute ref= and I modify it to xref= for debug purposes, but forget to remove it, since it works correctly without the ref= attribute, but then someone changes the custom elements definition to include a new attribute xref=. Now I have introduced a change in a production software without having to change the actual code. This is not good!! The problem with the "misspelling attribute name" solution is that it uses one thing (and attribute name) for two purposes. The allowing of undefined attributes was meant for compatibility in changing definitions. It is now being used as a way to implement a comment within an element.
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: none Rationale: If a < character is found, followed by !--, then it no longer is text but is a comment. Ergo, the < character isn't in the text. This applies equally to elements.