_wp_unfiltered_html_comment breaks XHTML validity

[jrawle]

When a user is logged in, the comment_form hook causes a hidden input field containing _wp_unfiltered_html_comment to be added to the page. In many themes, including the default theme, the comment_form action is within the <form> elements, but outside of any <p> or <div>. This is not valid in XHTML.

One solution would be to move the do_action to inside the preceding paragraph, which already contains the comment_post_ID hidden field. However, this may cause problems with plugins that assume it is outside of any paragraph or div.

The default theme using the latest SVN validates for me as XHTML 1.0 Transitional.

And yes, I'm talking about the single post view with comments enabled.

I can reproduce this in trunk.

Viper, I have a feeling you used the W3C validator, which does *not* see the same HTML as a logged-in user (read the ticket). Please don't quickly close tickets without checking them with the *same* conditions as specified in the ticket ("When a user is logged in").

No, I did have it test as logged in and it does validate for me. I am seeing _wp_unfiltered_html_comment in the source and the W3C validator doesn't seem to have a problem with it, at least for me.

I'm the same as Viper here, I'm seeing the hidden element outside of <p> tags, within the form, but its validating perfectly for me.

Perhaps you could save/upload a page somewhere? Personally I'm thinking a plugin might be causing some other HTML to be output..

I should add i'm using Operas builtin "validate" option which causes the displayed HTML to be uploaded to the W3C Validator, Not the URL of the page.

Ah...
It validates as XHTML 1.0 Transitional; However, If you validate it as XHTML 1.0 Strict it'll fail with this:

Validation Output: 1 Error 
 Line 119, Column 76: document type does not allow element "input" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag.
…ltered_html_comment" value="642e718613" />

✉ 

The mentioned element is not allowed to appear in the context in which you've placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you've forgotten to close a previous element. 

One possible cause for this message is that you have attempted to put a block-level element (such as "<p>" or "<table>") inside an inline element (such as "<a>", "<span>", or "<font>").

Yeah, I'm using Firefox's Web Developer extension that dumps the HTML to a file and then POSTs it.

Anyway, so then this is a non-issue right? The default theme is Transitional and any theme that wants to be strict can move the hook inside of a container.

Not gonna close again though as I don't wanna get yelled at by rob1n again. :(

Don't worry, Viper, I won't yell at you. Sorry I came off as a bit harsh earlier -- reading wp-hackers does it to me ;).

No worries. :)

It is true that the W3C validator doesn't mark it as an error, but the validator (even W3C's!) is not perfect. The HTML specification clearly states that all IDs must start with a letter at section 6.2 (​http://www.w3.org/TR/html401/types.html#type-id). For XHTML you have to dig a little deeper: at section 4.10 (​http://www.w3.org/TR/xhtml1/#h-4.10) it says "in XHTML 1.0 the id attribute is defined to be of type ID"; then in XML specification you must follow the ID type (​http://www.w3.org/TR/2000/REC-xml-20001006#id) to "Names and Tokens" (​http://www.w3.org/TR/2000/REC-xml-20001006#NT-Name), where it says "[5] Name ::= (Letter | '_' | ':') (NameChar)*", ruling out IDs starting with underscores. Like user jrawle, I also think that the _wp_unfiltered_html_comment id breaks XHTML validity. In any case, changing it "to be 100% sure" wouldn't hurt. ;) The affected files are only two: wp-comments-post.php:38 and comment-template.php:610 (as of version 2.5).

Sorry: this is in fact a new bug. I am reclosing this and opening a new one.

Why it is closed? It's easy to resolve that problem and it is a problem.

It was closed for the reason guillep2k said -

Sorry: this is in fact a new bug. I am reclosing this and opening a new one.

I'm sorry, but I fail to see why this was closed again. This bug still exists, its not a new bug, and its easy enough to fix.

There are two issues here - theme developers not placing the do_action inside a block level element. This should be documented in the Codex for reference and the default themes updated.

The second issue is that the core uses XML ID syntax in three files (apart from the themes): comment-template.php, admin-ajax.php and wp-comments-post.php.

_wp_unfiltered_html_comment needs to be changed to an ID that starts with a letter. Would renaming this to wp_unfiltered_html_comment cause any issues?

Fixing both these will allow frontend themes to render as valid XHTML.

I will add the diffs for the default themes shortly. Once I have tested the ID changes I will add patches for those too.

Think that's a bad idea as do_action('comment_form', $post->ID) is used for many different purposes like outputting extra fields, captcha, etc. Forcing this inside a <p> or even a <div> would break current plugins and/or themes. Could possibly wrap the string in a <div> before it's echoed but still would need testing to make sure it doesn't affect anything else.

No traction, patch or testing since last punt. Moving to 3.0. Potentially related, depending on how it is tackled: #11286.