In particular, Gecko does not do this, an while there were some reports about it back about 10 years ago; it's been years since we last had a report about it.

Given that, we don't think this particular IE quirk is something worth imposing on the web forevermore.

This surprises me.  Does Gecko support \ in file URLs on Windows?

Gecko does support replacing backslash with forward slash in file: URLs on Windows and OS/2.

Gecko also supports, on Windows and OS/2, converting backslashes in urls typed in the url bar (but NOT urls in web pages) to forward slashes, if the scheme is one of "http", "https", or "ftp".

There are no other cases in which we do such replacement.

See the net_NormalizeFileURL call in nsFileProtocolHandler::NewURI for the former replacement and the XP_WIN|XP_OS2 block in nsDefaultURIFixup::CreateFixupURI for the latter fixup.

Moreover, the current spec asks User-Agents to replace backslashes AFTER resolving the URI. But actual implementations (at least Mozilla on Windows for file URIs) replace it BEFORE resolving. Otherwise relative path resolving will not be handled correctly (consider about ".\" or "..\" or "\topleveldirectory").
It's obvious that the backslash replacement clause was added in an unconsidered way.

Eventually this section will be replaced by http://tools.ietf.org/html/draft-abarth-url so it might be better to focus on that draft.

mass-move component to LC1

(In reply to comment #5)
> Eventually this section will be replaced by
> http://tools.ietf.org/html/draft-abarth-url so it might be better to focus on
> that draft.

Adam? Any plan to update the URL draft to address this?

> Adam? Any plan to update the URL draft to address this?

I'm not planning to update that draft anytime soon.

un-assigning Adam for this per comment #8

Does anyone know if we have a component for URL spec issues? Or any other tracking mechanism?

(In reply to comment #10 from Hixie)
> Does anyone know if we have a component for URL spec issues? Or any other
> tracking mechanism?

we do now

Moving back to component="LC1 HTML spec" in order to comply with the decision policy, and cloned this bug to create bug 15684

Hixie, I would suggest that you change the status on this bug to RESOLVED with a comment that the plan is for this to be handled in the URL spec, and that bug 15684 is the bug for tracking this going forward.

If you do that and anybody objects to this bug being resolved that way, the decision policy gives them the option of reopening this bug and explaining why.

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: see comment 12

*** Bug 14693 has been marked as a duplicate of this bug. ***

Please keep this bug open until the text it is about is indeed gone.

This needs to be resolved prior to entrance to CR.  See also http://lists.w3.org/Archives/Public/public-html/2012Nov/0201.html

I'm moving this to .next because:

• It won't be addressed before CR;
• It's probably too big of a change to address in CR;
• While not specified in an optimal manner, the behaviour appears to be supported by all browsers save one and so is widespread (user questions on StackOverflow show that it does lead to interop issues);
• The slated replacement for this section (Anne's URL spec) maintains this feature.

So all in all, removing this text now would do more harm than good, and would be less in line with reality than including it, even if it is imperfect. This doesn't mean we're giving up on perfection: that's what .next is for.

Mass move to "HTML WG"

Mass move to "HTML WG"

Reviving discussion for this on public-html:

http://lists.w3.org/Archives/Public/public-html/2013Feb/0069.html

Reassigning to Silvia, to cherry-pick from the WHATWG spec:

https://github.com/w3c/html/commit/5eba22bd9dfec1295f6108e002d3a3a157287767

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: Accepted
Change Description: Adopted the WHATWG change to integrate with URL specification (which omits the logic errors of the original URL parsing algorithm outlined in HTML5)
Rationale: 

This was originally a LC1 bug which was won't fixed (Comment 13) in order for discussion to continue in cloned WHATWG bug 15684, which was ultimately won't fixed. In the meantime, Bug 14693, which points out a logical error in the URL parsing algorithm, was duped to this bug. This bug was then reopened on the grounds that it should not be resolved until the erroneous text of the algorithm be removed and the logic ammended. The following commit merged from the WHATWG spec does this and defers to the URL specification to define parsing logic:

https://github.com/w3c/html/commit/b2e4d7e252df4c1be9e71666ec794ab0b2fa3a3e

Going forward, bugs in URL parsing should be filed on that spec.

This is actually WONTFIX because WHATWG specs WONTFIXed the corresponding bug 15684.