W3C home > Mailing lists > Public > public-indie-ui@w3.org > November 2012

Re: IndieUI Event Interfaces

From: James Craig <jcraig@apple.com>
Date: Mon, 05 Nov 2012 07:43:36 -0800
Cc: public-indie-ui <public-indie-ui@w3.org>
Message-id: <EE1203A8-55BB-48D9-95BD-5C2E2AD68990@apple.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>

On Nov 5, 2012, at 7:24 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:

> On 2012-11-05 15:31, James Craig wrote:
>> Unless I hear objections, I am going to remove the IDL descriptions
>> altogether b/c Iím not sure they add much value.
> If you do this, will you then define that the events defined here implement the UIEvent interface?

Besides the implementation details, why does is matter? Is the concern here that without them, authors would not be able to determine programmatically through object detection whether or not the UA supports the interface and these events? 

>> I had considered the entirely lowercase event names, but AFAIK, not
>> all events are defined this way. Iíll look for some other examples,
>> but unless I find some good reasons, Iíll make the switch to
>> lowercase.
> It seems all the events whose names are prefixed with "DOM" (e.g. DOMActivate, DOMFocusIn, and the mutation events) are camel case.  So it seems the convention is broken at least in those cases.  The common ones like mouseover, keypress, etc. are all lowercase.

One more thing to consider is that text-to-speech engines typically do better with unknown, compound words written in camel-case. That said, unless we can make them case-insensitive, all lowercase would likely lead to less author error. I could take a hybrid approach and list them as real words in the spec for the sake of TTS pronunciations, but also list the event key as a lowercased compound word. 

For example:
Undo Request (undorequest)
Received on Monday, 5 November 2012 15:44:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:13:18 UTC