- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 10 Jul 2013 01:01:15 -0400
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, Jul 10, 2013 at 12:45 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 7/10/13 12:35 AM, Norbert Lindenberg wrote: >> >> So there's a new fundamentally broken type in a specification that's the >> foundation for all Web APIs, just to make it easier to describe a few >> semi-broken legacy APIs elsewhere > > To make it _possible_ to describe them, not to make it easier. This is not true. It would be possible to describe behavior in prose too. > There's a lot of stuff in WebIDL that's there only or mostly to be able to > describe legacy APIs. named/indexed getters/setters, bytestring, some of > the weirdness in how single-operation callback interfaces behave, > legacycaller, [LenientThis], [ImplicitThis], [NamedConstructor], > [TreatNonCallableAsNull], [TreatNullAs], [TreatUndefinedAs], and probably > others that I missed. > > I agree that it should be more clearly marked which parts are there for that > reason, of course. Indeed. Many of these end up getting used in new specs because they are readily available in WebIDL :( Going through these would also bring up a healthy debate about what patterns in legacy APIs are bad ideas to keep using in new APIs. I personally think that 'stringifier' is something that should be marked as legacy and a bad idea to keep using for example. / Jonas
Received on Wednesday, 10 July 2013 05:02:12 UTC