Interoperability vs file: URLs (was: URL Spec WorkMode)

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