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

Re: IDL: special DOMString that converts to Unicode

From: Anne van Kesteren <annevk@annevk.nl>
Date: Sun, 28 Jul 2013 12:27:09 -0700
Message-ID: <CADnb78hcNUS6D7Qt=HxbeDs4+XMYF4bUMAf+nxW0Jhhw3s8P8Q@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: Brendan Eich <brendan@mozilla.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Jonas Sicking <jonas@sicking.cc>, Simon Pieters <simonp@opera.com>, Robin Berjon <robin@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Tue, Jul 23, 2013 at 1:41 AM, Cameron McCormack <cam@mcc.id.au> wrote:
> I've added the [EnsureUTF16] extended attribute now.
> http://dev.w3.org/2006/webapi/WebIDL/#EnsureUTF16
> http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.646;r2=1.647;f=h

So actually an attribute does not work. Either this needs to be a type
or we should just go back to using the algorithm we have in IDL.

There are various places in the platform that assume Unicode scalar
values as input (e.g. the URL parser, encodings). This extended
attribute does not give them that, it still hands them code units. So
I think our options are:

1. Have a new type that does this.
2. Invoke this algorithm in a number of places.

1 would make things easier specification-wise and helps you understand
more of the API by just looking at the IDL, but I no longer consider 2

Received on Sunday, 28 July 2013 19:27:36 UTC

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