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.
Thanks! Looking forward to it!
Can I ask that you either open an issue or a bug (it matters not which
to me) on each of these items.
https://github.com/webspecs/url/issues
https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG&component=URL
Feel free to link back to your original post on this topic in the
issue/bug reports:
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0505.html
I also actively encourage pull requests, so if you care to propose a
change, I encourage you to do so.
Finally, I've expanded that list since October. Here's a few more
topics that you might want to weigh in on:
http://intertwingly.net/projects/pegurl/url.html#discuss
And by all means, don't stop there!
- Sam Ruby
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.
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.
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.
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.
Cheers, _dave_
