"keyIdentifier" Sucks

[Doug Schepers-3]

Hi, DOM3 Events folks-

I think key identifiers are a pretty good mechanism that will definitely
improve the authoring experience.

However... having typed "keyIdentifier" more times than I care to
remember in the course of editing this spec, I can state with some
measure of confidence that it's a terrible name.

* It is long
* It is camelCased
* The word "identifier" (and its connotations of uniqueness) gives the
immediate impression that it somehow uniquely identifies a key, that
each key has a set value, and that there is only one key identifier per
key.... none of which is correct.  This makes it harder for people to
understand than if it had some other name (like... monkeybuffalo or
something).

I am reluctant to change it because the term has been around for so long
in earlier drafts of this spec, and because of existing implementations,
but I really think authors would benefit from a shorter, more aptly
descriptive name.

I know, I know, this is bikeshedding... but this is also our best chance
to get this right, before it is widely deployed in implementations and
content.

Here are some counter-proposals, in roughly descending order of my
preference:
1) keyname (I'd need to come up with some other term for what I'm
calling a "key name" in the spec, but that's fine)
2) keystring
3) keyvalue
4) keyaddress
5) keyid (I don't like this one for a number of reasons)
6) keypeek (joke)

Is this a quixotic notion by someone who is too deep into the
specification, or do other people think this is a reasonable topic for
discussion?  Either way, I'm happy to entertain other names (which would
cover both the ".keyIdentifier" attribute and the "Key Identifiers Set"
label).

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Sean Hogan]

Doug Schepers wrote:

>
> Here are some counter-proposals, in roughly descending order of my
> preference:
> 1) keyname (I'd need to come up with some other term for what I'm
> calling a "key name" in the spec, but that's fine)
> 2) keystring
> 3) keyvalue
> 4) keyaddress
> 5) keyid (I don't like this one for a number of reasons)
> 6) keypeek (joke)
>

The XBL spec uses "key" for event filtering. Seems okay to me.

[Doug Schepers-3]

Hi, Sean-

Sean Hogan wrote (on 9/22/09 12:13 AM):

>
> Doug Schepers wrote:
>>
>> Here are some counter-proposals, in roughly descending order of my
>> preference:
>> 1) keyname (I'd need to come up with some other term for what I'm
>> calling a "key name" in the spec, but that's fine)
>> 2) keystring
>> 3) keyvalue
>> 4) keyaddress
>> 5) keyid (I don't like this one for a number of reasons)
>> 6) keypeek (joke)
>>
> The XBL spec uses "key" for event filtering. Seems okay to me.

Too general.  When you're describing the feature, you need a more
specific hook.  Just saying "key" doesn't distinguish it from a physical
key, keyCode/charCode, a VK, or even a scancode.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Travis Leithead-3]

> From: www-dom-request@... [mailto:www-dom-request@...] On Behalf Of Doug Schepers
>
> Sean Hogan wrote (on 9/22/09 12:13 AM):
> >
> > Doug Schepers wrote:
> >>
> >> Here are some counter-proposals, in roughly descending order of my
> >> preference:
> >> 1) keyname (I'd need to come up with some other term for what I'm
> >> calling a "key name" in the spec, but that's fine)
> >> 2) keystring
> >> 3) keyvalue
> >> 4) keyaddress
> >> 5) keyid (I don't like this one for a number of reasons)
> >> 6) keypeek (joke)
> >>
> > The XBL spec uses "key" for event filtering. Seems okay to me.
>
> Too general.  When you're describing the feature, you need a more specific
> hook.  Just saying "key" doesn't distinguish it from a physical key,
> keyCode/charCode, a VK, or even a scancode.

A few more choices to consider...

keyresult
keychar
keyinput
keytext
charvalue
[*]Unicode (to provide easy access to the Unicode string?)

[Travis Leithead-3]

