W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2012

Re: IDL: special DOMString that converts to Unicode

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 30 Oct 2012 12:16:47 +0100
Message-ID: <CA+c2ei_bEdahkyc92uuJu95zGiQO5Z2PFCBcS0iizY1c+TGjig@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Brendan Eich <brendan@mozilla.org>, Simon Pieters <simonp@opera.com>, Robin Berjon <robin@w3.org>, public-script-coord@w3.org
On Tue, Oct 30, 2012 at 10:01 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Oct 29, 2012 at 6:20 PM, Brendan Eich <brendan@mozilla.org> wrote:
>> In general, interface != implementation. Possibly these interfaces really
>> are implementation-specific, but suppose I want to implement XHR's
>> interfaces in JS and pass them off to a testsuite. Would the JS
>> implementation have to validate? Should it?
> No UTFString means the same as DOMString except that lone surrogates
> get replaced with U+FFFD. There's no exception throwing related to it.
> I would classify this as an effect at the binding level as either the
> string stays a sequence of code units or it gets converted to a
> sequence of code points.
> I agree that we should not use UTFString for cases where
> http://encoding.spec.whatwg.org/ is not involved and Web IDL should
> probably indicate something to that effect. We could name it
> "CodePointString" maybe so people are more likely to pick the shorter
> variant (as they should), but in the end implementors should review
> specifications as well before they implement them and if they use
> UTFString/CodePointString incorrectly it should be fixed at that
> point.

An alternative is to express this as an extended attribute rather than a type.

/ Jonas
Received on Tuesday, 30 October 2012 11:17:39 UTC

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