W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2014

Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 1 Dec 2014 19:22:49 -0800
Message-ID: <CA+c2ei9mvc99j5wkKJUFgybOyXxm1_ZwMzYCDh3Coje3Hh4eow@mail.gmail.com>
To: Domenic Denicola <d@domenic.me>
Cc: Sam Ruby <rubys@intertwingly.net>, Webapps WG <public-webapps@w3.org>
On Mon, Dec 1, 2014 at 7:11 PM, Domenic Denicola <d@domenic.me> wrote:
> What we really need to do is get some popular library or website to take a
> dependency on mobile Chrome or mobile Safari's file URL parsing. *Then* we'd
> get interoperability, and quite quickly I'd imagine.

To my knowledge, all browsers explicitly block websites from having
any interactions with file:// URLs. I.e. they don't allow loading an
<img> from file:// or even link to a file:// HTML page using <a
href="file://...">. Even though both those are generally allowed cross

So it's very difficult for webpages to depend on the behavior of
file:// parsing, even if they were to intentionally try.

/ Jonas

> ________________________________
> From: Jonas Sicking
> Sent: 2014-12-01 22:07
> To: Sam Ruby
> Cc: Webapps WG
> Subject: Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)
> Just in case I haven't formally said this elsewhere:
> My personal feeling is that it's probably better to stay away from
> speccing the behavior of file:// URLs.
> There's very little incentive for browsers to align on how to handle
> file:// handling. The complexities of different file system behaviors
> on different platforms and different file system backends makes doing
> comprehensive regression testing painful. And the value is pretty low
> because there's almost no browser content that uses absolute file://
> URLs.
> I'm not sure if non-browser URL consuming software has different
> incentives. Most software that loads resources from the local file
> system use file paths, rather than file:// URLs. Though I'm sure there
> are exceptions.
> And it seems like file:// URLs add a significant chunk of complexity
> to the spec. Complexity which might be for naught if implementations
> don't implement them.
> / Jonas
> On Mon, Dec 1, 2014 at 5:17 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> On 11/18/2014 03:18 PM, Sam Ruby wrote:
>>> Meanwhile, I'm working to integrate the following first into the WHATWG
>>> version of the spec, and then through the WebApps process:
>>> http://intertwingly.net/projects/pegurl/url.html
>> Integration is proceeding, current results can be seen here:
>> https://specs.webplatform.org/url/webspecs/develop/
>> It is no longer clear to me what "through the WebApps process" means. In
>> an
>> attempt to help define such, I'm making a proposal:
>> https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface
>> At this point, I'm looking for general feedback.  I'm particularly
>> interested in things I may have missed.  Pull requests welcome!
>> Once discussion dies down, I'll try go get agreement between the URL
>> editors, the WebApps co-chairs and W3C Legal.  If/when that is complete,
>> this will go to W3C Management and whatever the WHATWG equivalent would
>> be.
>> - Sam Ruby
Received on Tuesday, 2 December 2014 03:23:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:32 UTC