- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 28 Jul 2013 16:38:14 -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 4:33 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > 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. [EnsureUTF16] is a modifier within the value space, no? It makes the function throw if specific values are provided, but it doesn't mean that new values can be expressed. Just like [EnforceRange] does. And yes, I think ByteString could, and probably should, be done as an extended attribute. / Jonas
Received on Sunday, 28 July 2013 23:39:15 UTC