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

Encoding API exceptions

From: Anne van Kesteren <annevk@annevk.nl>
Date: Sun, 9 Nov 2014 10:45:28 +0100
Message-ID: <CADnb78h=hxoJaKpTw2G1Yd+dAOdGyJaNQ15o0DaNrGchqsFHyg@mail.gmail.com>
To: "www-international@w3.org" <www-international@w3.org>
Cc: Joshua Bell <jsbell@google.com>, Masatoshi Kimura <VYV03354@nifty.ne.jp>, Boris Zbarsky <bzbarsky@mit.edu>, Domenic Denicola <d@domenic.me>, Allen Wirfs-Brock <allenwb@mozilla.com>
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 Sunday, 9 November 2014 09:45:54 UTC

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