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:
- multiple values for attributes (which includes, but is not limited to, the
rel attribute), and
- allowed values in the
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:
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.
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
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.
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 126.96.36.199). 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?