Re: [url] Feedback from TPAC

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