This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html Multipage: http://www.whatwg.org/C#application/xhtml+xml Complete: http://www.whatwg.org/c#application/xhtml+xml Comment: Define fragment identifier processing. RFC 3023 is useless for this purpose. Posted from: 113.197.157.202 User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.107 Safari/535.1
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: Lets wait for the long promised update of RFC 3023 to fix it until we do something here. XML media types are a mess.
This bug was cloned to create HTML WG bug 19070.
Anne, is this relevant to your interests given the context of Fetch and URL, or is this really only relevant for us in HTML navigation land?
Fetch ignores the fragment identifier (it's up to whatever invokes Fetch to do something with it). URL does care about serializing and exposing it via API (there are many interoperability issues there :-(). Processing however seems in the realm of HTML. E.g. navigate, but also <img>/<video> for the media fragment stuff.
I don't really know what to do here. The spec is right; it's the same for application/xhtml+xml as any other XML MIME type. The spec also does define the processing already, in the "update the session history with the new page" algorithm. So it's not clear what really needs doing, in the HTML spec.
http://www.whatwg.org/C#the-indicated-part-of-the-document says the same. In any event, I did not file this bug. I think that maybe we should eventually define it as we already define loading XML into a browsing context, we have changed how parsing XML works, etc. but I also do not really care much.
It _is_ defined in that way. The behaviour here is defined. All that's not defined is the author-side semantic of a fragment identifier. It's really a bug on RFC 3023. I guess we can punt this until such time as we find a way to fix the MIME type registry and put it there.
This is already defined.