This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13787 - Define fragment identifier semantics for XML MIME types
Summary: Define fragment identifier semantics for XML MIME types
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Whiteboard: registry
Depends on:
Reported: 2011-08-15 14:45 UTC by contributor
Modified: 2016-03-22 14:50 UTC (History)
6 users (show)

See Also:


Description contributor 2011-08-15 14:45:52 UTC

Define fragment identifier processing.	RFC 3023 is useless for this purpose.

Posted from:
User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.107 Safari/535.1
Comment 1 Anne 2011-08-15 15:42:07 UTC
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: <>.

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.
Comment 2 Michael[tm] Smith 2013-01-30 07:54:09 UTC
This bug was cloned to create HTML WG bug 19070.
Comment 3 Ian 'Hixie' Hickson 2013-03-22 17:54:19 UTC
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?
Comment 4 Anne 2013-03-23 13:36:40 UTC
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.
Comment 5 Ian 'Hixie' Hickson 2013-10-22 22:04:11 UTC
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.
Comment 6 Anne 2013-10-23 10:37:31 UTC 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.
Comment 7 Ian 'Hixie' Hickson 2013-10-23 18:53:43 UTC
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.
Comment 8 Anne 2016-03-22 14:50:15 UTC
This is already defined.