- From: <bugzilla@jessica.w3.org>
- Date: Mon, 17 Jan 2011 14:01:48 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11775 Summary: Hello, I'm just writing a quick note to question the non-inclusion of the "feed" link type (rel="feed") which I remember coming across a few months ago. When I originally saw the new rel type, I was very glad to see that there was finally a way to specify Product: HTML WG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: HTML5 spec (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: contributor@whatwg.org QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org Specification: http://www.w3.org/TR/html5/ Section: http://www.whatwg.org/specs/web-apps/current-work/#top Comment: Hello, I'm just writing a quick note to question the non-inclusion of the "feed" link type (rel="feed") which I remember coming across a few months ago. When I originally saw the new rel type, I was very glad to see that there was finally a way to specify a feed for automatic browser detection that didn't declare it (erroneously) as an "alternate representation" of the document, which had always seemed to me somewhat of a hack caused by feed technology overtaking the existing markup standards. In that respect, the new link type seemed like a good, semantically specific, and progressive addition to the language. It is already supported by Firefox at least, and since discovering it, I have been using it on all of my (X)HTML5 sites. I see that the definition of the "alternate" link type has been specifically updated (presumably to address the non-inclusion of "feed") to say "not necessarily syndicating exactly the same content as the current page", but this seems like a very uncomfortable way to cram multiple, potentially ambiguous uses into one keyword (remember, some feeds - especially on blogs - really are alternate representations of the current document). >From a quick Googling of the issue, the best information I can find suggests that the "feed" type was not included due to poor browser support and user adoption, but I would beg to differ on both points. Firstly, as mentioned before, Firefox (which is, after all, one of the most widely used browsers) already clearly supports it; and as for adoption by users, I can only put forward that I, as a developer very supportive of good standards and semantics, personally started using it as soon as I found out about its existence, but as there is very little information about it available yet, it took me some time to come across its existence at all, and I suspect that the reason for its lack of widespread adoption is simply that it is, after all, a new feature in an as-yet unfinished standard. Moreover, it seems to me that there is no real reason not to include a semantically useful new rel type, especially since as far as I am aware, there is no physical limit to the amount of "allowed values" that can be included in the spec. Indeed, there are already rel types included that seem to be of very little real semantic value ("nofollow" springs to mind as a value that is really only of use as a somewhat crude method of discouraging search engine spam, rather than providing any useful content for a user). For these reasons, I would like to humbly suggest that the "feed" link type is reconsidered for inclusion; and that perhaps a better response to a perceived lack of user uptake might be to better publicise its existence, rather than to remove it from the spec. Anyway, hope my thoughts on this are in some way constructive or useful - please do feel very welcome to copy me into any further discussion of this issue. Best regards, Ryan J. Bury ryanjbury@gmail.com www.rjbsoftware.co.uk Posted from: 78.148.149.187 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 17 January 2011 14:01:52 UTC