W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [FileAPI] Remove readAsBinaryString?

From: Ojan Vafai <ojan@chromium.org>
Date: Sun, 18 Dec 2011 19:42:37 +0000
Message-ID: <CANMdWTt8wEFSBggT7GOmkhzsvSW8dZ5N7a85Tmi+GwkG5yp8Xg@mail.gmail.com>
To: Arun Ranganathan <aranganathan@mozilla.com>
Cc: Adrian Bateman <adrianba@microsoft.com>, Feras Moussa <ferasm@microsoft.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
What's the point of having deprecated features in a spec? If the purpose of
a specification is to get interoperability, then a UA either does or
doesn't need to implement the feature. There's no point in keeping a
feature that we think should be killed and there's no point in removing a
feature that can't be killed because too much web content relies on it.

DOM4 does mark some things as "historical", but DOM4's use of "historical"
is different than deprecating it in a subtle but important way. The
historical bits in DOM4 will still need to be implemented by all UAs, but
the features they correspond to won't (e.g. enums for node types that we're
killing are kept).

On Fri, Dec 16, 2011 at 8:42 AM, Arun Ranganathan

> I'm happy to remove this from the specification.  Right now this is marked
> as deprecated, which I suppose isn't strong enough discouragement?  :)
> ----- Original Message -----
> > Another topic that came up at TPAC was readAsBinaryString [1]. This
> > method
> > predates support for typed arrays in the FileAPI and allows binary
> > data
> > to be read and stored in a string. This is an inefficient way to store
> > data now that we have ArrayBuffer and we'd like to not support this
> > method.
> >
> > At TPAC I proposed that we remove readAsBinaryString from the spec and
> > there was some support for this idea. I'd like to propose that we
> > change
> > the spec to remove this.
> >
> > Thanks,
> >
> > Adrian.
> >
> > [1] http://dev.w3.org/2006/webapi/FileAPI/#readAsBinaryString
Received on Sunday, 18 December 2011 19:43:25 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC