W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: Updates to File API

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 20 May 2010 15:41:57 -0700
Message-ID: <AANLkTilbpjqgmXz5ic1QZ3y5UrSoxVrw30po4r1ZlOPn@mail.gmail.com>
To: nathan@webr3.org
Cc: arun@mozilla.com, Robin Berjon <robin@berjon.com>, Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
On Thu, May 20, 2010 at 2:53 PM, Nathan <nathan@webr3.org> wrote:
> Jonas Sicking wrote:
>>
>> On Wed, May 19, 2010 at 1:09 PM, Arun Ranganathan <arun@mozilla.com>
>> wrote:
>>>>>
>>>>> 3. The renaming of the property to 'url' also suggests that we should
>>>>> cease to consider an urn:uuid scheme.
>>>>>
>>>> I'm not sure that one follows from the other. The property's called
>>>> 'url'
>>>> because that's what will be familiar to authors, but the magic string
>>>> that
>>>> goes inside of it could still be a URN.
>
> FWIW, I'm a developer and sticking a URN in a .url property really doesn't
> seem familiar at all - even a '.id' property with an id that was
> consistently generated would be much better.
>
> If the scope of the identifiers is limited to a single ua, on a single
> machine, and specific to that single ua (as in I can't expect to request the
> identifier outside of the ua that provided it on x machine and get the same
> results) then I (personally) can't see why there's a need for anything more
> than a simple unique identifier (sha1 or suchlike)
>
> And if the above is true, then surely this would negate the need for .url,
> registering a new URI scheme, or URN namespace - and all in save you all
> from lots of headaches & time wasted, close the issue, and save the
> developer community from years of further confusion (or should i say
> conflated understanding of what a URL is), and benefit the entire web by
> saving us from yet another (predominantly unneeded) URN namespace or URL
> scheme.

Note that the important point of these URNs isn't that they are
identifiers, but rather that you can point a <iframe>.src, or a
<img>.src, or a #myElement { background-url: url(...) } at them. In
all useful use cases brought up so far, the website author will never
look at the actual string to see what it contains, but rather just
treat it as a url and load data from it.

The intended use for it is things like:

<img id=preview>
<input type=file onchange="document.getElementById('preview').src =
this.files[0].url">

In this context, calling the string an "identifier" misses the point IMHO.

(btw, the above example should work fine in nightly firefox builds)

/ Jonas
Received on Thursday, 20 May 2010 22:42:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT