WordPress › Support » WordPress abuses Rel Tag

alsd
Member
Posted 1 year ago #

First it was just in the <head> section, now it spreads to link tag in the posts.

Below markup is from twentyten theme, in the twentyten_posted_in it added "category tag" for the rel attribute this results validation error:

This entry was posted in <a href="http://wordpress:8888/category/uncategorized/" title="View all posts in Uncategorized" rel="category tag">Uncategorized</a>

Bad value category tag for attribute rel on element a: Keyword category is not registered.
A whitespace-separated list of link types listed as allowed on <a> and <area> in the HTML specification or listed as an allowed on <a> and <area> on the Microformats wiki without duplicate keywords in the list. You can register link types on the Microformats wiki yourself.
esmi
Theme Diva & Forum Moderator
Posted 1 year ago #

The HTML 5 specification is still in the draft stage & has still not been formalised. The HTML 5 validator is experimental.
alsd
Member
Posted 1 year ago #

Validation error or not, don't know what it has to do with HTML5 not being formalized or the validator being experimental.

If you are really interested to dig in more,

I suggest you read up the rel attribute in HTML4, HTML5, XHTML and Microformat and double check the code I posted, find out where has gone wrong. It will help you understand better.
esmi
Theme Diva & Forum Moderator
Posted 1 year ago #

don't know what it has to do with HTML5 not being formalized

If the spec isn't formalised, that means it can change at any time. Therefore what was valid one week might not be the next. The HTML 5 spec isn't expected to be formalised until 2014. If you want nice clean reports from a W3C validator, stick to XHTML for the time being.
alsd
Member
Posted 1 year ago #

Please read up the rel attribute in HTML4, HTML5, XHTML and Microformat and double check the code I posted if you really interested in this issue.

wrong: rel="category tag"
correct : rel="category-tag"
correct : rel="category"
correct : rel="tag"
correct : rel="no-follow"

I posted the validation error, even if it passed the validation error it's still WRONG! The issue is not about the validation error; the code generated is being abused because it doesn't consider user may want to assign more than one category or moren than one tag to a post. In this case, even just one category assigned it still inserts two tags and it's wrong because :

1) a rel attribute can has only single word, it must not has space;
2) if the space is removed using PHP, it defeats the purpose of using the rel attribute in this area because "category-tag" has no semantical meaning.

A code like this will further prevent web developers from using attribute selector because no browser can interpret it when a space is presented.

Correct: a[rel~="catgory"] {color: red}

Wrong: a[rel~="catgory tag"] {color: red}
esmi
Theme Diva & Forum Moderator
Posted 1 year ago #

rel = link-types [CI]
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.

http://www.w3.org/TR/html4/struct/links.html
John P. Bloch
Member
Posted 1 year ago #

LOL! Pwnd.
alsd
Member
Posted 1 year ago #

"White space characters are not permitted within link types."

I am here to report a bug/an abuse or rel attribute, not here to argue with anybody who wants to be right. Hopefully the persons who are in charged of the WordPress core know better.
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

I am here to report a bug/an abuse or rel attribute

From the W3c site, it's not a bug, however if you strongly feel that way, submit a ticket to http://core.trac.wordpress.org/ (use the same ID/password used to login here) and report it. If you can do it with a suggested (code) fix, more the better :)

Sidebar: I searched http://www.w3.org/TR/html4/struct/links.html for the sentence "White space characters are not permitted within link types." and came up blank. Can you cite your source on that one?

I checked on http://validator.w3.org and it even said that they were allowed, provided they were in this list:

http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#linkTypes

However that list, as Esmi correctly pointed out, is a work in progress. Says so on http://microformats.org/wiki/existing-rel-values
alsd
Member
Posted 1 year ago #

http://www.w3.org/TR/html4/struct/links.html
rel = link-types [CI]
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.

http://www.w3.org/TR/html4/types.html#type-links

Authors may use the following recognized link types, listed here with their conventional interpretations. In the DTD, %LinkTypes refers to a space-separated list of link types. White space characters are not permitted within link types.

I think this should give everyone enough info to search the HTML5, Mircoformats, XHTML and so on...and what I wrote above stand.
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

The value of this attribute is a space-separated list of link types.

vs

White space characters are not permitted within link types.

So ... great w3 is contradicting themselves. :)

ETA - Ooooh no they're not. What the second bit means is 'Each link type must be one word, no white spaces.'

