WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 7 years ago

Last modified 4 years ago

#1371 closed enhancement (wontfix)

Allowing HTML in post titles

Reported by: MaThIbUs Owned by: MathiasBynens
Milestone: Priority: lowest
Severity: minor Version: 2.9.2
Component: Template Keywords: dev-feedback 2nd-opinion
Focuses: Cc:

Description

http://comox.textdrive.com/pipermail/hackers/2004-August/001119.html

http://mathibus.com/archives/2005/05/15/html-in-post-titles/#comment-3

WordPress doesn't allow you to embed HTML in your posts's titles. In fact, this is not a WordPress problem, it's more a lack of usability in Kubrick, the default WP theme. So, unless you're following Anne van Kesteren's "A header should not be a link, stupid!" logic, there is no way to embed code in your posts's titles without breaking the title attributes of a certain amount of links, thus making your pages invalid.

Attachments (3)

html-in-post-titles.diff (2.9 KB) - added by MaThIbUs 9 years ago.
html-in-post-titles.patch (2.9 KB) - added by MaThIbUs 9 years ago.
html-in-post-titles.2.diff (3.8 KB) - added by MathiasBynens 9 years ago.
The final patch.

Download all attachments as: .zip

Change History (32)

comment:1 MaThIbUs9 years ago

  • Patch set to No

comment:2 MaThIbUs9 years ago

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

MathiasBynens9 years ago

The final patch.

comment:3 MathiasBynens9 years ago

  • Keywords kubrick title attribute html validation added
  • Milestone set to 1.5.2

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

comment:4 MathiasBynens9 years ago

  • Priority changed from normal to high
  • Version changed from 1.5.1.1 to 1.5.2

comment:5 MathiasBynens9 years ago

  • Owner changed from anonymous to MathiasBynens

comment:6 markjaquith9 years ago

  • Priority changed from high to low

comment:7 markjaquith9 years ago

  • Keywords bg|dev-feedback bg|2nd-opinion added

Passed to devs for feedback.

comment:8 follow-up: davidhouse9 years ago

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

comment:9 MathiasBynens9 years ago

My point exactly.

comment:10 error9 years ago

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

comment:11 matt8 years ago

  • Milestone changed from 1.6 to 2.1
  • Priority changed from low to lowest

comment:12 ranchnachos8 years ago

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

comment:13 rgovostes8 years ago

  • Keywords has-patch added

comment:14 matt7 years ago

  • Milestone changed from 2.1 to 2.2

comment:15 rob1n7 years ago

  • Keywords dev-feedback 2nd-opinion added; kubrick title attribute html validation bg|dev-feedback bg|2nd-opinion has-patch removed
  • Severity changed from normal to minor
  • Version changed from 1.5.2 to 2.1

comment:16 rob1n7 years ago

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

comment:17 Martin107 years ago

I agree with rob1n. No HTML in titles.

comment:18 Nazgul7 years ago

  • Milestone 2.2 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:19 follow-up: ManxStef7 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:20 in reply to: ↑ 19 ; follow-up: Otto427 years ago

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.

comment:21 in reply to: ↑ 20 foolswisdom7 years ago

  • Version changed from 2.1 to 2.3

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.

comment:22 Nazgul7 years ago

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

Reclosing as wontfix based on the last couple of replies.

comment:23 JoostdeValk7 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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

comment:24 foolswisdom7 years ago

  • Milestone set to 2.4 (future)

comment:25 in reply to: ↑ 8 f00f7 years ago

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.

comment:26 follow-up: thee177 years ago

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.

comment:27 in reply to: ↑ 26 JeremyVisser7 years ago

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.

comment:28 Otto427 years ago

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

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.

comment:29 Otto427 years ago

  • Milestone 2.4 deleted

comment:30 ricfischer4 years ago

  • Cc ricfischer added
  • Version changed from 2.3 to 2.9.2

I have two posts. One was about an ISP company denying their customers access to my sites. The second, about 3 months later, was about the same company finally allowing their customers access to my sites.

Original post's title: Qwest Denies Their Customers

New post's title: Qwest <strike>Denies</strike> Allows Their Customers

Strike is the now-deprecated way of doing a strike-through. <del></del> is the replacement.

I've had to edit the title because, while gone from WP for well over a year, updates to WP have forced Textile to not work and the Textile plugin wasn't updated. Apparently, Textile must've allowed the <strike></strike> to work.

I see no reason why a philosophy of accepting all input (within reason depending on the field) but scrubbing the output cannot apply. Generating RSS? Scrub the output to make sure it complies with RSS. Creating a menu of posts from post titles? Scrub it appropriately. Since <del> and <ins> are non-block elements, I believe they should be allowed where other XHTML is allowed.

Another example is citing the name of a book or movie or some such and allowing the user to recognize it is the name of a book or movie. Do we just stick with old-school style and use single quotes or can we move forward at all with the greater flexibility computers and the web allow?

Leaving this closed. I welcome a discussion why minor style attribute elements cannot be applied in headlines, excluding <strong>, of course.

Note: See TracTickets for help on using tickets.