WordPress abuses Rel Tag

Sorry I hope I got it posted in the same place, he was complaining about W3C errors for about the same thing. I have moved it.

Thanks

Having just stumbled upon this problem myself I first opened a bug against validator.w3.org (see [1]).

The initial response from the W3C Validator team is that they are reporting @rel=’category tag’ as an error because while there is an entry in the Microformats wiki entry for it, that error is invalid because the Specification field of that entry is empty. I’ve replied to them that I still think it is an error in the validator because the HTML5 spec doesn’t say the entry in the Microformats wiki must be a valid/legal entry, just that the Status = “proposed” (or “ratified”)…and as one of the editors of a W3C spec [2] I’m particularly sensitive to whether code conforms to the precise wording of a spec.

So, as soon as I get through reading the background stuff [3] on reporting a WordPress bug I will open a bug that the WordPress dev team should:

1. write a spec on what @rel=’category’ means
2. update the Microformats wiki entry for it
3. remove the Microformats wiki entry for ‘category tag’
4. inform the W3C Validator team that the Microformats wiki has been updated

and then the Validator should not flag this as an error.

I’ll come back here and and post a link to the WordPress bug that I open once I have done so.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16510
[2] http://www.w3.org/TR/xmlschema-2/
[3] http://codex.wordpress.org/Reporting_Bugs

@bamajr: the reason “people keep quoting the microformats list” is that the HTML5 spec does (http://www.w3.org/TR/html5/links.html#other-link-types):

Conformance checkers must use the information given on the Microformats wiki existing-rel-values page to establish if a value is allowed or not: values defined in this specification or marked as “proposed” or “ratified” must be accepted when used on the elements for which they apply as described in the “Effect on…” field, whereas values marked as “discontinued” or not listed in either this specification or on the aforementioned page must be rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).

That is, the microformats wiki entries ARE “part of the HTML5 WD” by inclusion.

As mentioned in my comment yesterday on this thread, the reason the W3C Validator (and any other validators out there that are conformant with the HTML5 WD) flags @rel*=’category’ as a valdiation error is simply because no one has written a “specification” for what it means and added that to it’s microformats wiki entry. Once that happens it will “magically” be considered valid.

And as I said yessterday, if someone (preferably someone involved in writing the code in WordPress that spits it out 🙂 sends me the text for that spec, I will ensure that all the rest of the necessary steps happen.

Hi. I saw a parallel discussion to this thread was taking place here and I thought I should reply here since this thread is older.
Even though I think great contributions have been made by everyone involved, I get the impression there’s a certain level of confusion regarding two entirely separated things:
t

1. multiple values for attributes (which includes, but is not limited to, the rel attribute), and
2. allowed values in the rel attribute.

Let’s break this down a bit, then.

1. Multiple Values for Attributes:
I would like to confirm that Ipstenu is absolutely right about this and that white spaces as multiple value separators are allowed in all doc types (except XML).

2. Allowed values in Rel Attribute:
2.1. HTML4
Section 6.12 of the specs,after listing several values for the rel attribute, reads:

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types.

2.2.XHTML 1.0
I was not able to find any explicit uses of link types in the Specs. However, Section 4, which describes the differences between XHTML and HTML4, does not explicitly mention anything about the use of the rel attribute. Also, Section 4.11 (Attributes with predefined value sets) does not target the attribute rel.
All these conclusions do not seem to be DTD-dependent.
2.3. XHTML 1.1
There do not seem to be any relevant references to the issue at hand in the Specs.
2.4. HTML5
Section 4.12.4 of the Editor’s draft defines a list of link types (where the tag attribute is included), but before doing so, it clearly states:

The following table summarizes the link types that are defined by this specification. This table is non-normative.

Bolded text is my own. That, to me, reads “other values can be used”, such as, for instance, the ones on the Microformats wiki list (as per sub-section 4.12.4.14). In that list, I can confirm that category has a proposed status, so AFAIK, it should be recognized for the time being.

Even if it wasn’t, and if one were to take link types in HTML5 in a restrictive/normative way, one would still be forced to admit that rel is not invalid in other doc types, such as HTML4 and XHTML. Saying, as bamajr did in the other thread, that rel="category tag" should be deleted just because it is not supported in an HTML5 yet (which is experimental), does not seem to make much sense to me. From a logical point of view, such reasoning could be outlined like so:

Component 1 is allowed in environment A.
Component 1 is allowed in environment B.
Component 1 is not allowed in environment C.
———————————————————
Thus, Component 1 is not allowed anywhere and should be deleted.

This, of course, is completely invalid (logically speaking).

So, the bottom line seems to be that the rel attribute does support unlisted values, and the only environment in which it might not be supported (in my opinion it is partially, but I leave this open for discussion) is still experimental and is not bound to be ready for the next couple of years.
Why should the coredev team address this now?

I realized I made a mistake under point 2.4. I said:

the Editor’s draft defines a list of link types (where the tag attribute is included)

which was a mistake, since it should have read:

the Editor’s draft defines a list of link types (where the tag value is included)

Sorry about that!

Hi Paul,
Thanks for the extra info. Summarizing your research and mine, it would seem that:
1. It is safe to use pretty much any rel value for HTML4 and XHTML;
2. In HTML5, only values included in the table at the beginning of Section 4.12.4 are 100% safe, and tag is one of them;
3. In HTML5 again, resorting to a value outside of that table, such as the ones included in Microformats, is not 100% safe since these could potentially disappear in the final implementation of the specs. As a side question, can values that are “ratified” also be dropped in the final stages?

Applying all that to the issue at hand, it seems that:

rel="tag"

is safe regardless of the Doctype, whereas:

rel="tag category"

is just plain silly because category is not included in Section 4.12.4 of the HTML5 specs nor it is defined or sustained in Microformats by WP or anyone else. Moreover, it seems unlikely that category is ever going to be included due to the fact that the value tag is already recognized and it would be redundant to have both.

All this seems to lead to the conclusion that the easiest solution to this issue would be to simply change the get_the_category_list function’s (and any other similar or related functions’) HTML output to rel="tag". This would ensure doctype cross-compatibility and avoid future potential problems regarding the experimental nature of HTML5. Your idea of turning this into a parameter still seems good to me, since certain users and/or developers might not want to include the rel attribute and, AFAICT, more flexibility has always been preferable to less flexibility when it comes to webdev, 🙂