category and tag are SEPARATE link types, they're okay. The only issue is they're not defined.
alsd
Member
Posted 1 year ago #

FYI, I only posted the above link (html4) because esmi posted it.

My thought is WordPress uses it for both XFN and Microformats In HTML5. You don't ever find white space in rel or any link type in any of the references, if you ever see web developer using it, it's wrongly used. Tag keyword is in the HTML5 spec while category isn't, though it's not to say we can't use 'category' but we can't use it in a single rel attribute.

HTML5 Validator isn't incorrectly flagged it because it's experimental; it flags it as error because it's wrongly used - the spec doesn't allow two separate elements in a single rel attribute. Using PHP to get rid of the white space or substitue it with a 'dash' defeats the purpose of XFN and Microformat for the rel attribute because "categogerytag" or "category-tag" provides no semantical meaning.
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

Esmi didn't say HTML5 was incorrect, she said, and this remains accurate, that it's experimental. Which means its not locked and loaded, which MEANS it's a bit early to start kowtowing to rules that are not yet defined.

Which is all fair.

The microformats are in flux. Today there isn't one for category, tag isn't supposed to be used in a link, but that's changed a few times in the last year already, who knows what will happen in the next three years.

It's a case of putting the cart before the horse. When we get closer to HTML5 being locked, then it's the time to fuss. Until then, don't panic :)
alsd
Member
Posted 1 year ago #

It doesn't matter. Microformats can take all the time it wants to include something to the spec, and HTML5 can take all the time it needs.

What matter is: "White space characters are not permitted within link types.". It's clearly written in the HTML4 Spec. In W3C site the most frequent used wordings are "may", "should", "may not" and ''should not". When "not permitted" wording is used, it means what it said according to the spec, and there is no "may", "should", "may not" and ''should not" for interpretation.

The value of this attribute is a space-separated list of link types....So ... great w3 is contradicting themselves. :)

English isn't my tongue language so I do read the spec more literally, and read more into it with "space-separated" vs "space separated". The usage of "-" literally indicates the white space (if any) will replaced by a hypen. There is no contradiction.

What esmi said about HTML5 being experimental, in another word, is that it's an error caused by HTML5 validator and that it's not a abuse, not a issue (meaning it's correct in HTML4 and XHTML) - by saying so he/she lightly discard my report. And I do have a tiny bit issue because :1) I did my homework (cross-checked with HTML5, XTHML, HTML4 and Microformats) before I made the post; 2) I don't know what kind of power a moderator has - this is "Requests and Feedback" forum and I don't know if any WordPress team read the post or not, or if there is a screening procedure that first needs to pass through the moderator before it gets the attention from the WordPress team. If there is a screen procedure, it's very bad for the users and for WordPress if the moderator takes a feedback lightly without doing his/her homework thoroughly.

HTML5 being experimental as esmi said it, has nothing to do with "White space characters are not permitted within link types." REL attribute is not a newly invented element in HTML5 nor in Microformat, HTML4 clearly indicated that "white spaces are not permitted" and it will not changed in HTML5 or HTML6 50 years later.

Thanks for the info on the core.trac.wordpress.org, I was not aware of this place and didn't know I can use the same user account to file bug report. Next time I sure will go to the right place.
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

English isn't my tongue language so I do read the spec more literally, and read more into it with "space-separated" vs "space separated". The usage of "-" literally indicates the white space (if any) will replaced by a hypen. There is no contradiction.

Ah. That explains a lot :) Okay, the problem is you're reading it too literally. English is terribly inexact in some cases. (I'm studying French and its making me better at trying to pick the right words!)

In this situation, they use space separated to mean this: Each individual tag must be ONE word, without spaces, as space separation is used to separate individual tags from each other. Ergo 'tag' and 'category' are (potentially) valid, but 'house builder' is not and would need to be renamed 'housebuilder' instead.

Does that help?

The whole 'experimental' thing is ... HTML5 isn't set in stone. It's not a finished product. As the only invalidation in the rel tag usage is that we're using tags not-yet approved, it's a small 'bug', if it's a bug at all. I'm not convinced it is, personally, since so much of this is in-flux, and it's premature to say 'This is wrong!' when we're in that state.

2) I don't know what kind of power a moderator has - this is "Requests and Feedback" forum and I don't know if any WordPress team read the post or not, or if there is a screening procedure that first needs to pass through the moderator before it gets the attention from the WordPress team.

