On 11/25/2014 03:52 PM, David Walp wrote:
Apologies for being a late comer to the discussion, but here is some feedback
in our implementation. We're looking forward to engaging on these interactions
more proactively in the future.
On Wednesday, October 29, 2014 6:55 PM, Sam Ruby <ru...@intertwingly.net> wrote:
Now to get to what I personally am most interested in: identifying
changes to the expected test results, and therefore to the URL
specification -- independent of the approach that specification takes
to describing parsing. To kick off the discussion, here are three examples:
1) http://intertwingly.net/projects/pegurl/urltest-results/7357a04b5b
A number of browsers, namely Internet Explorer, Opera(Presto), and
Safari seem to be of the opinion that exposing passwords is a bad
idea. I suggest that this is a defensible position, and that the
specification should either standardize on this approach or at a minimum permit
this.
Yes, we, Microsoft, are of the opinion that exposing passwords is a bad idea.
Based on received feedback, customers agree and I suspect our customers are not
unique on this opinion.
I've filed a bug on your behalf:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27516
There already is a discussion as a result. I encourage you to register
with bugzilla and add yourself to the cc-list for this bug.
2) http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190
This is not a valid URL syntax, nor does any browser vendor implement
it. I think it is fairly safe to say that given this state that there
isn't a wide corpus of existing web content that depends on it. I'd
suggest that the specification be modified to adopt the behavior that
Chrome, Internet Explorer, and
Opera(Presto) implement.
Agreed. Standardizing something not used that is not in anyone's interest. What you
have posted on Github:
https://github.com/rubys/url/tree/peg.js/reference-implementation#readme ".. I found
I had a hard time determining what should be the parsing output for a number of
cases." rings true here. There is no advantage to adding complexity when it is not
required.
I've filed a bug on your behalf:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27517
Hopefully you find the following work-in-progress easier to follow:
https://specs.webplatform.org/url/webspecs/develop/
If not, please let me know how it could be improved.
3) http://intertwingly.net/projects/pegurl/urltest-results/61a4a14209
This is an example of a problem that Anne is currently wrestling with.
Note in particular the result produced by Chrome, which identifies the
host as a IPV4 address and canonicalizes it.
This is the type of interop issue we think should be a focus of the URL
specification and the W3C efforts.
This is the subject of an existing bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26431
The webspecs link above contains a concrete proposal for resolving this.
Finally we are focused at identifying and fixing real-world interop bugs that we see in live sites
in support our goal of "The web should just work...".
(http://blogs.msdn.com/b/ie/archive/2014/05/27/launching-status-modern-ie-amp-internet-explorer-platform-priorities.aspx).
For example, I think you had at one time listed an IE issue in the discussion section of the URL
spec - http://intertwingly.net/projects/pegurl/url.html#discuss. This bug was related to a missing
"/" at the front of URLs under certain conditions. Since this issue has been removed
from the discussion section, I am hoping you have seen that we have fixed the issue. We are
actively pursuing and fixing similar interop bugs. We want the URL spec to be source of interop
behavior and believe that our goal is in line with your direction.
To the best of my knowledge, the fix has not been released, but a
workaround has been published. See:
https://connect.microsoft.com/IE/feedbackdetail/view/1002846/pathname-incorrect-for-out-of-document-elements
Cheers,
_dave_
- Sam Ruby
