- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 25 Nov 2014 17:18:39 -0500
- To: David Walp <David.Walp@microsoft.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
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 > <rubys@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_ >
Received on Tuesday, 25 November 2014 22:19:07 UTC