W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: convertKeyIdentifier

From: Doug Schepers <schepers@w3.org>
Date: Tue, 22 Sep 2009 11:55:07 -0400
Message-ID: <4AB8F35B.8000908@w3.org>
To: "www-dom@w3.org" <www-dom@w3.org>
Hi, Anne-

Anne van Kesteren wrote (on 9/22/09 11:34 AM):
> On Tue, 22 Sep 2009 17:10:27 +0200, Doug Schepers <schepers@w3.org> wrote:
>> Anne van Kesteren wrote (on 9/22/09 10:51 AM):
>>> On Tue, 22 Sep 2009 16:48:19 +0200, Travis Leithead
>>> <travil@microsoft.com> wrote:
>>>>> [*]Unicode (to provide easy access to the Unicode string?)
>>>> Scratch that last one--just noticed
>>>> DocumentEvent::convertKeyIdentifier...
>>> Should we really have such a method on document though? And what is the
>>> reason for using U+.... in the first place. Can't we just always return
>>> the Unicode scalar value?
>> The Unicode scalar value is the "U+xxxx" format (the code point).
> No it is not:
> http://unicode.org/glossary/#unicode_scalar_value

Yes, this is the range of hex integers, not the character.  I may have 
misunderstood what you were asking... I thought you were asking for the 
attribute to just return the character (e.g. 'q'), as opposed to the 
code point (e.g. 0071, representing in the attribute as the string 
'U+0071')... Maciej and I had a recent conversation about returning the 
most author-friendly representation (e.g. 'q'), and I assumed you were 
on agreement with that.  My mistake.

> (You also seem to misunderstand code point if you think it is about its
> common string representation.)

No, I was just using the key identifier representation of the code point 
as an illustration.  (It's possible I do misunderstand code points in 
some deeper way, but I hope not.)

>> You might have meant the character value. We have already decided that
>> the character value (if it exists) will be the attribute value.
> So we will not have strings in the form of "U+xxxx" anymore?

Please read the spec.

>> There are potential use cases for getting each of the different
>> formats (for example, for Unicode code points, making sure that a
>> character is in a certain range, or presenting an advanced virtual
>> keyboard, or signaling non-printing diacritics).
> That functionality seems to apply to charcter handling everywhere and is
> not at all specific to event handling so I think it would be
> inappropriate for the events specification.

You may misunderstand what the DocumentEvent interface is for.  It's 
intended to extend the Document interface with methods and attributes 
that are applicable to features defined in the events specification, 
even if they don't directly deal with events.  It deals directly with 
key identifiers and the key identifiers set (for example, there are also 
named values, not just various representations of the Unicode code 
points), so it's not just general character handling.  I don't want to 
cripple authors because of misgivings about architectural purity... this 
is a directly related to DOM3 Events key identifiers, and it needs to be 
implemented in that context.  Mozilla and Microsoft have already agreed 
that we need this, BTW.

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Tuesday, 22 September 2009 15:55:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:15 UTC