WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 6 years ago

#5120 closed defect (bug) (wontfix)

_wp_unfiltered_html_comment breaks XHTML validity

Reported by: jrawle Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8
Component: Template Keywords: has-patch
Focuses: Cc:
PR Number:

Description

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.

Attachments (2)

classic-theme-comments-patch.diff (1.2 KB) - added by Elpie 10 years ago.
default-theme-comments.diff (1.1 KB) - added by Elpie 10 years ago.

Download all attachments as: .zip

Change History (25)

#1 @Viper007Bond
12 years ago

  • Component changed from General to Template
  • Milestone 2.5 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

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

#2 @Viper007Bond
12 years ago

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

#3 @rob1n
12 years ago

  • Milestone set to 2.3.1
  • Resolution worksforme deleted
  • Status changed from closed to reopened

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").

#4 @Viper007Bond
12 years ago

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.

#5 @DD32
12 years ago

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.

#6 @DD32
12 years ago

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>").

#7 @Viper007Bond
12 years ago

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. :(

#8 @rob1n
12 years ago

  • Milestone 2.3.1 deleted
  • Resolution set to invalid
  • Status changed from reopened to closed

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 ;).

#9 @Viper007Bond
12 years ago

No worries. :)

#10 @guillep2k
12 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 2.2.3 to 2.5

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).

#11 @guillep2k
12 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

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

#12 @igroknow
10 years ago

  • Cc igroknow added
  • Resolution invalid deleted
  • Status changed from closed to reopened

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

#13 @igroknow
10 years ago

  • Version changed from 2.5 to 2.8

#14 @igroknow
10 years ago

  • Milestone set to 2.8.1

#15 @mrmist
10 years ago

  • Milestone 2.8.1 deleted
  • Resolution set to invalid
  • Status changed from reopened to closed
  • Version changed from 2.8 to 2.5

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.

#16 @Elpie
10 years ago

  • Cc Elpie added
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 2.5 to 2.8

#17 @Elpie
10 years ago

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.

#18 @Elpie
10 years ago

  • Milestone set to 2.8.1

#19 @scribu
10 years ago

  • Keywords has-patch commit added

#20 @azaozz
10 years ago

  • Keywords commit removed
  • Milestone changed from 2.8.1 to 2.9

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.

#21 @nacin
10 years ago

  • Milestone changed from 2.9 to 3.0

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

#22 @nacin
10 years ago

  • Milestone changed from 3.0 to Future Release

#23 @nacin
6 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

The HTML5 spec renders this decidedly invalid.

Note: See TracTickets for help on using tickets.