None at all. Our job is to keep the peace, filter spam, try and help, and that's it. We screen nothing :) We may go find a dev if we see something, or suggest you take it to trac if we think it should go there, but the development team reads as they like :) This forum is to openly discuss ideas and requests for WordPress.
Mike Baker
Member
Posted 1 year ago #

I realize this has been discussed, I am using a theme that is HTML5 with PHP and to be honest I don't know a lot of PHP but I am trying to learn. You buy themes, or use plugin that either cause a lot of errors or do not work properly, yet get approved by WordPress that is causes one to think, maybe a new platform in the way to go. But I love WordPress. My latest error which shows up as critical in my editor that validates code and shows up as seen below from W3C is.
Error Line 310, Column 153: Bad value tag[Gallery] for attribute rel on element a: Keyword tag[gallery] is not registered.

…100webhits.com_.jpg" class="preloader" rel="tag[Gallery]" title="100 Web Hits">

Syntax of link type valid for <a> and <area>:
A whitespace-separated list of link types listed as allowed on <a> and <area> in the HTML specification or listed as an allowed on <a> and <area> on the Microformats wiki without duplicate keywords in the list. You can register link types on the Microformats wiki yourself.

If Google doesnt like bad code is this a real problem or just a W3C problem?
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

Mike Baker - Make a new post for this. You're asking a support question, the OP was on about something else.
Mike Baker
Member
Posted 1 year ago #

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
Kowalsky
Member
Posted 1 year ago #

Hello,

this thread was interesting as I was having the same rel="category tag" validation error after updating my theme.

Ipstenu post was helpfull to understand the "white space" thingie as english is also not my mother tongue, but I still wasn't satisfied as the error was also there when using a clean install of WP and theme 2011.

So I had a look at the full code and found out this was coming from line 163 in wp-includes/category-template.php

I then replaced 'rel="category tag"' by 'rel="tag"' and got a valid HTML5 code.

So far it seems not to alter my WP but I know that on next WP update I'll have to modify the file again to keep the code valid.

The purpose of my comment : is there a reason using 'rel="category tag"' instead of 'rel="tag" in this particular place or could this fix be applied to the existing core code ?
Paul Biron
Member
Posted 1 year ago #
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
Paul Biron
Member
Posted 1 year ago #

There apparently was already a WordPress ticket related to this [1].

I added to it, noting what needs to be done [2]. With all luck that will happen soon.

[1] http://core.trac.wordpress.org/ticket/17632
[2] http://core.trac.wordpress.org/ticket/17632#comment:10
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

Further work should be done in trac :) Thanks, phiron!
bamajr
Member
Posted 1 year ago #

I've been searching for some rhyme or reason as to why rel="category" and rel="category tag" were used in the development of the WordPress core and found several WordPress.org posts about the topic.

I just posted a little history and explanation about this at http://wordpress.org/support/topic/get_the_category_list-produces-rel-attribute-with-invalid-values?replies=7#post-2720221

People keep quoting the microformats list (found at http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions) as valid rel keywords. However, they neglect to read the information, very plainly stating that there is no formal specification for rel="category" and rel="category tag" and the status of proposed means it has not received wide peer review and approval...

Its one thing to include elements which are already part of the HTML5 Working Draft, but completely different to include elements which are not even being considered at this time.
Paul Biron
Member
Posted 1 year ago #

@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.
bamajr
Member
Posted 1 year ago #

@Paul Biron - I understand that the HTML5 spec lists the microformats site. However, the rel keywords only become valid if someone creates and maintains a working specification for the rel keyword(s). rel keyword(s) without a defined specification is not valid HTML5.

Also, without the specification, no one knows how or when to use the rel keyword(s) correctly.

Without the specification, the rel keyword(s) are useless to search engines, which is kind of the point of using them in the first place.

Finally...

If you want to create and maintain the rel="category" microformat spec, you can simply copy/paste the rel="tag" spec and replace "tag" with "category" - that should give you all the language you need and is already in an approved format. Though finding implementations and references may be hard if WordPress is the only one using it.

A caveat may come in the form of usage. The way rel="category" is being used, is by microformat definition, the same thing as rel="tag" and if they aren't different in usage, I don't see why it is needed. I don't see how WordPress "Categories" are not defined under the rel="tag" microformat specification. Categories are tags.
Marventus
Member
Posted 1 year ago #
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?
Paul Biron
Member
Posted 1 year ago #