> From: Travis Leithead
> > From: www-dom-request@... [mailto:www-dom-request@...]
> On Behalf
> > Of Doug Schepers
> >
> > Sean Hogan wrote (on 9/22/09 12:13 AM):
> > >
> > > Doug Schepers wrote:
> > >>
> > >> Here are some counter-proposals, in roughly descending order of my
> > >> preference:
> > >> 1) keyname (I'd need to come up with some other term for what I'm
> > >> calling a "key name" in the spec, but that's fine)
> > >> 2) keystring
> > >> 3) keyvalue
> > >> 4) keyaddress
> > >> 5) keyid (I don't like this one for a number of reasons)
> > >> 6) keypeek (joke)
> > >>
> > > The XBL spec uses "key" for event filtering. Seems okay to me.
> >
> > Too general.  When you're describing the feature, you need a more
> > specific hook.  Just saying "key" doesn't distinguish it from a
> > physical key, keyCode/charCode, a VK, or even a scancode.
>
> A few more choices to consider...
>
> keyresult
> keychar
> keyinput
> keytext
> charvalue
> [*]Unicode (to provide easy access to the Unicode string?)

Scratch that last one--just noticed DocumentEvent::convertKeyIdentifier...

-Travis

[Anne van Kesteren-2]

On Tue, 22 Sep 2009 16:48:19 +0200, Travis Leithead <travil@...>  
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?


--
Anne van Kesteren
http://annevankesteren.nl/

[Olli Pettay]

On 9/22/09 7:00 AM, Doug Schepers wrote:

> Hi, DOM3 Events folks-
>
> I think key identifiers are a pretty good mechanism that will definitely
> improve the authoring experience.
>
> However... having typed "keyIdentifier" more times than I care to
> remember in the course of editing this spec, I can state with some
> measure of confidence that it's a terrible name.
>
> * It is long
> * It is camelCased
> * The word "identifier" (and its connotations of uniqueness) gives the
> immediate impression that it somehow uniquely identifies a key, that
> each key has a set value, and that there is only one key identifier per
> key.... none of which is correct. This makes it harder for people to
> understand than if it had some other name (like... monkeybuffalo or
> something).
>
> I am reluctant to change it because the term has been around for so long
> in earlier drafts of this spec, and because of existing implementations,
> but I really think authors would benefit from a shorter, more aptly
> descriptive name.
>
> I know, I know, this is bikeshedding... but this is also our best chance
> to get this right, before it is widely deployed in implementations and
> content.
>
> Here are some counter-proposals, in roughly descending order of my
> preference:
> 1) keyname (I'd need to come up with some other term for what I'm
> calling a "key name" in the spec, but that's fine)

I'd prefer camelCased, because many other attribute are camelCased too.
So perhaps keyName or what about just name?


> 2) keystring
> 3) keyvalue
For some reason, these don't sound good :)


> 4) keyaddress
This doesn't feel right. This would be closer to the native keyboard
layout key location, or something.


> 5) keyid (I don't like this one for a number of reasons)
And the reasons are?
I was almost going to suggest having just id.

There could be id and location, or
keyId and keyLocation.

or s/id/name/


-Olli

> 6) keypeek (joke)
>
> Is this a quixotic notion by someone who is too deep into the
> specification, or do other people think this is a reasonable topic for
> discussion? Either way, I'm happy to entertain other names (which would
> cover both the ".keyIdentifier" attribute and the "Key Identifiers Set"
> label).
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>
>

[Doug Schepers-3]

Hi, Anne-

Please change the subject line if you change the subject...

Anne van Kesteren wrote (on 9/22/09 10:51 AM):

> On Tue, 22 Sep 2009 16:48:19 +0200, Travis Leithead
> <travil@...> 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).  You
might have meant the character value.  We have already decided that the
character value (if it exists) will be the attribute value.

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).

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Anne van Kesteren-2]

On Tue, 22 Sep 2009 17:10:27 +0200, Doug Schepers <schepers@...> wrote:
> Please change the subject line if you change the subject...

I thought both items were in scope for the subject. Sorry.

> Anne van Kesteren wrote (on 9/22/09 10:51 AM):
>> On Tue, 22 Sep 2009 16:48:19 +0200, Travis Leithead
>> <travil@...> 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

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


