> 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) 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".

> 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.

> WHATWG always just standardizes "whatever Chrome does".

It really ... doesn't. When the situation has arisen that Chrome has implemented an API for long enough for it to become entrenched in the web, it then discusses standardizing it (see also: https://compat.spec.whatwg.org/). But it's not blindly following Chrome, it's only in these special cases.

I've recently been involved in a couple of issues where browsers disagree with each other and/or the spec. Each time there's a discussion, and the best version of the behavior is chosen and worked into the spec. This best version is not always the Chrome version.

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

> 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".

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.

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-f...

You can't upload subdirectories, so it quickly becomes painful to upload an entire directory of files if it has multiple folders within.

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!

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.