On Sat, Jan 11, 2014 at 5:27 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> 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.

If you follow the link for "throw", you'll find it's a DOMException.


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

Sure, that's easily mapped though. (The whole EnsureUTF16 thing is in
need of fixing in IDL.)


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

Agreed. I don't really have the bandwidth at the moment to work on
this though. I have fixed the examples:

https://github.com/whatwg/encoding/commit/da5d1426a4e7ff7c7fea6724957b2c70df09bce4


-- 
http://annevankesteren.nl/

On Sat, Jan 11, 2014 at 5:27 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 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.

If you follow the link for "throw", you'll find it's a DOMException.


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

Sure, that's easily mapped though. (The whole EnsureUTF16 thing is in
need of fixing in IDL.)


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

Agreed. I don't really have the bandwidth at the moment to work on
this though. I have fixed the examples:

https://github.com/whatwg/encoding/commit/da5d1426a4e7ff7c7fea6724957b2c70df09bce4