> 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?


> 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.


--
Anne van Kesteren
http://annevankesteren.nl/

[Doug Schepers-3]

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@...> wrote:
>
>> Anne van Kesteren wrote (on 9/22/09 10:51 AM):
>>> On Tue, 22 Sep 2009 16:48:19 +0200, Travis Leithead
>>> <travil@...> 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.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Anne van Kesteren-2]

On Tue, 22 Sep 2009 17:55:07 +0200, Doug Schepers <schepers@...> wrote:
>>> 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.

I did. I don't understand why "U+xxxx" is still there so I was wondering  
if that was temporary.


>> 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 would be nice if you simply assumed that I did and went on from there.


> 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.

This is new then since you took over editing. Before that it only dealt  
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...

I don't understand why we cannot have a single list and rather need to  
have various identifiers for everything.


> 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.

Well, I disagree. I do not see the point in having this method as I do not  
see the need for having multiple representations for everything in the  
first place in the context of DOM Level 3 Events.

Furthermore I think putting createEvent on Document was a mistake in to  
begin with. Especially with the design we have now where DOM events are  
often used outside the context of documents. (Think of e.g. Web Workers.)


--
Anne van Kesteren
http://annevankesteren.nl/

[Doug Schepers-3]

Hi, Anne-

Anne van Kesteren wrote (on 9/22/09 12:27 PM):

> On Tue, 22 Sep 2009 17:55:07 +0200, Doug Schepers <schepers@...> wrote:
>>>> 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.
>
> I did. I don't understand why "U+xxxx" is still there so I was wondering
> if that was temporary.

The spec has everything that's at risk marked as such.  As I said in
previous messages, I've just reworked the key identifiers section
substantially, so if it were at risk, I would have marked it that way,
or mentioned it on the list.


>>> 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 would be nice if you simply assumed that I did and went on from there.

I didn't mean disrespect by that.  I didn't understand before I talked
with PLH (the previous editor) about this particular matter, and it was
his suggestion to put it in DocumentEvent interface instead of waiting
to put it in a new DOM Core spec (as I originally intended).


>> 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.
>
> This is new then since you took over editing. Before that it only dealt
> with events.

Not so.  It may appear that way, but that was never the intent.


>> 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...
>
> I don't understand why we cannot have a single list and rather need to
> have various identifiers for everything.

Because there are different uses for the different values, and the open
Web platform currently doesn't have any way to deal with that.  This
happens to be a convenient place to do that, especially in the context
of the complexity of key events and i18n.

>> 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.
>
> Well, I disagree. I do not see the point in having this method as I do
> not see the need for having multiple representations for everything in
> the first place in the context of DOM Level 3 Events.
>
> Furthermore I think putting createEvent on Document was a mistake in to
> begin with. Especially with the design we have now where DOM events are
> often used outside the context of documents. (Think of e.g. Web Workers.)

Noted.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Anne van Kesteren-2]

On Tue, 22 Sep 2009 18:51:17 +0200, Doug Schepers <schepers@...> wrote:

> Anne van Kesteren wrote (on 9/22/09 12:27 PM):
>>> 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...
>>
>> I don't understand why we cannot have a single list and rather need to
>> have various identifiers for everything.
>
> Because there are different uses for the different values, and the open  
> Web platform currently doesn't have any way to deal with that.  This  
> happens to be a convenient place to do that, especially in the context  
> of the complexity of key events and i18n.

What are these different uses? As I understand the current specification  
keyIdentifier will only return the first value so what is the use for the  
other values?

>>> 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.
>>
>> Well, I disagree. I do not see the point in having this method as I do
>> not see the need for having multiple representations for everything in
>> the first place in the context of DOM Level 3 Events.
>>
>> Furthermore I think putting createEvent on Document was a mistake in to
>> begin with. Especially with the design we have now where DOM events are
>> often used outside the context of documents. (Think of e.g. Web  
>> Workers.)
>
> Noted.

