Allen Wirfs-Brock (2014-01-11T17:27:07.000Z)
On Jan 11, 2014, at 6:13 AM, Anne van Kesteren wrote:

> On Fri, Jan 10, 2014 at 7:00 PM, Allen Wirfs-Brock
> <allen at wirfs-brock.com> wrote:
>> [...] it might be reasonable to have a solution that isn't tied to a specific environment.
> 
> Agreed. I have argued the same for URL parsing
> http://url.spec.whatwg.org/ at some point.
> 
> As for the API in the Encoding Standard, I think the only strong tie
> to the DOM at this point is its usage of DOMException. I have a few
> times on this list tried to figure out what the right way forward is
> for exceptions within the web platform so that they still fit well
> within the ES universe, but none of those led anywhere satisfactory
> yet.
> 

I don't see any occurrences of DomException in http://encoding.spec.whatwg.org/ 

It seems to be throwing TypeError for parameter validation issues which is what a TC39 spec. would generally do, except that for a few of those cases we might throw a RangeError instead.

There are a couple places where a string such as "EncodingError" is thrown.  We'd never do that and would use either TypeError or RangeError.

The major Web platform dependency I see is the use of DOMString and associated attributes such as [EnsureUTF16].  Those shouldn't be there for a host environment independent spec.

Finally, it seems likely that the subclassing contract for TextEncoder/TextDecoder haven't been thought through and I notice that the examples instantiate instances of them without using the new operator.

But overall, it shouldn't be hard to fix these things and make it completely independent of the web platform.  It could drop quite nicely into the new TC39 process model it you wanted to go that route of standardization.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140111/14890f71/attachment.html>
domenic at domenicdenicola.com (2014-01-17T04:42:44.025Z)
On Jan 11, 2014, at 6:13 AM, Anne van Kesteren wrote:

> As for the API in the Encoding Standard, I think the only strong tie
> to the DOM at this point is its usage of DOMException. I have a few
> times on this list tried to figure out what the right way forward is
> for exceptions within the web platform so that they still fit well
> within the ES universe, but none of those led anywhere satisfactory
> yet.

I don't see any occurrences of DomException in http://encoding.spec.whatwg.org/ 

It seems to be throwing TypeError for parameter validation issues which is what a TC39 spec. would generally do, except that for a few of those cases we might throw a RangeError instead.

There are a couple places where a string such as "EncodingError" is thrown.  We'd never do that and would use either TypeError or RangeError.

The major Web platform dependency I see is the use of DOMString and associated attributes such as [EnsureUTF16].  Those shouldn't be there for a host environment independent spec.

Finally, it seems likely that the subclassing contract for TextEncoder/TextDecoder haven't been thought through and I notice that the examples instantiate instances of them without using the new operator.

But overall, it shouldn't be hard to fix these things and make it completely independent of the web platform.  It could drop quite nicely into the new TC39 process model it you wanted to go that route of standardization.