Support » Requests and Feedback » get_the_category_list produces rel attribute with invalid values

  • In the file “wp-includes/category-template.php”, in the function called get_the_category_list()

    There are links produced, for category linkage in the content template, which have a rel attribute, which has values that are invalid.

    On my blog the links suffer this failure on validation:

    Bad value category tag for attribute rel on element a: Keyword category is not registered.

    Apparently it’s trying to put “category” in the rel attribute which is not supported by W3C standards.

    To fix the validity, of the content produced by wordpress, I would like to make the following suggestions:


    Change This line (in wp-includes/category-template.php):

    $rel = ( is_object( $wp_rewrite ) && $wp_rewrite->using_permalinks() ) ? 'rel="category tag"' : 'rel="category"';

    The current code appears to be saying, if using rewrite and if using permalinks, list it as a category and tag, otherwise just a tag.

    This is an incorrect semantic use of these rel tags as described by W3C. According to official html5 specification, the tag link is as follows:

    “Gives a tag (identified by the given address) that applies to the current document.”

    In the context of wordpress, this would be applicable to both tag and category links.

    Since there is no such thing as a “category” link type, use rel=”tag” for both category and tag links. I suggest using the “bookmark” type for indicating a permalink; which would be more appropriate in this situation:

    “Gives the permalink for the nearest ancestor section.”

    A more semantically correct line to produce the rel attribute would be this:

    To this:

    $rel = ( is_object( $wp_rewrite ) && $wp_rewrite->using_permalinks() ) ? 'rel="bookmark tag"' : 'rel="tag"';

    I think this will achieve the desired effect of the rel attribute in this context. “tag” is appropriate regardless of using permalinks because tag describes a relationship to application content. This is something that category and tag links both do in the wordpress context. “bookmark” is indicative of a permalink and so it is appropriate in the true condition of this clause.


    This may be a better option than all of the above:

    Just let the template creators define this attribute in their templates. Give a good example of how to do it in twenty(twelve?), and otherwise give content producers the ability to sculpt their links as they please.

Viewing 9 replies - 1 through 9 (of 9 total)
  • Hi Jesse,

    Even though you are right about the rel attribute only supporting a strict list of values in HTML 5 at the moment, this doc type is still in an experimental stage, so it might be a little premature to start changing core functions, such as get_the_category_list, before it is officially released and broadly supported.


    Hi Marventus,

    Do you have information that indicates “category” will be added to the legal rel values in html5 specification? I have never seen it talked about in any documentation or white paper. I don’t believe its appearance in WordPress will be relevant in it becoming a part of the html5 standard. So I’m not sure why it’s there in the first place and I’m not sure what value it has to wait until html 5 revision is official. It’s invalid now and it has every likelihood of being just as invalid as when html5 is the new official revision.

    The link I posted shows a table of available rel values and their valid use in relation to link, a, and area. link is not an attribute it’s a tag name like a. a is an anchor, like for creating hyperlinks, link is for bringing in external assets like stylesheets. rel is an attribute that’s available on both link and a, and area. The “link type” is exactly what “rel” is.

    I understand what you mean, and again, I agree with you overall. What I was trying to say is that WordPress is a huge platform with a lot of different elements, and core developers work extremely hard to bring new features into it every day. I know they are currently working on the 3.3 version as we speak, for instance.
    In light of this, and the titanic amounts of work this requires, it would seem premature (and potentially a waste of valuable resources and time) to modify core files in order to implement features (be it, doc types, functions, etc.) that are still undergoing testing and have not been fully released, mainly because they might change in time, rendering some of the previous implementation work useless.
    My 2 cents.

    Moderator Ipstenu (Mika Epstein)


    🏳️‍🌈 Halfelf Rogue & Plugin Review Team Rep

    I would also add in the buggers are still making changes to HTML5 spec (including the dropping of <time>). This is a ‘Not yet.’ thing.

    Yep, I thought so. Thanks for confirming, Ipstenu.

    There is a lot of confusion about time being removed and reinstated, mostly brought on by media reports from people who don’t understand what is going on.

    Ian ‘Hixie’ Hickson filed a bug “Consider replacing time with data” on 2011-07-14(See:

    Ian ‘Hixie’ Hickson closed the bug on 2011-10-29, removing it from the HTML5 spec (See: It was immediately applied to the HTML5 SVN (See:

    However the W3C WG chairs vetoed minutes, Ian ‘Hixie’ Hickson’s decision in their meeting on 2011-11-03 (See:

    As far as I can tell, this issue never affected the HTML5 Working Draft (See: which is edited by Ian ‘Hixie’ Hickson), only the Editorial Draft.

    The HTML5 validation, offered by the W3C, is powered by the parsing power of, which utilizes an HTML5 parsing algorithm defined by WHATWG (Web Hypertext Application Technology Working Group) at

    The information web developers (like us) need, to ensure HTML5 is used correctly, can be found at with all the browser lingo removed. Guess what, this space is also edited by Ian ‘Hixie’ Hickson (and Ben Schwarz).

    Don’t get me wrong, I’m an advocate for the time element. However, Ian Hickson didn’t singlehandedly modify and change the HTML5 “Working” specification, we all use and that the various browsers understand when presenting our code. He made a proposal, based on his findings and concerns, and then tried to persuade the group with his position and opinions. So what? Everyone does this from one time to another.

    However, to my knowledge rel=”category” and rel=”category tag” has never been part of the HTML5 specification. It has been proposed by a private party, outside of those who build the specification, and it wasn’t proposed with any kind of formal specification backing (See:

    If you look at carefully, you’ll see an entire list of rel keywords, whose status is proposed. However, this doesn’t mean they are part of the HTML5 working specification, and may not be likely to get in (See: under Status:Proposed). rel=”category” and rel=”category tag” has not received wide peer review and approval… thus it is invalid and not part of the HTML5 Spec and invalid.

    Until one of the major players in the HTML5 Working Group, formally submit a request, with a working specification, and use cases on how it is used, it will not be added. The ones proposed by Apple validate!

    With all the intellect involved in developing WordPress, it seems this particular issue has escaped the minds of some brilliant people. Why anyone would add rel=”category” and rel=”category tag” to the internal framework of WordPress, even while it is completely unsupported, is beyond me. It’s not like it showed up due to a theme developer. It was built into the WordPress Framework.

    My solution, DELETE IT! If Google’s own Ian ‘Hixie’ Hickson doesn’t consider it valid, I do not see any benefit, in using it.

    @paul Biron – I’m there 😉

    I have a same case here >>

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘get_the_category_list produces rel attribute with invalid values’ is closed to new replies.