W3C home > Mailing lists > Public > www-international@w3.org > October to December 2014

Re: Encoding API exceptions

From: Joshua Bell <jsbell@google.com>
Date: Mon, 10 Nov 2014 09:41:22 -0800
Message-ID: <CAD649j7x2cQiNLQzsf5n0e5nWHhh30HwahFfGALoYiCOknouSA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "www-international@w3.org" <www-international@w3.org>, Masatoshi Kimura <VYV03354@nifty.ne.jp>, Boris Zbarsky <bzbarsky@mit.edu>, Domenic Denicola <d@domenic.me>, Allen Wirfs-Brock <allenwb@mozilla.com>
I'd be willing to experiment with changing the exception types in Chromium.
History tells us this sort of change is usually web-compatible, and the
feature still has pretty low usage numbers at this point.

It'd be nice to have more confidence about starting to use RangeError in
web platform features; IIRC an early iteration of the Encoding API design
did use RangeError but we moved away from it! Is there a new spec/feature
that can test the waters first?

On Sun, Nov 9, 2014 at 1:45 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Both Chromium and Gecko implement the API. There's interest in this
> API from the wider JavaScript community. Unfortunately for them we use
> a DOMException which so far is the only dependency on "DOM things".
>
> We also use a TypeError based on IDL enumerations, but reportedly IDL
> should attempt switching to RangeError there as that is what
> JavaScript itself uses in such situations. (We cannot use IDL
> enumerations in the Encoding API because we also trim whitespace and
> use ASCII case-insensitve matching.)
>
> I was wondering if there would be interest in changing both Chromium
> and Gecko to throw TypeError where we now throw EncodingError, and
> throw RangeError where we now throw TypeError. My hope is that this
> would make the API more attractive as JavaScript's Encoding API (to
> the extent it isn't that already).
>
> The Encoding API: https://encoding.spec.whatwg.org/#api
>
>
> --
> https://annevankesteren.nl/
>
Received on Monday, 10 November 2014 17:41:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:38 UTC