This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"4.8.5 The object element ... If that is successful, fetch the resulting absolute URL,..." This should say "...fetch the resource identified by the resulting..." (according to the definition of 'fetch').
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: Partially Accepted Change Description: see diff given below Rationale: The terminology is used all over the place, so I just changed the "fetch" algorithm to allow it to be used with either a resource or a URL.
Checked in as WHATWG revision r4518. Check-in comment: make 'fetch' support being called with a URL, since that is what the spec does all over the place anyway. http://html5.org/tools/web-apps-tracker?from=4517&to=4518
You just made things even more confusing. URLs are identifiers. The result of "fetching" an identifier isn't the same thing as fetching what it identifies (there's a difference in the levels of indirection). Please undo, and just make the spec consistent.
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: Nonsense, people talk about fetching URLs all the time, it's not confusing at all.
The purpose of a spec is not to mirror the language that "people use" (which is acceptable to be sloppy), but to be consistent internally, consistent with other specs, and precise.
No, the purpose of a spec is to set out what should happen in such a way that interoperability is achieved. It could be sloppy and inconsistent and completely intelligible, if that happened to be the way to get interoperability (it rarely is). In this particular instance, however, it is self-consistent, unambiguous, and consistent with numerous specs (just not some that happen to themselves be ambiguous and confusing in their terminology use).