Re: Interoperability vs file: URLs
On Thu, Dec 4, 2014 at 7:50 AM, Sam Ruby wrote: > On 12/02/2014 02:22 AM, Jonas Sicking wrote: >> To be clear, I'm proposing to remove any and all normative definition >> of file:// handling from the spec. Because I don't think there is >> interoperability, nor do I think that it's particularly high priority >> to archive it. > > > A bug has been file on your behalf: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=27518 > > In response, I suggest that your proposal is a bit too extreme, and I > suggest dialing it back a bit. That sounds ok to me. / Jonas
Re: Interoperability vs file: URLs
On 12/02/2014 02:22 AM, Jonas Sicking wrote: On Mon, Dec 1, 2014 at 7:58 PM, Sam Ruby wrote: On 12/01/2014 10:22 PM, Jonas Sicking wrote: On Mon, Dec 1, 2014 at 7:11 PM, Domenic Denicola 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 from file:// or even link to a file:// HTML page using . 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. To be clear, I'm proposing to remove any and all normative definition of file:// handling from the spec. Because I don't think there is interoperability, nor do I think that it's particularly high priority to archive it. A bug has been file on your behalf: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27518 In response, I suggest that your proposal is a bit too extreme, and I suggest dialing it back a bit. / Jonas - Sam Ruby
Re: Interoperability vs file: URLs (was: URL Spec WorkMode)
On Mon, Dec 1, 2014 at 7:58 PM, Sam Ruby wrote: > On 12/01/2014 10:22 PM, Jonas Sicking wrote: >> >> On Mon, Dec 1, 2014 at 7:11 PM, Domenic Denicola 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 >> from file:// or even link to a file:// HTML page using > 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. To be clear, I'm proposing to remove any and all normative definition of file:// handling from the spec. Because I don't think there is interoperability, nor do I think that it's particularly high priority to archive it. / Jonas
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 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 from file:// or even link to a file:// HTML page using . 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 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
