W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] [URL] Starting work on a URL spec

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 25 Jul 2010 23:01:57 -0700
Message-ID: <D246D502-D4D0-4A48-82E8-E28A75EF4DBD@apple.com>

On Jul 25, 2010, at 6:43 AM, Boris Zbarsky wrote:

> On 7/25/10 8:57 AM, Adam Barth wrote:
>>> There's also the related question of what browsers should do with input typed into the URL field. Other than establishing that these rules may be different between the URL field and URLs present in content, I'm not sure this is amenable to spec. But perhaps a survey of what browsers do would be useful.
>> 
>> I wasn't planning to cover that because it's not a critical to
>> interoperability
> 
> Unfortunately, it is.  In particular, servers need to know what to
> expect the browser to send if a user types non-ASCII into the url bar.
> There are real interoperability problems out there due to differing
> server and browser behavior in this regard.
> 
> It may not be an _html_ interoperability problem, but it's certainly a
> _web_ interoperability problem.
> 
>> There are also other
>> considerations there because the URLs are displayed to users as
>> security indicators.
> 
> What's displayed is not a concern, in my opinion, in terms of
> interoperability.  What's put on the wire is.  The constraints that need
> to be imposed are much looser than on <a href> (e.g. we don't need to
> define exactly what url gets loaded if the user types "monkey" in the
> url bar), but sorting out the non-ASCII issue is definitely desirable.

One thing to keep in mind is that browsers do all sorts of non-interoperable things for input that is not a valid URL, such as guessing that it is a hostname or performing a search with a search engine. So there's a limit to how much this can be spec'd. I agree that for certain URL-like strings that a user may type or cut & paste, there is an interop issue.

Regards,
Maciej
Received on Sunday, 25 July 2010 23:01:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC