- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 28 Jul 2013 16:08:04 -0700
- 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 UnicodeString or anything similar would. / Jonas
Received on Sunday, 28 July 2013 23:09:02 UTC