Where?


--
Anne van Kesteren
http://annevankesteren.nl/

[Doug Schepers-3]

Hi, Anne-

Anne van Kesteren wrote (on 9/22/09 12:56 PM):

> On Tue, 22 Sep 2009 18:51:17 +0200, Doug Schepers <schepers@...> wrote:
>> Anne van Kesteren wrote (on 9/22/09 12:27 PM):
>>>> 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...
>>>
>>> I don't understand why we cannot have a single list and rather need to
>>> have various identifiers for everything.
>>
>> Because there are different uses for the different values, and the
>> open Web platform currently doesn't have any way to deal with that.
>> This happens to be a convenient place to do that, especially in the
>> context of the complexity of key events and i18n.
>
> What are these different uses? As I understand the current specification
> keyIdentifier will only return the first value so what is the use for
> the other values?

Please refer to my earlier email in this thread.

>>>> 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.
>>>
>>> Well, I disagree. I do not see the point in having this method as I do
>>> not see the need for having multiple representations for everything in
>>> the first place in the context of DOM Level 3 Events.
>>>
>>> Furthermore I think putting createEvent on Document was a mistake in to
>>> begin with. Especially with the design we have now where DOM events are
>>> often used outside the context of documents. (Think of e.g. Web
>>> Workers.)
>>
>> Noted.
>
> Where?

In the definition of convertKeyIdentifier() in the spec, where I track
most issues.

I also have some issues noted in the wiki (mostly resolved, now), and I
use Tracker for protracted issues.  When we go to LC, I'll have to be
more strict about using Tracker.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Cameron McCormack-4]

Anne van Kesteren:
> Furthermore I think putting createEvent on Document was a mistake in
> to begin with. Especially with the design we have now where DOM
> events are often used outside the context of documents. (Think of
> e.g. Web Workers.)

I guess you’re saying it should really be WindowEvent rather than
DocumentEvent.  Then it would make sense to have

  WorkerUtils implements WindowEvent;

in Web Workers.  (Well, we could do that now, but it would be strange to
have createEvent() on Document in regular windows but on the global
object in workers.)


Maybe we should also have:

  [Constructor]
  interface UIEvent : Event {
    // …
  };

etc.

--
Cameron McCormack ≝ http://mcc.id.au/

[Maciej Stachowiak]

On Sep 22, 2009, at 7:43 AM, Travis Leithead wrote:

>> From: www-dom-request@... [mailto:www-dom-request@...] On  
>> Behalf Of Doug Schepers
>>
>> Sean Hogan wrote (on 9/22/09 12:13 AM):
>>>
>>> Doug Schepers wrote:
>>>>
>>>> Here are some counter-proposals, in roughly descending order of my
>>>> preference:
>>>> 1) keyname (I'd need to come up with some other term for what I'm
>>>> calling a "key name" in the spec, but that's fine)
>>>> 2) keystring
>>>> 3) keyvalue
>>>> 4) keyaddress
>>>> 5) keyid (I don't like this one for a number of reasons)
>>>> 6) keypeek (joke)
>>>>
>>> The XBL spec uses "key" for event filtering. Seems okay to me.
>>
>> Too general.  When you're describing the feature, you need a more  
>> specific
>> hook.  Just saying "key" doesn't distinguish it from a physical key,
>> keyCode/charCode, a VK, or even a scancode.
>
> A few more choices to consider...
>
> keyresult
> keychar
> keyinput
> keytext
> charvalue
> [*]Unicode (to provide easy access to the Unicode string?)

These should all use mixedCase to be consistent with DOM naming style.  
Personally, I think "key" is the best name out of these. The attribute  
tells you what key was pressed. Code like this:

if (evt.key == "Q") {
     // ...
} else if (evt.key == "Enter") {
    // ...
}

seems very natural to me.

Regards,
MAciej

[Maciej Stachowiak]

On Sep 22, 2009, at 8:10 AM, Doug Schepers wrote:

