The problem is that then you're exposing platform endianness.

If I understand correctly, a browser is not expected to convert ArrayBufferView to a binary frame in the network byte order or to transform into some platform independent structure. So there is no difference between ArrayBuffer and ArrayBufferView from the viewpoint of endian. I think major benefits to use ArrayBufferView is that we can send a part of ArrayBuffer without any extra copy. It is because subarray() can create a object which refer a part of the buffer with start and end offset information.

I could not find authoritative information how TypedArray handle endian. At least, DataView has interfaces which required explicit endian indication and its default behavior is big endian. But, in my environment TypedArray works as little endian. I guess TypedArray depends on platform endian type, but it's good for use cases of TypedArray.

(In reply to comment #0)
> negative reason is just for compatibility.
> But, sometimes JavaScript has an ArrayBuffer object without any
> ArrayBufferView.
> E.g., obviously JavaScript has only ArrayBuffer object which are received via
> WebSocket API.
> I think the old interface send(ArrayBuffer data) is worth to be held.

If it's genuinely needed for web compatibility, that's fine.

But if it's not, then it should be removed.  It's cheap and trivial to create an Int8Array view around the ArrayBuffer: "xhr.send(new Int8Array(array))".  It's not worth adding an ArrayBuffer overload to every API that accepts typed arrays, just to avoid 15 bytes of typing (especially for something that's being typed rather infrequently).

(In reply to comment #1)
> The problem is that then you're exposing platform endianness.

You can treat sending an ArrayBuffer as equivalent to creating an Int8Array and sending that.  The typed array spec has major bugs around endianness, but I don't think this would add to them.

I don't understand how sending an ArrayBuffer rather than an ArrayBufferView exposes endianness. Can you elaborate? The way I specced it, they should be exactly identical, since all the spec does is send the ArrayBuffer that the ArrayBufferView references (suitably cropped)...

As I mentioned at the WebApps F2F, Microsoft intends to continue supporting ArrayBuffer for these scenarios. It is too late in our cycle to change this now and we have content already created that relies on supporting ArrayBuffer. We're okay with the change to also support ArrayBufferView - that makes good sense.

Not sure if my response is still wanted, but I'll defer to Glenn and note that we did remove it from other APIs such as XMLHttpRequest. We should have a somewhat consistent story.

We haven't (and won't) removed it from any APIs in IE. It was too late a change for us to consider and we have people building on these APIs. It doesn't seem harmful to allow both.

It's harmful just because it's extra API surface area.

We, WebKit, couldn't remove it for now.
If Ian removed it from the spec, we will try to abandon it.
But, we will remove it after statistics shows it being obsolete enough.

WebKit project's consensus would be summarized as:
- We don't drop ArrayBuffer support immediately. We will show users a console warning to encourage migration.
- We will probably keep the ArrayBuffer support until its usage is proven to be reasonably low according to our usage metrics.

Yuta, I think it's premature to say that the WebKit project has consensus that we'll be able to drop using ArrayBuffers here (or in the other places we've added ArrayBufferView).

We have a significant enough amount of content using ArrayBuffer that it will be difficult for us to remove it and so not really worth the compatibility cost.

The ideal solution would be for ArrayBuffer and ArrayBufferView to share a base class, so there'd be no distinction for functions like this, and people wouldn't need to create a view over the whole buffer for functions that don't care about data types.  (Ideally, ArrayBuffer would simply implement Uint8Array.)

Unfortunately, the TypedArray Constructor(TypedArray array) and Constructor(ArrayBuffer buffer, ...) constructors get in the way of this, since unfortunately those functions do subtly but significantly different things (the former allocates new storage, the latter creates a view).  It's hard to fix this now without breakage: the TypedArray ctors should never allocate, and a deep copy should require a separate function call.

I mention this only in case somebody has any ideas for correcting this that I haven't thought of.  Maybe I'm overestimating the impact of changing TypedArray(TypedArray) to creating a shallow view (maybe this is rare in practice?), but I suspect not.

I've put this back since multiple browser vendors said they were going to implement it anyway. I recommend making sure that XHR implementations are following the XHR spec or else changing the XHR spec back as well.