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

Re: IDL: special DOMString that converts to Unicode

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 28 Jul 2013 16:08:04 -0700
Message-ID: <CA+c2ei_UD90r9K-8xrVHG6J74h-nx5z7vQC148tbCpNXnRymZA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Cameron McCormack <cam@mcc.id.au>, Brendan Eich <brendan@mozilla.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Simon Pieters <simonp@opera.com>, Robin Berjon <robin@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Sun, Jul 28, 2013 at 12:27 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 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.

Why does an extended attribute not provide this? It seems like an
implementation detail if

[EnsureUTF16] DOMString

hands the backing implementation a string in UTF8, UTF16, UTF32 or
something else. I.e. there is no requirement that the WebIDL
implementation hands the backing code something that is the same
format as a DOMString. All that the above requires is that the backing
code is handed something that can be converted to unicode without
decoding errors.

So it seems like it provides the same guarantees and flexibility as
something like


or anything similar would.

/ Jonas
Received on Sunday, 28 July 2013 23:09:02 UTC

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