This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Please clarify the expected behavior for the case when WEBADDRESSES parsing into components fails, such as for http://a[b].example.org/
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: Did Not Understand Request Change Description: no spec change Rationale: Could you clarify which concrete case you're talking about? As far as I can tell, all the places that refer to parsing URLs or refer to components of URLs are well-defined in the case of parse errors.
The "WEBADDDRESS" spec requires that parsing "fails" for: http://a[b].example.org/ "If w doesn't match the <URI-reference> production, even after the above changes are made to it, then parsing the Web address fails with an error. [RFC3986]" (see http://www.w3.org/html/wg/href/draft, Section 2, Step 6)
Yes, I know, I basically wrote that text. What concrete case doesn't handle this?
How many times do I need to repeat it? The case is http://a[b].example.org/ which, as far as I can tell, doesn't parse according to that spec.
If you're only asking about parsing, then there's no expected behaviour. The parsing fails. That also happens to be out of scope for HTML5 now, so I don't really know why you're asking me. There's no HTML in the example you gave, nor is there any DOM manipulation, or any XHTML, or anything that HTML gives any conformance criteria for. 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: Did Not Understand Request Change Description: no spec change Rationale: The question appears to be meaningless.
Here is a test case that I believe expresses Julian's intent: <a id="link" href="http://a[b].example.org/">Some link</a> <pre> <script> var link = document.getElementById("link"); document.writeln(link.protocol); document.writeln(link.hostname); document.writeln(link.pathname); </script> </pre> I think Julian wants it to be defined what this outputs. The results do not match among Safari, Opera, Firefox and Chrome. (The first two and the last two match each other.) Per WEBADDRESSES, the parsing in this case "fails with an error", and it does not say what the components are. HTML5 just uses the components returned by WEBADDRESSES, and does not handle the "failed with an error" case. Seems like one of the two needs to change.
Reopened per new information. (Hope that's ok, Julian.)
(In reply to comment #7) > Reopened per new information. (Hope that's ok, Julian.) Appreciated; although I don't think this is "new" information. It would be cool if your mediation wasn't needed here.
I think this is a bug in the URL spec by the way. When it says that parsing fails it should also say what each of the components are.
(In reply to comment #6) > Here is a test case that I believe expresses Julian's intent: > > <a id="link" href="http://a[b].example.org/">Some link</a> > <pre> > <script> > var link = document.getElementById("link"); > document.writeln(link.protocol); > document.writeln(link.hostname); > document.writeln(link.pathname); > </script> > </pre> That case is already defined. The spec says that it should write three empty strings. See the paragraph starting "On getting, if the input is an absolute URL" and ending "Otherwise, the attribute must return the empty string." in the Interfaces for URL manipulation section. (In reply to comment #8) > > Appreciated; although I don't think this is "new" information. It's new because it gives an actual case, unlike your report, which did not give enough information to determine the validity of the report. (In reply to comment #9) > I think this is a bug in the URL spec by the way. When it says that parsing > fails it should also say what each of the components are. There is no time as far as I am aware where the components are used if parsing fails. If there was such a time, that would be a valid bug. 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 above - there's no bug here
It appears I was mistaken. I agree that the spec does define this case (because a string is an "absolute URL" as defined in the spec if and only if parsing it succeeds.)
(In reply to comment #11) > It appears I was mistaken. I agree that the spec does define this case (because > a string is an "absolute URL" as defined in the spec if and only if parsing it > succeeds.) What confused me here is that "absolute URL" is *not* defined to be a URL that happens to be absolute, but comes with additional constraints. Not sure that this is a good idea; and also I'm very sure that we wouldn't want to use that terminology in IRIbis.
(In reply to comment #12) > (In reply to comment #11) > > It appears I was mistaken. I agree that the spec does define this case (because > > a string is an "absolute URL" as defined in the spec if and only if parsing it > > succeeds.) > > What confused me here is that "absolute URL" is *not* defined to be a URL that > happens to be absolute, but comes with additional constraints. Not sure that > this is a good idea; and also I'm very sure that we wouldn't want to use that > terminology in IRIbis. > The way the spec arranged things initially confused me and Anne too, though only because we didn't notice the "if the input is an absolute URL" bits. I could imagine IRIbis exposing an interface that makes this more clear.
I just realised why I couldn't work out what Julian was talking about. I didn't see the bug's summary, which contained critical information.