Re: Changes to DOM3 Events Key Identifiers

Hi Doug,

--Original Message--:
>Hi, Alex-
>
>Alex Danilo wrote (on 10/30/09 4:05 AM):
>>
>> --Original Message--:
>>>
>>>As editor of the DOM3 Events specification, I made what some may
>>>consider to be drastic changes in the most recent drafts:
>>>   * I changed the syntax of the key identifier strings from "U+xxxx" (a
>>>plain string representing the Unicode code point) to "\uxxxx" (an
>>>escaped UTF-16 character string), based on content author and
>>>implementer feedback.
>>
>> I think this is a terrible change.
>>
>> Predominantly for SVG Tiny 1.2 user agents that want to support
>> DOM3 as well.
>>
>> In Tiny devices memory footprint is critical and this just introduces
>> an entire extra set of strings that will bloat the binary for no
>> added functionality.
>
>Why not simply store the Unicode code point, and compose it with "U+" or 
>"\u" on the fly?

Because the other key identifiers are not mapped to Unicode
code points. For example F1, F2, etc. have no Unicode representation.

On a Windows system for example, the mappings of key codes to
the representational strings are most logically placed at the
site of the event handing from a Windows key event.

It's at that point that you decide to map 'U+' or '\u' or 'F1', etc.
So it's completely contained at the operating system specific
level. That doesn't require the DOM tree or the scripting
interface to know anything about the underlying source of
the key event code.

The mapping point architecturally could move, but the
most logical place to put it is in the code that deals with
OS level events.

Yes you could compose on the fly - but now you introduce an
additional level of detection in the scripting interface to
push the key code to string mapping up from the OS specific
layers into the scripting interface.

Also, I see the '\u' string as problematic in a historical/cross
language form.

The use of '\' as anything is _bad_. I hate to dredge it up, but
the single most stupid design decision in MS-DOS was to
choose '\' as a path separator vs. CP/M of the day and UNIX
that all used '/'.

To this day, C++ programmers the world over have to write
all this special case code to include '\\' for Windows, and
'/' for UNIX and it's a mess.

Using '\u' in the string for Javascript ignores other languages
we may want to bind to the DOM. So in some of them '\'
is the escape character and so you need to type '\\' instead.

>From an implementation point of view, anything can be supported
but there is one guiding principle that is a nice one - don't repeat
yourself.

Our aim with the multi-namespace model is to unify everything.
This seems like fragmentation.

If an author wants to handle an event in an SVG/HTML document
do they author with "U+xxxx" or "\uxxxx"? It's confusing, and of no
visible benefit.

If there's a JSON reason to make this change, then let's hear the
reasons but at the moment I can only see downsides in both
implementation time/complexity and author confusion in a
compound document environment as well as the added pain
for programmers dealing with backslash hell:-)

(And before the Apple fanbois get cocky about \ vs. / and we
told you so, the Mac OS 9 (and earlier) decision to make
'\n' emit a '\r' into the file and subvert C newline conventions
is just as bad:)

>> The "\uxxxx" syntax is just reminiscent of a programming language
>> but has little to do with strings returned from DOM APIs. I suppose
>> you could argue that it's useful in some situations, but my concern
>> is more about the existence of 2 things that mean the same
>> thing.
>>
>> i.e. in a CDF document, the script has to deal with "U+xxxx" or
>> "\uxxx" dependent on which namespace the element is living
>> in.   I know that you can use 'keyIdentifier' and 'keyValue' to
>> distinguish them, however that pushes the detection logic
>> to the wrong place.
>
>How so?  If the author gets SVGT1.2's ".keyIdentifier" attribute, the 
>code point is prepended with "U+", and with ".key", it's prepended with 
>"\u".  Am I missing some point of optimization?

Well, I'd personally avoid '\' in any form of string identifier
returned from anything since historically it's been used
as a special escape. In C/C++ you use \x or similar where
it has special meaning, but there's no \u, where the returned string
from keyIdentifier is a descriptive string, not an escape mechanism.
There is a distinction.

>FWIW, we heard feedback from BitFlash that authors did not like the "U+" 
>syntax, and I believe they may have made some concession to convenience 
>in their implementation (though I don't know the details).

That's the problem with users, they get upset about their own
needs without realizing the implications of such a 'simple' change.

It would be nice if someone could actually point to why '\uxxx' is
better than 'U+xxx' from a technical perspective.

Avoiding the use of '\' as I said above is far more important.

Oh, and making sure there's a lack of redundancy that just
creates author confusion.

>>>   * I renamed the "key identifier(s)" feature to "key value(s)".
>>
>> That is a nice change - and does reflect what the semantics
>> are. It's also a minimal implementation burden to support both
>> keyIdentifier and keyValue.
>
>Actually, the name of the attribute on the Key interface has been 
>changed to ".key", which is simpler, if less descriptive.

Sounds good. That's of minor consequence compared to my concerns
above.

But anyway, as implementors we will willingly build what is asked for,
however, in the presence of existing mechanisms to handle the
identifiers it's hard to justify adding another way to do the same
thing and then bring on the possibility that some user agents
will support only one or both of the alternatives forcing a least
common denominator authoring approach for interoperable
content...

Cheers,
Alex

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

Received on Friday, 30 October 2009 09:34:33 UTC