[whatwg] New URL Standard

[Alexandre Morgaut]

On 24 sept. 2012, at 11:34, Anne van Kesteren wrote:

>> 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
>
> I have been thinking about introducing a .query attribute that would
> return a special interface for this purpose, but what the right API
> should be seems somewhat tricky. Adam and Erik came up with a solution
> that introduces eight new methods (see
> http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html#url ) but I hope
> we can find something more elegant. (Unless we are stuck with their
> solution for some reason, but I believe that is not the case.)

Yes I saw the methods, and as for XHR and its headers, I don't find them user friendly enough
The "search" property could stand as is, but I personally think that having a Web Storage like key/value mapping for the parameters would make the code more readable.
We could then have a "params" or "parameters" property with key / value mapping and implementing the Storage interface:
http://www.w3.org/TR/webstorage/#storage-0
Developers who are more comfortable with methods would then still be happy, and because of having the same interface, the learning curve would be better.

What I would love in the enhancement of parameters management, is that the developer should not need to take care about URL encoding of the names and values any more.... all those encoding/decoding could be done automatically, either with your proposed methods or using a Storage interface...


>> Should this document include a more complete list of schemes with ones that are more and more used in URLs?
>
> Maybe, kinda depends on what turns out to be the ideal scope for the
> URL Standard. For now I only wanted to include those schemes relevant
> to the parser (and it may turn out there is a few more of those, e.g.
> mailto, javascript, data, and file might need some special casing).

Going progressively makes sense

>> 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
>
> We might not want to adapt it either because of the relative increase
> in complexity while not actually addressing many use cases. You want
> to modify query/path for http/https and maybe ws/wss a lot, but not so
> much for mailto I'd think.

I started my purpose saying "Unfortunately...", but in the end, it looks like the Location/URL interface, in combination with the Storage interface should fit with any of the mentioned schemes. The only specificity being the format of the "tel:" parameters (it'd be great if we could update the RFC). I must say I'm more comfortable with the matching of this URL interface with "mailto:", "tel:", "sms:", and "tv:" than with "data:" or "javascript:"

Bellow some potential examples for those schemes using the URL and the Storage interfaces (without showing the methods)


mailto:joe at example.com?cc=bob at example.com&subject=current-issue&body=send%20current-issue%0D%0Asend%20index

{
        host: "joe at example.com",
        hostname: "joe at example.com",
        href: "joe at example.com?cc=bob at example.com&subject=current-issue&body=send%20current-issue%0D%0Asend%20index",
        parameters: {
                cc: "bob at example.com",
                subject: "current-issue",
                body: "send current-issue\r\nsend index"
        }
        pathname: "",
        port: "",
        protocol: "mailto:",
        search: "?cc=bob at example.com&body=hello",
}


tel:+11231231234;isub=8978

{
        host: "+11231231234",
        hostname: "+11231231234",
        href: "+11231231234;isub=8978",
        parameters: {
                isub: "8978"
        }
        pathname: "",
        port: "",
        protocol: "tel:",
        search: ""
}


sms:+15105550101?body=hello%20there

{
        host: "+15105550101",
        hostname: "+15105550101",
        href: "+15105550101?body=hello%20there",
        parameters: {
                body: "hello there"
        }
        pathname: "",
        port: "",
        protocol: "sms:",
        search: ""
}


tv:west.hbo.com

{
        host: "west.hbo.com",
        hostname: "west.hbo.com",
        href: "west.hbo.com",
        parameters: {}
        pathname: "",
        port: "",
        protocol: "tv:",
        search: ""
}


data:image/png;base64; ........

{
        host: "",
        hostname: "",
        href: "image/png;base64; ........",
        parameters: {} // might include auto-generated mediaType & charset string parameters and base64 boolean parameter
        pathname: "",
        port: "",
        protocol: "data:",
        search: ""
}







Alexandre Morgaut
Wakanda Community Manager

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

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