> Hi, Anne-
>
> Please change the subject line if you change the subject...
>
> Anne van Kesteren wrote (on 9/22/09 10:51 AM):
>> On Tue, 22 Sep 2009 16:48:19 +0200, Travis Leithead
>> <travil@...> 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).  
> You might have meant the character value.  We have already decided  
> that the character value (if it exists) will be the attribute value.
>
> 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).

If you get a string of the character, you can very easily get the  
unicode value of the character as a number in almost any reasonable  
programming language. It's actually harder to parse out of the U+xxxx  
format. The conversion is only useful if there are keys with a U+xxxx  
equivalent where the name is not just that very unicode character.

Regards,
Maciej

[Maciej Stachowiak]

On Sep 22, 2009, at 9:27 AM, Anne van Kesteren wrote:

>
>
>> 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.
>
> Well, I disagree. I do not see the point in having this method as I  
> do not see the need for having multiple representations for  
> everything in the first place in the context of DOM Level 3 Events.
>
> Furthermore I think putting createEvent on Document was a mistake in  
> to begin with. Especially with the design we have now where DOM  
> events are often used outside the context of documents. (Think of  
> e.g. Web Workers.)

I agree with Anne. I think we should remove the U+XXXX format  
entirely. If you have a string like Q, you can convert it to a unicode  
numeric value for range checking like this:

var codePoint = evt.keyIdentifier.charCodeAt(0);

This seems easier than this as a way to get a numeric unicode code  
point:
parseInt(document.convertKeyIdentifier(evt.keyIdentifier).substring(2))

Also, you can range check the actual string, so it's rare to need the  
code point at all:
if (evt.keyIdentifier >= "A" && evt.keyIdentifier <= "Z")

I don't think the U+XXXX string format does not add any value.

Regards,
Maciej

[Ian Hickson]

On Tue, 22 Sep 2009, Maciej Stachowiak wrote:
> On Sep 22, 2009, at 9:27 AM, Anne van Kesteren wrote:
>
> I agree with Anne. I think we should remove the U+XXXX format entirely.
> If you have a string like Q, you can convert it to a unicode numeric
> value for range checking like this: [...]
>
> I don't think the U+XXXX string format does not add any value.

Are dead keys represented in some way? The string "\x0308" is not a valid
Unicode string (it has a combining character with no base), but I don't
see how else we would represent the diaeresis dead key.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Maciej Stachowiak]

On Sep 22, 2009, at 7:53 PM, Ian Hickson wrote:

> On Tue, 22 Sep 2009, Maciej Stachowiak wrote:
>> On Sep 22, 2009, at 9:27 AM, Anne van Kesteren wrote:
>>
>> I agree with Anne. I think we should remove the U+XXXX format  
>> entirely.
>> If you have a string like Q, you can convert it to a unicode numeric
>> value for range checking like this: [...]
>>
>> I don't think the U+XXXX string format does not add any value.
>
> Are dead keys represented in some way? The string "\x0308" is not a  
> valid
> Unicode string (it has a combining character with no base), but I  
> don't
> see how else we would represent the diaeresis dead key.

I hadn't thought of dead keys. According to the spec, the key  
identifier for the diaeresis dead key is the string "DeadUmlaut". I  
can see a few possible ways to deal with this:

1) Have a way to get the unicode code point for a dead key. But I  
think a numeric value would be more useful than the U+XXXX format  
string.
     1.a) This could be a global method that takes strings like  
"DeadUmlaut" and returns code points as numeric values ; OR
     1.b) There could be an attribute on key events that gives the  
code point, if any, separate from the key identifier. long  
unicodeCodePoint for instance.

2) Alternately - even though "\x0308" is not a valid Unicode string,  
it can still be represented as a DOM string and as a JavaScript  
string, since both the DOM and JavaScript define strings as sequences  
of 16-bit UTf-16 code units, and may represent invalid strings  
(including even such things as containing only one code unit of the  
two that comprise a surrogate pair). Thus, identifiers like  
"DeadUmlaut" could be replaced with ones like "\x0308".

Regards,
Maciej