5 ms·

Also to note: Firefox can now upload directories. Granted, it's done by mimicking Webkit APIs, but that has the advantage that existing sites work without chan

Also to note: Firefox can now upload directories. Granted, it's done by mimicking Webkit APIs, but that has the advantage that existing sites work without changes.

Nadya 10y ago
I was confused by what this meant - so perhaps some others are too. This is what a few minutes of research got me: Uploading individual files in a directory = was possible Uploading an entire directory (eg: a folder to a cloud storage service) = was not possible Personally my workflow means I've uploaded the contents of a directory to a directory I make myself, so I've never encountered the problem. Am I missing something or was that right? Example of error: http://superuser.com/questions/909112/does-firefox-support-folder-upload http://superuser.com/questions/909112/does-firefox-support-f...
- pitaj 10y ago
  You can't upload subdirectories, so it quickly becomes painful to upload an entire directory of files if it has multiple folders within.
  - Nadya 10y ago
    Outside of my personal use cases but I can definitely see how many, if not even most, people would need that at some point. :) Thanks for the response!
    - nicky0 10y ago
      Another reason is on macOS where many file formats are actually directory based. (Called 'packages', they are actually structured directories with a metadata bit set.) For example the RTFD format. This is a rich text document with embedded images. It is actually implemented as a folder containing a RTF file and the images. In the Mac GUI however it appears to be a regular file. Attempting to upload it on the web would fail without the ability to upload directories. This may well explain why WebKit (being from Apple) was the first to implement this. I bet they needed it for their iCloud web app versions of Pages, Keynote etc.
Manishearth 10y ago
> Granted, it's done by mimicking Webkit APIs, That's ... not a bad thing. Chrome creating nonstandard APIs (IIRC this was for Drive?) on its own is a bad thing. Coming together and speccing (https://wicg.github.io/directory-upload/proposal.html https://wicg.github.io/directory-upload/proposal.html) the API is a good thing. They seem to have specced more or less what Webkit had already implemented (plus some promise based stuff), but usually when a nonstandard API has been out there long enough it's best to build your standardized version on top of it instead of having two APIs for it. This is a common practice. This isn't "mimicking".
- kuschku 10y ago
  > They seem to have specced more or less what Webkit had already implemented The problem is that the WHATWG always just standardizes "whatever Chrome does". This leads to the HTML living standard actually being just like Office Open XML, with one entity controlling all of it.
  - Navarr 10y ago
    I would postulate that the cause of this is that, as a provider of services, Google kind of knows what's difficult to do in a browser and what apis are needed to make it more native-like. So it's not a terribly bad thing, unless other people's standards are just being ignored
    - hobarrera 10y ago
      > So it's not a terribly bad thing, unless other people's standards are just being ignored. It's actually an unfair advantage. "Oh, let's standardize what Chrome already has implemented and Google is using". This immediately sets Firefox behind the new "standard", and website that don't work on FF technically "follow current standards".
    - Manishearth 10y ago
      Actually, no. Google is bound to have its own favorite frameworks (perhaps even in house), its own coding style, and in general its own way of doing things. Most large companies do. Google would end up creating APIs that are most suitable for their use cases and their frameworks. These need not be the best APIs for all.

Also to note: Firefox can now upload directories. Granted, it's done by mimicking Webkit APIs, but that has the advantage that existing sites work without changes.

Nadya 10y ago

I was confused by what this meant - so perhaps some others are too. This is what a few minutes of research got me: Uploading individual files in a directory = was possible Uploading an entire directory (eg: a folder to a cloud storage service) = was not possible Personally my workflow means I've uploaded the contents of a directory to a directory I make myself, so I've never encountered the problem. Am I missing something or was that right? Example of error: http://superuser.com/questions/909112/does-firefox-support-folder-upload http://superuser.com/questions/909112/does-firefox-support-f...

pitaj 10y ago
You can't upload subdirectories, so it quickly becomes painful to upload an entire directory of files if it has multiple folders within.
- Nadya 10y ago
  Outside of my personal use cases but I can definitely see how many, if not even most, people would need that at some point. :) Thanks for the response!
  - nicky0 10y ago
    Another reason is on macOS where many file formats are actually directory based. (Called 'packages', they are actually structured directories with a metadata bit set.) For example the RTFD format. This is a rich text document with embedded images. It is actually implemented as a folder containing a RTF file and the images. In the Mac GUI however it appears to be a regular file. Attempting to upload it on the web would fail without the ability to upload directories. This may well explain why WebKit (being from Apple) was the first to implement this. I bet they needed it for their iCloud web app versions of Pages, Keynote etc.

Manishearth 10y ago

> Granted, it's done by mimicking Webkit APIs, That's ... not a bad thing. Chrome creating nonstandard APIs (IIRC this was for Drive?) on its own is a bad thing. Coming together and speccing (https://wicg.github.io/directory-upload/proposal.html https://wicg.github.io/directory-upload/proposal.html) the API is a good thing. They seem to have specced more or less what Webkit had already implemented (plus some promise based stuff), but usually when a nonstandard API has been out there long enough it's best to build your standardized version on top of it instead of having two APIs for it. This is a common practice. This isn't "mimicking".

kuschku 10y ago
> They seem to have specced more or less what Webkit had already implemented The problem is that the WHATWG always just standardizes "whatever Chrome does". This leads to the HTML living standard actually being just like Office Open XML, with one entity controlling all of it.
- Navarr 10y ago
  I would postulate that the cause of this is that, as a provider of services, Google kind of knows what's difficult to do in a browser and what apis are needed to make it more native-like. So it's not a terribly bad thing, unless other people's standards are just being ignored
  - hobarrera 10y ago
    > So it's not a terribly bad thing, unless other people's standards are just being ignored. It's actually an unfair advantage. "Oh, let's standardize what Chrome already has implemented and Google is using". This immediately sets Firefox behind the new "standard", and website that don't work on FF technically "follow current standards".
  - Manishearth 10y ago
    Actually, no. Google is bound to have its own favorite frameworks (perhaps even in house), its own coding style, and in general its own way of doing things. Most large companies do. Google would end up creating APIs that are most suitable for their use cases and their frameworks. These need not be the best APIs for all.