Re: [whatwg] New URL Standard

Thanks Anne, I'd appreciate to be able to easily get a URLUtil interface from a string UTL without doing some nasty hacks

I have a ew questions

Would the URLUtil interface replace the "URL decomposition IDL attributes" of the Location interface?
        -> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#url-decomposition-idl-attributes
        -> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-location-interface

Could the search property have a "query" and/or "params" (see "tel:" and "fax:" bellow) alias?

Could the search property have a key/value mapping?
ex:
http://test.com?param1=value1
-> var value1 = url.search.param1
"search" as "window.location" could still be usable as a string


Shouldn't this document have references on some of the URL related RFCs:

- Uniform Resource Locators (URL)
        -> http://tools.ietf.org/html/rfc1738

- The "data" URL scheme
        -> http://tools.ietf.org/html/rfc2397

- Uniform Resource Identifier (URI): Generic Syntax
        -> http://tools.ietf.org/html/rfc3986

Should this document include a more complete list of schemes with ones that are more and more used in URLs?
ex:
- "mailto:"
        -> https://tools.ietf.org/html/rfc2368
        -> https://tools.ietf.org/html/rfc6068
- "tel:", "fax:"
        -> https://tools.ietf.org/html/rfc2806
        -> https://tools.ietf.org/html/rfc3966
- "sms:"
        -> http://tools.ietf.org/html/rfc5724
- tv:
        -> http://tools.ietf.org/html/rfc2838
Unfortunately, the URLUtil interface would not be adapted for them:
- the "protocol", "host", and "hostname" properties make sense and would work;
- the query part (search property) is used by the "mailto:" and "sms:" URIs;
- for "tel:" and "fax", we see "parameters" prefixed by ";" as the ones used in some media types, those parameters could be found in the search property


PS:
Note that the fax: scheme could be supported in a form or via XHR to send PDF documents, postcript document, HTML documents with their potential CSS print...
But that would be another discussion

On 21 sept. 2012, at 17:16, Anne van Kesteren wrote:

> I took a crack at defining URLs: http://url.spec.whatwg.org/
>
> At the moment it defines parsing (minus domain names / IP addresses)
> and the JavaScript API (minus the query manipulation methods proposed
> by Adam Barth). It defines things like setting .pathname to "hello
> world" (notice the space), it defines what happens if you resolve
> "http:test" against a data URL (you get "http://test/") or
> http://teehee (you get "http://teehee/test"). It is based on the
> various URL code paths found in WebKit and Gecko and supports the \ as
> / in various places because it seemed better for compatibility.
>
> I'm looking for some feedback/ideas on how to handle various aspects, e.g.:
>
> * data URLs; in Gecko these appear to be parsed as part of the URL
> layer, because they can turn a URL invalid. Other browsers do not do
> this. Opinions? Should data URLs support .search?
> * In the current text only a select few URLs support host/port/query.
> The rest is solely path/fragment. But maybe we want mailto to support
> query? Should it support host? (mailto supporting e.g. host would also
> mean normalising host via IDNA toASCII and friends. Not sure I'm fond
> of that.)
> * Advice on file URLs would be nice.
> * IDNA: what are your plans? IDNA2003 / IDNA2008 / UTS #46 / something
> else? It would be nice to get agreement on this.
> * Terminology: should we align the terminology with the API or would
> that just be too confusing?
>
> Thanks!
>
>
> PS: It also does the query encoding thing correctly for the first time
> ever in the history of URL standards although the wording can probably
> be improved.
>
>
> --
> http://annevankesteren.nl/





Alexandre Morgaut
Wakanda Community Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :    Alexandre.Morgaut@4d.com
Web :      www.4D.com

Received on Saturday, 22 September 2012 07:10:54 UTC