W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: ByteString in Web IDL

From: Robin Berjon <robin@w3.org>
Date: Wed, 10 Jul 2013 11:41:53 +0200
Message-ID: <51DD2C61.2040006@w3.org>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>, public-script-coord@w3.org
On 10/07/2013 06:45 , Boris Zbarsky 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.
> 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.

I can't seem to find a strong trace of this, but I was under the 
impression that at some point we'd agreed that all legacy features in 
WebIDL should be prefixed with "legacy" (as in legacycaller). It's not a 
bad idea, I think people would definitely hesitate to plaster their new 
APIs with LegacyByteString.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 10 July 2013 09:42:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:17 UTC