- From: Sam Ruby <rubys@intertwingly.net>
- Date: Mon, 01 Dec 2014 22:58:55 -0500
- To: Jonas Sicking <jonas@sicking.cc>, Domenic Denicola <d@domenic.me>
- CC: Webapps WG <public-webapps@w3.org>
On 12/01/2014 10:22 PM, Jonas Sicking wrote: > 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 > origin. > > So it's very difficult for webpages to depend on the behavior of > file:// parsing, even if they were to intentionally try. Relevant related reading, look at the description that the current URL Living Standard provides for the origin for file: URLs: https://url.spec.whatwg.org/#origin I tend to agree with Jonas. Ideally the spec would match existing browser behavior. When that's not possible, getting agreements from browser vendors on the direction would suffice. When neither exist, a more accurate description (such as the one cited above in the Origin part of the URL Standard) is appropriate. > / Jo - Sam Ruby P.S. Bug reports and/or a github issue opened on this topic would be appreciated. A pull request would be even better. >> ________________________________ >> 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:59:50 UTC