This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Citing <http://dev.w3.org/html5/spec/Overview.html#other-elements-attributes-and-apis>, as of 2009-09-03: "[Supplemental] interface HTMLHeadElement { attribute DOMString profile; }; User agents should ignore the profile content attribute on head elements. When the attribute would be used as a globally unique name, the user agent should instead always assume that all known profiles apply to all pages, and should therefore apply the conventions of all known metadata profiles to the document. When the attribute's value would be handled as a URL and dereferenced, the user agent may resolve the attribute's value, and if that is successful, may then fetch the resulting absolute URL and apply the appropriate processing. The profile IDL attribute of the head element must reflect the content attribute of the same name." This makes it sound as if the attribute value is a single URI; that is not the case. The related text in HTML 4.01 is inconsistent, and this has been a known bug for eternity. The HTML WG should fix this misunderstanding.
HTML4's text on this is hard to follow, but it seems there is content out there using multiple URLs: http://philip.html5.org/data/profile-values-2.txt And it seems some processors handle it.
Why was this bug closed?
It was closed because the spec section you cite now process profile as multiple space-separated URLs as you requested: "When the attribute's value would be handled as a URL and dereferenced, the user agent must use the following steps: Split on spaces the the value of the profile attribute. Resolve each resulting token relative to the meta element. For each token that is successfully resolved, fetch the resulting absolute URL and apply the appropriate processing."
(In reply to comment #3) > It was closed because the spec section you cite now process profile as multiple > space-separated URLs as you requested: > > "When the attribute's value would be handled as a URL and dereferenced, the > user agent must use the following steps: > > Split on spaces the the value of the profile attribute. > > Resolve each resulting token relative to the meta element. > > For each token that is successfully resolved, fetch the resulting absolute URL > and apply the appropriate processing." The spec still says "...When the attribute would be used as a globally unique name..." and "When the attribute's value would be handled as a URL...". Why not simply state that it's a set of whitespace separated tokens/URLs?
> The spec still says "...When the attribute would be used as a globally unique > name..." and "When the attribute's value would be handled as a URL...". Fixed, thanks. > Why not simply state that it's a set of whitespace separated tokens/URLs? It's not anything, the attribute isn't allowed to be set.
Checked in as WHATWG revision r3948. Check-in comment: Clarify that profile='' took multiple tokens. http://html5.org/tools/web-apps-tracker?from=3947&to=3948
"When the attribute's value would be handled as a list of URLs to be dereferenced..." Dereferencing is totally optional in HTML 4, so it's not clear why it's mentioned here. Just say: "When the attribute's value would be handled as a list of URLs, ..."
There are two cases that you have described that implementations do: a. Treating the URLs as magic tokens. b. Treating the URLs as identifying resources to apply. Both cases are treated in the spec; the text you quoted is the text for (b). Remarking FIXED since this now addresses your original comment. If you still disagree with the text, please file a new bug specifying what the problem with the new text is.
Ack. In that case, my objection moves to the other sentence: "When the attribute would be used as a list of globally unique names,..." That should just say URIs, as does HTML4.
I don't understand the difference, but ok, done.
Checked in as WHATWG revision r3966. Check-in comment: More tweaks to the profile='' attribute. http://html5.org/tools/web-apps-tracker?from=3965&to=3966
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, 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 This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.