If you want to create and maintain the rel="category" microformat spec, you can simply copy/paste the rel="tag" spec and replace "tag" with "category" - that should give you all the language you need and is already in an approved format.

see my latest reply to the Trac ticket on this.
Marventus
Member
Posted 1 year ago #

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!
Paul Biron
Member
Posted 1 year ago #
@Marventus:

I'll try to answer your questions.

re: your 2.1: yes, HTML4 allows @rel to contain (essentially, see p.s. below) any value. In addition to the section you cite, there's also these fragments from the DTD [1]:
```
<!ENTITY % LinkTypes "CDATA"
    -- space-separated list of link types
    -->
<!ATTLIST A
  ...
  rel         %LinkTypes;    #IMPLIED  -- forward link types --
  ...
  >
```
re: your 2.2: the relevant sections of XHTML 1.0 are 4.7 [2] and 4.11 [3].

4.7 essentially says that @rel=' this is a test ' in an XHTML 1.0 doc gets treated the same as @rel='this is a test' in an HTML4 doc. 4.11 essentially says that @rel='THIS' and @rel='this' get treated differently within the same XHTML 1.0 doc; while they get treated the same within the same HTML 4 doc.

So, for XHTML 1.0, (essentially) any value for @rel is legal. The only difference from HTML4 is that the case of the "tokens" in the list are significant in XHTML 1.0 while they are not in HTML4.

re: your 2.3: the relevant sections of XHTML 1.1 is 5.2.3 [4] and 4.3 [5].

The conclusion is the same as for XHTML 1.0.

Note that [5] also contains the following text:

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. Please see the profile attribute of the head element for more information.

While HTML4 and XHTML 1.0 have head/profile, neither advises document authors the use it to define what is meant by their @rel values (and note the should even in XHTML 1.1.

re: your 2.4: while there is that note that the table at the start of 4.12.4 is non-normative, but it also says the subsequent sub-sections are normative...as far as the meanings of the values defined in HTML5 are concerned.

But the oft-cited section 4.12.4.14 [6] says that in addition to those values defined in 4.2.12.{1-13}, any value in (also oft-cited) microformats wiki [7] with a status of "proposed" or "ratified" are also valid.

I hope this helps!

p.s. the "(essentially)" qualification on "any value" above has to do with the fact that HTML4 and XHTML 1.0 define @rel to be CDATA. XHTML 1.0 defines CDATA to be anything that matches the Char production [8] in XML (whitespace and all other Unicode chars except those in the surrogate blocks, FFFE and FFFF). HTML4 also defines @rel to be CDATA, but doesn't explicitly say (AFAIR) what CDATA is...and it's been a while since I've read the SGML spec and I forget how it is defined there, but for all intents and purposes, it is the same as in XHTML 1.0.

XHTML 1.1 is different, however, because it defines @rel to be:
```
<xs:simpleType name="LinkTypes">
   <xs:list itemType="xs:NMTOKEN"/>
</xs:simpleType>
```
or
```
<!ENTITY % LinkTypes.datatype "NMTOKENS" >
```
depending on whether you're using the XML Schema [9] or DTD [10] Implementation.

Both of those mean a whitespace separated list of chars matching the Nmtoken production in XML [11].

And HTML5 is different still. It defines @rel as a DOMString, which ultimately goes back to section 1.1.5 of [12], and is defined a "sequence<unsigned short>".

Hi, may name is Paul...and I'm a language-lawyer :-)

[1] http://www.w3.org/TR/REC-html40/sgml/dtd.html
[2] http://www.w3.org/TR/xhtml1/#h-4.7
[3] http://www.w3.org/TR/xhtml1/#h-4.11
[4] http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_hypertextmodule
[5] http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_LinkTypes
[6] http://dev.w3.org/html5/spec/single-page.html#other-link-types
[7] http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
[8] http://www.w3.org/TR/REC-xml/#NT-Char
[9] http://www.w3.org/TR/xhtml-modularization/schema_module_defs.html#a_smodule_XHTML_Datatypes
[10] http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_XHTML_Datatypes
[11] http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken
[12] http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-C74D1578
Marventus
Member
Posted 1 year ago #
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, :-)

Topic Closed

This topic has been closed to new replies.

WordPress.org

Forums

WordPress abuses Rel Tag (30 posts)

Topic Closed

About this Topic

Tags

Code is Poetry