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 16:33:08 -0700
Message-ID: <CADnb78i77HsCwQO4=6wNPFzNi6Xurg1jGBEtjAXgDnnXdjkbbw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
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 4:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

It is not defined as such at the moment. I sorta expected extended
attributes to be modifiers within the value space always and not
represent another type underneath that's translated back and forth at
the boundaries. If we want it to that too, we should probably also
change ByteString into an extended attribute, but it seems somewhat
weird design-wise to me.

Received on Sunday, 28 July 2013 23:33:39 UTC

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