Allowing HTML in post titles

Whoops, uploaded the patch file as html-in-post-titles.patch instead of with the .diff extension. Not sure if this makes any difference, though. Anyway, I uploaded the .diff file as well. Enjoy

The final patch.

Please ignore all files but html-in-post-titles.2.diff.

Passed to devs for feedback.

I say include it. Those that don't want HTML in their titles can simply not use any.

My point exactly.

$strip should default to true, not false, for backward compatibility with themes that don't understand this field. Otherwise you're going to get odd breakage in quite a few themes.

As a non-developer and a large user of wordpress, I have to say this idea is rediculous. I can understand that this probably is an easy fix, but if you want to style post titles, that's what you use CSS for.

Adding support for post titles will just add more cruft to users' web pages. It's suppose to be about seperation of style from content, not allowing them to style their content directly from the editor, which is the complete opposite of everything Wordpress stands for(in my opinion, of course).

Just my .02

I'm for marking this as wontfix. Post titles aren't meant to have HTML...

I agree with rob1n. No HTML in titles.

Closing as wontfix, because: - The general reponse on the ticket was negative. - The given patch would result in attributes containg html tags, which is invalid xhtml.

Post titles aren't meant to have HTML? Why not? You are allowed to use HTML in each post's body but not its title? That's rather arbitrarily restrictive, don't you think?

The case for allowing HTML in posts' titles is a strong one. Primarily, allowing a post's title to contain HTML would be very useful and make WordPress more flexible. Why anyone would be against this is beyond me.

Most uses of the_title() when it comes to markup involve wrapping it in a heading element (h1,h2,h3,h4,h5,h6). According to my reading of the XHTML 1.0 & 1.1 Specifications there are many valid child elements that are allowed inside heading elements, so the potential is definitely there.

For instance, say you'd like to put emphasis on a particular word in the title, what's wrong with using the "em" element? What about if you're talking about say, the C standard library, and your post's title contains "#include <stdio.h>" and you'd like to wrap this in a "code" element? What if you wish to wrap a particular part of your title's text with a "span" so you can style it separately with CSS? There are many, many other perfectly legitimate uses.

CSS alone cannot give enough control over the styling of a header in many cases, the examples I've given show as much, and the fact the the XHTML specs allow for child elements inside heading elements shows that they realise this, too.

Of course there are also instances where you then don't want the HTML to show up, which is why this patch is necessary. For instance, Kubrick's handling of the title of the hyperlink to each post's title i.e. (line 10 of index.php)

<h2><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title(); ?>"><?php the_title(); ?></a></h2>

The "a" element's title parameter will potentially invalidate the entire page's code if a post's title currently contains markup. This is bad.

Therefore, a cautious "no-HTML by default" approach to the_title() would be good and is exactly what this patch would provide, allowing older themes to continue to function while providing the means for newer themes to take advantage of the extra functionality.

As such, I'm in STRONGLY in favour of this patch to the_title(), it'd definitely help people do perfectly valid things with post titles that they currently can't.

Replying to ManxStef:

Post titles aren't meant to have HTML? Why not? You are allowed to use HTML in each post's body but not its title? That's rather arbitrarily restrictive, don't you think?

No, it goes with the whole separation of content and style thing. HTML in the post body is a) restricted to certain privileged users and b) heavily filtered. It's one thing to allow body text to have tags like em and strong and such, but it's another to allow them in post titles and then have to deal with all the hassle of filtering them and dealing with the weird permalink issues that it would probably cause.

The case for allowing HTML in posts' titles is a strong one. Primarily, allowing a post's title to contain HTML would be very useful and make WordPress more flexible. Why anyone would be against this is beyond me.

Because it makes no sense. If you want to style the post titles, then use the CSS file. That's what it's for. Unless you want to style each post title separately or in different colors or something, which seems like a bit of an edge case.

Most uses of the_title() when it comes to markup involve wrapping it in a heading element (h1,h2,h3,h4,h5,h6). According to my reading of the XHTML 1.0 & 1.1 Specifications there are many valid child elements that are allowed inside heading elements, so the potential is definitely there.

Then those elements should be in the template, not in the data. The data layer should be *just* the data, not the style as well. Presentation vs. content. HTML tags are only content in certain, very-limited, cases.

If we heavily filter the title (perhaps with kses) and don't allow arbitrary code for *any* user, and then always make the_title() and get_the_title() filter *ALL* HTML code out by default with only an option to display it if the theme allows it, then *maybe* your notion would work.

But I'm still +1 for not ever allowing HTML unless you can show me a legitimate example of why it would be useful that is not completely arbitrary in nature. Just putting some title words in italics or using separate styling for each title doesn't strike me as reason enough to add all the extra filtering overhead and violating the content/presentation layer concept.

Replying to Otto42:

Replying to ManxStef:

Post titles aren't meant to have HTML? Why not? You are allowed to use HTML in each post's body but not its title? That's rather arbitrarily restrictive, don't you think?

No, it goes with the whole separation of content and style thing. HTML in the post body is a) restricted to certain privileged users and b) heavily filtered. It's one thing to allow body text to have tags like em and strong and such, but it's another to allow them in post titles and then have to deal with all the hassle of filtering them and dealing with the weird permalink issues that it would probably cause.

I think including XML or HTML sounds good in theory, but I don't think it is a problem currently worth solving.

Replying to Nazgul:

Closing as wontfix, because: - The general reponse on the ticket was negative. - The given patch would result in attributes containg html tags, which is invalid xhtml.

Reclosing as wontfix based on the last couple of replies.

I think there are certain html values with should be allowed in title's, the first two that come to mind being <abbr> and <acronym>...

Replying to davidhouse:

I say include it. Those that don't want HTML in their titles can simply not use any.

I don't want HTML in the titles of my blog. But having several authors your "if you don't want it don't use it" policy probably would not be enough.

But besides that I don't see the point in having HTML in titles.

I'm voting -1 just for the occasion that this would break the RSS. And also the what if someone puts a </div> or something that will break the page.

Replying to thee17:

I'm voting -1 just for the occasion that this would break the RSS. And also the what if someone puts a </div> or something that will break the page.

This reason is not really valid, because any time that user HTML input is accepted, it would be run through the balance_tags() function which would make sure that your scenario would never happen.

It's still going to break the RSS, and several themes. Again, nobody has really explained why they want HTML in post titles. All cases for it are very edge cases, the title is text only for a very good reason. That reason being that it's used in places where HTML is unacceptable.

It's a title, not HTML output. It's not guaranteed to be output as a webpage.

Closing as wontfix for the third time. Unless somebody can make a really compelling case, I suggest that this remain closed.