- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Sun, 28 Jul 2013 16:33:08 -0700
- 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. -- http://annevankesteren.nl/
Received on Sunday, 28 July 2013 23:33:39 UTC