Re: [FileAPI] Remove readAsBinaryString?

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
<aranganathan@mozilla.com>wrote:

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