This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The decision on ISSUE-27 has resulted in a state where the semantics of link relations may depend on where they appear in (Link: HTTP header vs HTML content). Minimally, the spec should clarify that there's potential for conflict, and explain that the semantics of link relations appearing in the HTTP Link header field are defined by RFC 5988 and the IANA link relations registry, not the Microformats Wiki.
I doubt that is how it would end up being implemented in a user agent that implements both. At least in Opera the code is partially shared.
In which case you should open a bug requesting the spec to define *that*.
mass-move component to LC1
What does this have to do with HTML?
(In reply to comment #4) > What does this have to do with HTML? The spec tries to define UA behavior for many things which are not "HTML". It already *does* talk about processing Link headers and cites RFC 5988. So just clarify this, please.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: This has nothing to do with HTML. The semantics of Link: headers apply just as much when there is no HTML document at all and all that is being viewed is a pure SVG or even pure arbitrary-XML document. It is completely out of scope for HTML to define this.
From the EDITOR'S RESPONSE "please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so" Does anybody want to propose title and text for the tracker issue? Or to create the tracker issue themselves?
http://www.w3.org/html/wg/tracker/issues/174
Working Group Decision: http://lists.w3.org/Archives/Public/public-html/2011Dec/0054.html Change Proposal: http://lists.w3.org/Archives/Public/public-html/2011Oct/0108.html
The decision is to replace this paragraph: "HTTP Link: headers, if supported, must be assumed to come before any links in the document, in the order that they were given in the HTTP entity header. (URLs in these headers are to be processed and resolved according to the rules given in the relevant specification; the rules of this specification don't apply.) [HTTP] [WEBLINK]" By these two paragraphs: "HTTP Link: header fields, if supported, must be assumed to come before any links in the document, in the order that they were given in the HTTP message. These header fields are to be processed according to the rules given in the relevant specifications. [HTTP] [WEBLINK] Note: registration of relation types in HTTP Link: header fields is distinct from HTML5 link types, and thus their semantics can be different from same-named HTML5 types." with "HTML5 link types" being a cross-reference. In the WHATWG copy the wording of the second paragraph will have to be slightly different, obviously.
(In reply to comment #10) > ... > In the WHATWG copy the wording of the second paragraph will have to be slightly > different, obviously. Not obvious to me. Please elaborate.
I imagine Ian simply means that the WHATWG spec would s/HTML5/HTML/ in the last paragraph.
(In reply to comment #12) > I imagine Ian simply means that the WHATWG spec would s/HTML5/HTML/ in the last > paragraph. Ah. Well, that can be the same in both specs.
Can the chairs confirm that it's ok to s/HTML5/HTML/ in this text?
(In reply to comment #14) > Can the chairs confirm that it's ok to s/HTML5/HTML/ in this text? The chairs will not intercede unless there is an objection by a WG member. This does not look likely here.
Done.
Checked in as WHATWG revision r6956. Check-in comment: Tweak the wording per chair decision. http://html5.org/tools/web-apps-tracker?from=6955&to=6956