tag:old.nabble.com,2006:forum-11684
Nabble - w3.org - dom
2009-12-02T11:02:18Z
w3c Document Object Model (DOM). w3.org - dom home is <a href="http://www.w3.org/DOM/" target="_top" rel="nofollow">here</a>.
tag:old.nabble.com,2006:post-26614435
Re: A few strawman proposals: Query Key State, Selector-based Mutation Events Replacement
2009-12-02T11:02:18Z
2009-12-02T11:02:18Z
Doug Schepers-3
Hi, Travis-
<br><br>How about we write these up as Editor's Drafts, to get more precise
<br>feedback, and consider adding them to the next charter?
<br><br><br>Travis Leithead wrote (on 11/30/09 7:22 PM):
<br>> I’ve been meaning to do this for awhile, but over the extended holidays
<br>> I finally had the chance. I’ve quietly added a few strawman proposals
<br>> for next-generation events specs to consider:
<br>>
<br>> · Query Key Status – method for getting key state outside of the
<br>> eventing model
<br><br>Yup, seems logical. Obviously needs fleshing out.
<br><br><br>> · Selector-based Mutation Events – follow-up proposal to Jonas’ concept
<br>> earlier this year (or last year??)
<br>>
<br>> <a href="http://www.w3.org/2008/webapps/wiki/DOM3Events#Proposals" target="_top" rel="nofollow">http://www.w3.org/2008/webapps/wiki/DOM3Events#Proposals</a><br>>
<br>> Comments welcome—I have quite a few issues to resolve, but now I’ve at
<br>> least got the proposals out in a public place for inspection :-)
<br><br>My high-level feedback is that both would benefit from a more explicit
<br>requirements list, perhaps explaining some of the shortcomings of
<br>Mutation Events for that one.
<br><br>* watchSelector's SelectorElementCallback should be a list... there may
<br>be a DOM mutation that simultaneously fits the match criteria (e.g.,
<br>inserting or removing large fragments)
<br>* Combine both methods into one?
<br>* notifyOnMatch is confusingly named... and could be a third value, "both"
<br>* make some ARIA examples (might help test fulfillment of use cases)
<br><br>Regards-
<br>-Doug Schepers
<br>W3C Team Contact, SVG and WebApps WGs
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26584602
A few strawman proposals: Query Key State, Selector-based Mutation Events Replacement
2009-11-30T16:22:23Z
2009-11-30T16:22:23Z
Travis Leithead-3
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>I’ve been meaning to do this for awhile, but over the extended holidays I finally had the chance. I’ve quietly added a few strawman proposals for next-generation events specs to consider:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l62 level1 lfo1'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]>Query Key Status – method for getting key state outside of the eventing model<o:p></o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l62 level1 lfo1'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]>Selector-based Mutation Events – follow-up proposal to Jonas’ concept earlier this year (or last year??)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><a href="http://www.w3.org/2008/webapps/wiki/DOM3Events#Proposals" target="_top" rel="nofollow">http://www.w3.org/2008/webapps/wiki/DOM3Events#Proposals</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Comments welcome—I have quite a few issues to resolve, but now I’ve at least got the proposals out in a public place for inspection :-)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Travis<o:p></o:p></p></div></body></html><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26573476
Re: [whatwg] createEvent() in Web Workers?
2009-11-30T03:52:04Z
2009-11-30T03:52:04Z
Simon Pieters-3
On Fri, 27 Nov 2009 17:02:00 +0100, Simon Pieters <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26573476&i=0" target="_top" rel="nofollow">simonp@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> An idea for creating events is to support [Constructor] on all event
<br>> IDLs, which makes the createEvent method unnecessary.
<br>>
<br>> Maybe we could even make the arguments to the constructor be called to
<br>> initFooEvent() directly, so instead of doing
<br>>
<br>> var e = document.createEvent('MouseEvents');
<br>> e.initMouseEvent('click', ...);
<br>> foo.dispatchEvent(e);
<br>>
<br>> you could do
<br>>
<br>> foo.dispatchEvent(new MouseEvent('click', ...))
<br>>
<br>>
<br>> I've cc-ed www-dom since this is a suggestion for a change to DOM Events.
</div><br>Another thing we could change is to make all but the first arguments to
<br>initFooEvent() optional and let them have sensible defaults, so that if
<br>all you care about is the event type, you can include just the first
<br>argument.
<br><br>If the constructor is called with no arguments, then initFooEvent() would
<br>not be called.
<br><br>--
<br>Simon Pieters
<br>Opera Software
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26548693
Re: [whatwg] createEvent() in Web Workers?
2009-11-27T09:23:23Z
2009-11-27T09:23:23Z
Jonathan Cook-2
<div class='shrinkable-quote'>> An idea for creating events is to support [Constructor] on all event
<br>> IDLs, which makes the createEvent method unnecessary.
<br>>
<br>> Maybe we could even make the arguments to the constructor be called to
<br>> initFooEvent() directly, so instead of doing
<br>>
<br>> var e = document.createEvent('MouseEvents');
<br>> e.initMouseEvent('click', ...);
<br>> foo.dispatchEvent(e);
<br>>
<br>> you could do
<br>>
<br>> foo.dispatchEvent(new MouseEvent('click', ...))
<br>>
<br>>
<br>> I've cc-ed www-dom since this is a suggestion for a change to DOM Events.
<br>>
</div>I think that allowing creation of events via constructor is a good
<br>idea. It is simple in a way that doesn't detract from usefulness. I
<br>don't think it's a good idea to diverge far from how events are done in
<br>the DOM for non-DOM uses. That means that the DOM specs should lead the
<br>way in terms of providing for how events work for browsers, available
<br>objects like Web Workers, server-side javascript and anything else you
<br>can think of.
<br><br>The DOM Level 3 Events spec is specifying interface DocumentEvent that
<br>document should implement, corresponding to feature "Events". It would
<br>be nice if the DOM Level 3 DocumentEvent and Event interfaces were
<br>super-classes of something also available for other implementations.
<br>WorkerGlobalScope could implement this non-DOM eventing interface and
<br>whatever constructors make sense to be available for Worker events
<br>(ErrorEvent is the one that is already specified, as well as the
<br>messaging ones). Another example of an object that does eventing but
<br>isn't DOM is the XmlHttpRequest object.
<br><br>Regards,
<br>J5
<br><br><br><br><br>I'm the type of person who "thinks out loud" and as such even in an
<br>email conversation I can get long-winded and lengthily end up somewhere
<br>that I later realize is much quicker to arrive at by direct means. I
<br>don't know whether the protocol of this list is that I ramble or that I
<br>be as direct as possible and do thinking "off-list". I suspect that it
<br>leans towards the latter and so I'm putting the rambling part below.
<br>=================================
<br><br>That uncouples events from the document object and makes it easier to
<br>make them part of specs that are not DOM-related, so it sounds like a
<br>good idea to me. I think you'd still want to support a no-arg
<br>constructor and some form of mutators for initialization.
<br><br>For use cases where separate initialization is not needed, I think the
<br>syntax you're showing is very understandable and the terseness does not
<br>detract from the usefulness.
<br><br>For reasons related to use of reflection, it would still be nice to be
<br>able to create an event by passing the name via string.
<br><br>Could it make sense to have an independent event control object (factory
<br>or singleton make sense to me) that could be used to create events via
<br>reflection rather than explicit constructors? It might be interesting
<br>to be able to look-ahead at upcoming events that are not yet being
<br>processed, or have built in event history. Such an object could be a
<br>window into existing eventing queues, as well as a place to implement a
<br>createEvent method agnostically.
<br><br>Under the hood the eventing object could be proxying to document or
<br>workerglobalscope or window or whatever object or objects are actually
<br>implementing eventing. In that sense I guess it could be made an
<br>interface that document and workerglobalscope implement and not even be
<br>a first-class object.
<br><br>I am now thinking a bit in circles here, because I'm back to suggesting
<br>document.createEvent() as just fine :) I hope my comments are useful.
<br><br>I will try to summarize where I've ended up:
<br><br>Objects implementing DOM Level 3 Event interface can be created via
<br>constructor, equivalent to .creatEvent(foo), .initFooEvent(bar,baz,...)
<br>EventingInterface specifies createEvent method and maybe some other fun
<br>stuff for looking at eventing queues
<br>Document (and possibly WorkerGlobalScope) to implement EventingInterface
<br>(if people want the convenience of the coupling of Document with event
<br>creation because of all the DOM Events)
<br>Consider Eventing object "eventing" which implements EventingInterface
<br>to be used in place of Document in non-DOM environments
<br><br>Regards,
<br>J5
<br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26544357
Re: [whatwg] createEvent() in Web Workers?
2009-11-27T08:02:00Z
2009-11-27T08:02:00Z
Simon Pieters-3
On Fri, 27 Nov 2009 16:50:21 +0100, Jonathan Cook
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26544357&i=0" target="_top" rel="nofollow">jonathan.j5.cook@...</a>> wrote:
<br><br>> Simon Pieters wrote:
<br>>> There's ErrorEvent.initErrorEvent, and dispatchEvent is exposed in
<br>>> workers, but there's no createEvent (because there's no document). Are
<br>>> there use cases for sending events in a worker? Should we expose
<br>>> createEvent somewhere? Should we remove initErrorEvent?
<br><div class='shrinkable-quote'><br>> I would like to see createEvent in WebWorker. My (theoretical) use case
<br>> would involve using custom eventing to load or set new message
<br>> handlers. Flow would be something like this
<br>>
<br>> window A creates worker 1
<br>> window A sends message to worker 1
<br>> worker 1 sends message to window A
<br>> window A sends message to worker 1
<br>> worker 1 creates an event "switch" in response to message, passing the
<br>> message in the event: createEvent("switch",message)
<br>> worker 1 switch event handler loads / sets new message handler, mutating
<br>> itself into worker 1 sub 1 and calls the new message handler on the
<br>> passed message
<br>> worker 1 sub 1 sends message to window A
<br>>
<br>> Anyone think this theoretical use case or some derivative is a useful
<br>> abstraction to aid in code organization and flow control? I would think
<br>> since an eventing queue is specified for message handling that adding
<br>> custom events would not be much additional effort for implementers.
<br>>
<br>> initErrorEvent would seem to put the DOM Events Level 3 createEvent and
<br>> initEvent methods together. Is there a reason that this approach was
<br>> chosen instead of mirroring DOM Events? The simple answer seems to be
<br>> because there is no DOM :)
</div><br>An idea for creating events is to support [Constructor] on all event IDLs,
<br>which makes the createEvent method unnecessary.
<br><br>Maybe we could even make the arguments to the constructor be called to
<br>initFooEvent() directly, so instead of doing
<br><br> var e = document.createEvent('MouseEvents');
<br> e.initMouseEvent('click', ...);
<br> foo.dispatchEvent(e);
<br><br>you could do
<br><br> foo.dispatchEvent(new MouseEvent('click', ...))
<br><br><br>I've cc-ed www-dom since this is a suggestion for a change to DOM Events.
<br><br>--
<br>Simon Pieters
<br>Opera Software
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26518657
Minutes, DOM3 Events, 18 Nov 2009
2009-11-25T11:16:13Z
2009-11-25T11:16:13Z
Doug Schepers-3
Hi, DOM3 Events fans-
<br><br>The minutes for the DOM3 Events telcon of 18 Nov 2009:
<br><br> <a href="http://www.w3.org/2009/11/18-webapps-minutes.html" target="_top" rel="nofollow">http://www.w3.org/2009/11/18-webapps-minutes.html</a><br><br>Or as text below:
<br><br> [1]W3C
<br><br> [1] <a href="http://www.w3.org/" target="_top" rel="nofollow">http://www.w3.org/</a><br><br> - DRAFT -
<br><br> Web Applications Working Group Teleconference
<br><br>18 Nov 2009
<br><br> See also: [2]IRC log
<br><br> [2] <a href="http://www.w3.org/2009/11/18-webapps-irc" target="_top" rel="nofollow">http://www.w3.org/2009/11/18-webapps-irc</a><br><br>Attendees
<br><br> Present
<br> [Microsoft], [IPcaller], Shepazu
<br><br> Regrets
<br> Chair
<br> SV_MEETING_CHAIR
<br><br> Scribe
<br> Travis
<br><br>Contents
<br><br> * [3]Topics
<br> * [4]Summary of Action Items
<br> _________________________________________________________
<br><br><br><br> <trackbot> Date: 18 November 2009
<br><br> Travis: Talked to some folks about element-level resize (layout
<br> engineers) and based on layout complexity and potential spec
<br> vagueness (plus other browsers don't support this), I'd like to not
<br> spec this behavior as part of DOM L3 Events.
<br> ... Suggested change to spec for resize: proximal event target =
<br> Window (only)
<br> ... Wanting to ensure Wiki access to create strawman proposal for
<br> Faster Mutation Events (discussed with Jonas at TPAC 2009).
<br> ... verified that I do have editing access :)
<br> ... Got feedback from Microsoft's Office Web Companions: they wanted
<br> to have a keyboard language hint for internationalization features
<br> (spell/grammer).
<br> ... Makes more sense for compositionend events (which tend to be
<br> langauge specific).
<br><br> shepazu: Side conversation on shortcomings of not having physical
<br> key layout information.
<br> ... (re-)discovered keyValues for copy/paste/cut, which solves some
<br> common use cases.
<br> ... 2 key down sequence: CTRL keyValue + C [key], results in a
<br> KeyDown{keyValue:"Control"}, KeyDown{keyValue:"Copy"}
<br><br> Travis: "Labled keys" on my keyboard (Control Key combos):
<br> SelectAll, Find, Cut, Copy, Paste, Bold, Underline, Italic
<br> ... Non-Function keys (share keyspace as F1-F12): Help, Undo, Redo,
<br> New, Open, Close, Reply, Fwd, Send, Spell, Save, Print
<br><br> (Travis/Olli to think about this)
<br><br> Last topic: DOMActivate...
<br><br> Scenario-- user tabs to a link and press enter/space. Event sequence
<br> is {KeyboardEvent -> MouseEvent (click) -> Event (DOMActivate).
<br><br> scribe: So this is legacy behavior.
<br> ... We can't change this.
<br> ... It seems like DOMActivate and click have roughly the same
<br> meaning.
<br> ... I'll be radical: Let's consider deprecating (like the mutation
<br> events) DOMActivate. In its place, make 'click' the new DOMActivate!
<br><br> shepazu: We need to run this by the accessibility community to make
<br> sure we're not missing anything.
<br> ... Intuition tells me that deprecating DOMActivate will simplify
<br> web application development and actually make it simpler to make
<br> accessible web applications.
<br><br> <smaug> [5]<a href="http://www.w3.org/TR/progress-events/" target="_top" rel="nofollow">http://www.w3.org/TR/progress-events/</a><br><br> [5] <a href="http://www.w3.org/TR/progress-events/" target="_top" rel="nofollow">http://www.w3.org/TR/progress-events/</a><br><br> <smaug>
<br> [6]<a href="http://mxr.mozilla.org/mozilla-central/source/content/base/src/ns" target="_top" rel="nofollow">http://mxr.mozilla.org/mozilla-central/source/content/base/src/ns</a><br> Document.cpp#6145
<br><br> [6]
<br><a href="http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#6145" target="_top" rel="nofollow">http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#6145</a><br><br> <shepazu> trackbot, end telcon
<br><br>Summary of Action Items
<br><br> [End of minutes]
<br> _________________________________________________________
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26518059
Re: Thoughts on DOMActivate
2009-11-25T10:36:40Z
2009-11-25T10:36:40Z
Olli Pettay
On 11/19/09 6:21 PM, Travis Leithead wrote:
<div class='shrinkable-quote'><br>> As discussed on the recent working group call, I mentioned that I needed
<br>> to do some investigation into DOMActivate.
<br>>
<br>> (Attached are a few HTM files that demo the points made below.)
<br>>
<br>> Activate.htm tests the following types of elements that might/could fire
<br>> DOMActivate:
<br>>
<br>> 1. Focusable elements
<br>>
<br>> <div tabindex="1">Some block content</div>
<br>>
<br>> 2. Buttons (was mentioned explicitly)
<br>>
<br>> <div><button>A button to click on</button></div>
<br>>
<br>> 3. Anchors (sans href attribute)
<br>>
<br>> <p><a>A link to click on (sans href set)</a></p>
<br>>
<br>> 4. Anchors (with href attribute)
<br>>
<br>> <p><a href="javascript:void">Another link to click on</a></p>
<br>>
<br>> Per Firefox Testing:
<br>>
<br>> Using MouseClicks
<br>>
<br>> 1> 'click'
<br>>
<br>> 2> 'click', 'DOMActivate'
<br>>
<br>> 3> 'click'
<br>>
<br>> 4> 'click', 'DOMActivate'
<br>>
<br>> Using the Keyboard
<br>>
<br>> 1> 'keydown'
<br>>
<br>> 2> 'keydown', 'click', 'DOMActivate'
<br>>
<br>> 3> n/a (not default focusable)
<br>>
<br>> 4> 'keydown', 'click', 'DOMActivate'
<br>>
</div><br>Actually, IIRC, it is keypress which fires click.
<br><div class='shrinkable-quote'><br>> Hypothetically, if the standard deprecates 'DOMActivate' as has been
<br>> discussed, These two scenarios would look like this:
<br>>
<br>> Using MouseClicks (click for DOMActivate)
<br>>
<br>> 1> 'click'
<br>>
<br>> 2> 'click'
<br>>
<br>> 3> 'click'
<br>>
<br>> 4> 'click'
<br>>
<br>> Using the Keyboard (click for DOMActivate)
<br>>
<br>> 1> 'keydown'
<br>>
<br>> 2> 'keydown', 'click'
<br>>
<br>> 3> n/a (not default focusable)
<br>>
<br>> 4> 'keydown', 'click'
<br>>
<br>> So,
<br>>
<br>> 1) In cases where you use the keyboard or the mouse to perform an
<br>> activation (cases 2 and 4) click can be used fully in place of
<br>> DOMActivate with no issues. It will also be triggered for
<br>> non-activations which could be an issue.
<br>>
<br>> 2) In cases where you wanted to detect that an activation behavior was
<br>> about to be triggered, you can no longer distinguish between a regular
<br>> click and a click that is a result of an activation. E.g., when using
<br>> the mouse as your input device you can't tell when an activation
<br>> behavior will occur for anything...
</div>I'm not quite sure what you mean here.
<br>If there is DOMActivate, some event listener could call preventDefault
<br>on that, the similar way as with click.
<br><br><div class='shrinkable-quote'><br>>
<br>> For (2) this could be considered a "good thing" or a "bad thing". It
<br>> could be considered good if you want to abstract away the concept of
<br>> "activate" to that web apps don't need to care about it--they handle
<br>> everything through 'click'. It could be a bad thing if you feel that a
<br>> web app should know when some "activation" happens.
<br>>
<br>> For buttons, radio buttons, checkboxes, etc., the activation behavior
<br>> seems rather redundant, since event handlers for 'click' are going to
<br>> check the state of the element themselves (this.value or
<br>> this.checked)--Canceling the 'click' event in these scenarios already
<br>> revert the changed value (has identical behavior as DOMActivate in these
<br>> scenarios).
<br>>
<br>> For links, there's already a catch-all that can (and is) used to stop
<br>> the default value of the activation--even after DOMActivate has
<br>> successfully completed--and that is 'beforeunload'.
</div>What is wrong with adding 'click' listener to window? That
<br>would catch all the click events and could call preventDefault()
<br>(and maybe stopPropagation() if needed, depends on the phase the
<br>listener was added to).
<br><br><div class='shrinkable-quote'><br>>
<br>> An additional test is attached [activate2.htm] for showing that
<br>> beforeunload can be used in place of DOMActivate to stop
<br>> navigations--The drawback is that to use it, a dialog is displayed to
<br>> the user (no silent link blocking--which may be a good thing from a
<br>> user-perspective anyway).
<br>>
<br>> I remain open to scenarios that prove the need for DOMActivate, but seem
<br>> to find that it's largely irrelevant (except for legacy dependencies, of
<br>> course).
<br>>
</div>It is indeed difficult to find good real-world use cases for
<br>DOMActivate. click works usually just well enough.
<br><br><br>-Olli
<br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26429274
Thoughts on DOMActivate
2009-11-19T08:21:03Z
2009-11-19T08:21:03Z
Travis Leithead-3
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>As discussed on the recent working group call, I mentioned that I needed to do some investigation into DOMActivate. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(Attached are a few HTM files that demo the points made below.)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Activate.htm tests the following types of elements that might/could fire DOMActivate:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>1. Focusable elements<o:p></o:p></p><p class=MsoNormal> <div tabindex="1">Some block content</div><o:p></o:p></p><p class=MsoNormal>2. Buttons (was mentioned explicitly)<o:p></o:p></p><p class=MsoNormal> <div><button>A button to click on</button></div><o:p></o:p></p><p class=MsoNormal>3. Anchors (sans href attribute)<o:p></o:p></p><p class=MsoNormal> <p><a>A link to click on (sans href set)</a></p><o:p></o:p></p><p class=MsoNormal>4. Anchors (with href attribute)<o:p></o:p></p><p class=MsoNormal> <p><a href="javascript:void">Another link to click on</a></p><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>Per Firefox Testing:<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>Using MouseClicks<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>1> 'click'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>2> 'click', 'DOMActivate'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>3> 'click'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>4> 'click', 'DOMActivate'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>Using the Keyboard<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>1> 'keydown' <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>2> 'keydown', 'click', 'DOMActivate'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>3> n/a (not default focusable)<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>4> 'keydown', 'click', 'DOMActivate'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>Hypothetically, if the standard deprecates 'DOMActivate' as has been discussed, These two scenarios would look like this:<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>Using MouseClicks (click for DOMActivate)<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>1> 'click'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>2> 'click'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>3> 'click'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>4> 'click'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>Using the Keyboard (click for DOMActivate)<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>1> 'keydown' <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>2> 'keydown', 'click'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>3> n/a (not default focusable)<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>4> 'keydown', 'click'<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>So, <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>1) In cases where you use the keyboard or the mouse to perform an activation (cases 2 and 4) click can be used fully in place of DOMActivate with no issues. It will also be triggered for non-activations which could be an issue.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>2) In cases where you wanted to detect that an activation behavior was about to be triggered, you can no longer distinguish between a regular click and a click that is a result of an activation. E.g., when using the mouse as your input device you can't tell when an activation behavior will occur for anything... <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>For (2) this could be considered a "good thing" or a "bad thing". It could be considered good if you want to abstract away the concept of "activate" to that web apps don't need to care about it--they handle everything through 'click'. It could be a bad thing if you feel that a web app should know when some "activation" happens. <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>For buttons, radio buttons, checkboxes, etc., the activation behavior seems rather redundant, since event handlers for 'click' are going to check the state of the element themselves (this.value or this.checked)--Canceling the 'click' event in these scenarios already revert the changed value (has identical behavior as DOMActivate in these scenarios).<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>For links, there's already a catch-all that can (and is) used to stop the default value of the activation--even after DOMActivate has successfully completed--and that is 'beforeunload'.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>An additional test is attached [activate2.htm] for showing that beforeunload can be used in place of DOMActivate to stop navigations--The drawback is that to use it, a dialog is displayed to the user (no silent link blocking--which may be a good thing from a user-perspective anyway).<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.25in;text-autospace:none'><span style='font-size:9.0pt;font-family:Consolas'>I remain open to scenarios that prove the need for DOMActivate, but seem to find that it's largely irrelevant (except for legacy dependencies, of course).<o:p></o:p></span></p></div></body></html><br /><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Untitled Page</title>
</head>
<body>
</body>
<div tabindex="1">Some block content</div>
<div><button>A button to click on</button></div>
<p><a target="_top">A link to click on (sans href set)</a></p>
<p><a href="#" target="_top" rel="nofollow">Another link to click on</a></p>
<code></code>
</html>
<br /><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Untitled Page</title>
</head>
<body>
</body>
<div tabindex="1">Some block content</div>
<div><button>A button to click on</button></div>
<p><a target="_top">A link to click on (sans href set)</a></p>
<p><a href="http://www.bing.com" target="_top" rel="nofollow">Another link to click on (Bing)</a></p>
<code></code>
</html>
<br /><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Untitled Page</title>
</head>
<body>
<input type="checkbox" />
</body>
</html>
<p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26307645
Belated regrets...
2009-11-11T12:03:05Z
2009-11-11T12:03:05Z
Travis Leithead-3
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>I apologize for missing today’s telecon. I have goals this coming week to deliver on several of my DOM Events actions items so that we can start to close in on CR.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sorry for the inconvenience.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Travis<o:p></o:p></p></div></body></html><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26225574
Key Identifiers
2009-11-05T14:47:55Z
2009-11-05T14:47:55Z
Øistein E. Andersen-4
According to a note in the draft, ‘the “keydown” and “keyup”
<br>events are traditionally associated with detecting a physical key
<br>rather than a character value’, but the current model does not seem
<br>to allow a physical key to be detected.
<br><br>For some use cases, what matters is the physical position of a key,
<br>irrespective of keyboard layout, and not the character produced when a
<br>particular keyboard layout is active. For instance, the MacOS X
<br>Widget ‘Tastiera’ [1] maps keys to piano keys; for this
<br>application, a Q on a QWERTY keyboard is equivalent to an A on a
<br>French (AZERTY) keyboard, to an Й on an Old Russian (ЙІУКЕН)
<br>keyboard, etc., but DOM Events does no seem to provide a unique
<br>identifier corresponding to the physical key variously producing a Q,
<br>an A, an Й, etc.
<br><br>Mac OS X Cocoa's NSEvent (for the sake of a concrete example) provides
<br>‘charactersIgnoringModifiers’ similar to DOM Events'
<br>KeyboardEvent.key (though it uses unescaped Unicode characters in the
<br>returned string, which seems preferable, but that is a different
<br>discussion), but also ‘keyCode’ which identifies a physical key by
<br>means of a hardware-independent, virtual key code (probably inherited
<br>from ADB). Other platforms presumably have similar functionality, and
<br>it would be great if an attribute allowing a physical key to be
<br>identified could be added to DOM Events as well. An existing set of
<br>scan codes could be adopted, or a more systematic area/row/column
<br>enumeration scheme could be envisaged.
<br><br>***
<br><br>This is somewhat related to a WebKit bug on keyup/keydown events and
<br>dead keys [2]. The DOM Events draft suggests that dead keys should be
<br>represented by Unicode combining characters, which may well be the
<br>best solution available; it might be worth pointing out, though, that
<br>the two concepts are different in that a dead key is pressed before
<br>the corresponding letter key whereas a combining character comes after
<br>the corresponding letter (i.e., naïve would be typed na¨ive with ¨
<br>being a dead key, but represented as nai¨ve in Unicode with ¨ being a
<br>combining diacritic).
<br><br>--
<br>Øistein E. Andersen
<br><br><br>[1] <<a href="http://coq.no/widget/tastiera/en" target="_top" rel="nofollow">http://coq.no/widget/tastiera/en</a>>
<br>[2] <<a href="https://bugs.webkit.org/show_bug.cgi?id=30652" target="_top" rel="nofollow">https://bugs.webkit.org/show_bug.cgi?id=30652</a>>
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26177010
Re: [whatwg] focus change inside keypress event handler
2009-11-03T01:23:28Z
2009-11-03T01:23:28Z
Michael A. Puls II
On Tue, 03 Nov 2009 03:26:05 -0500, Michael A. Puls II
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26177010&i=0" target="_top" rel="nofollow">shadow2531@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> On Thu, 29 Oct 2009 21:58:29 -0400, Michael A. Puls II
<br>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26177010&i=1" target="_top" rel="nofollow">shadow2531@...</a>> wrote:
<br>>
<br>>> I'll put together a new description with the changes to see if sounds
<br>>> good.
<br>>
<br>> O.K., this description might be better and sounds more like what Firefox
<br>> does for compat with the net:
<br>>
<br>> -------
<br>> Fire 'keydown' first.
<br>>
<br>> The default action for 'keydown' is to set the acceptKeypress flag to
<br>> true. Using preventDefault() (either explicitly or implicitly through
<br>> return false) prevents the default action and results in the
<br>> acceptKeypress flag remaining false.
<br>>
<br>> Changing the focus from one object to another inside the 'keydown'
<br>> handler changes the current Context Object (what the action will be
<br>> performed on) for the following 'keypress' handler.
<br>>
<br>> After the 'keydown' handler runs, fire 'keypress'.
<br>>
<br>> The default action for 'keypress' is to allow the keypress if the
<br>> acceptKeypress flag is true.
<br>>
<br>> If acceptKeypress is not true or if preventDefault() is called in the
<br>> 'keypress' handler (either explicitly or implicitly through return
<br>> false), then the keypress is not allowed.
<br>>
<br>> If the keypress is allowed then perform the action on the current
<br>> Context Object. The action could be text insertion, text deletion,
<br>> scrolling etc.
<br>>
<br>> If the keypress is not allowed, then do not perform the action unless
<br>> the UA does not allow preventing the action, which in that case, perform
<br>> the action.
<br>>
<br>> Note that a focus change inside a 'keypress' handler does not change the
<br>> current Context Object for the keypress.
<br>>
<br>> If the a key is being held down and Repeat Processing is supported,
<br>> process the above over and over. (e.g. keydown -> keyup -> keydown ->
<br>> keyup)
<br>>
<br>> When the key is finally released, fire 'keyup'.
<br>>
<br>> However, note that if alert(), confirm() or prompt() is used inside a
<br>> 'keydown' handler and or inside a 'keypress' handler, whether 'keyup'
<br>> fires varies between implementations.
<br>>
<br>> Also note that alert(), confirm(), prompt(), setTimeout and
<br>> setInterval() inside the 'keydown' , 'keypress' and 'keyup' handlers
<br>> may result in some code inside the handlers running in a different order
<br>> than 'keydown' -> 'keypress' -> 'keyup'.
<br>> -------
<br>>
<br>> That's how Firefox appears to work, in my words, from the outside
<br>> looking in.
</div><br>I should also note that in the 'keydown' handler, if a focus change
<br>happens *after* an alert(), the focus change will not change the context
<br>for 'keypress' as 'keypress' will have already fired before the focus
<br>change happens, which probably makes my "After the 'keydown' handler runs,
<br>fire 'keypress'" part not entire accurate as far as "After" goes.
<br><br>--
<br>Michael
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26176357
Re: [whatwg] focus change inside keypress event handler
2009-11-03T00:26:05Z
2009-11-03T00:26:05Z
Michael A. Puls II
On Thu, 29 Oct 2009 21:58:29 -0400, Michael A. Puls II
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26176357&i=0" target="_top" rel="nofollow">shadow2531@...</a>> wrote:
<br><br>> I'll put together a new description with the changes to see if sounds
<br>> good.
<br><br>O.K., this description might be better and sounds more like what Firefox
<br>does for compat with the net:
<br><br>-------
<br>Fire 'keydown' first.
<br><br>The default action for 'keydown' is to set the acceptKeypress flag to
<br>true. Using preventDefault() (either explicitly or implicitly through
<br>return false) prevents the default action and results in the
<br>acceptKeypress flag remaining false.
<br><br>Changing the focus from one object to another inside the 'keydown' handler
<br>changes the current Context Object (what the action will be performed on)
<br>for the following 'keypress' handler.
<br><br>After the 'keydown' handler runs, fire 'keypress'.
<br><br>The default action for 'keypress' is to allow the keypress if the
<br>acceptKeypress flag is true.
<br><br>If acceptKeypress is not true or if preventDefault() is called in the
<br>'keypress' handler (either explicitly or implicitly through return false),
<br>then the keypress is not allowed.
<br><br>If the keypress is allowed then perform the action on the current Context
<br>Object. The action could be text insertion, text deletion, scrolling etc.
<br><br>If the keypress is not allowed, then do not perform the action unless the
<br>UA does not allow preventing the action, which in that case, perform the
<br>action.
<br><br>Note that a focus change inside a 'keypress' handler does not change the
<br>current Context Object for the keypress.
<br><br>If the a key is being held down and Repeat Processing is supported,
<br>process the above over and over. (e.g. keydown -> keyup -> keydown ->
<br>keyup)
<br><br>When the key is finally released, fire 'keyup'.
<br><br>However, note that if alert(), confirm() or prompt() is used inside a
<br>'keydown' handler and or inside a 'keypress' handler, whether 'keyup'
<br>fires varies between implementations.
<br><br>Also note that alert(), confirm(), prompt(), setTimeout and setInterval()
<br>inside the 'keydown' , 'keypress' and 'keyup' handlers may result in some
<br>code inside the handlers running in a different order than 'keydown' ->
<br>'keypress' -> 'keyup'.
<br>-------
<br><br>That's how Firefox appears to work, in my words, from the outside looking
<br>in.
<br><br>Again though, even if that's not right, I still want the spec to go into
<br>details like that.
<br><br>--
<br>Michael
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26157212
Re: Touch and gestures events
2009-11-01T06:50:24Z
2009-11-01T06:50:24Z
Pascal Germroth
Hello List,
<br>I subscribed just now, hope this will be in the correct thread...
<br><br>> We have implemented touch and manipulate (including pan, scale and
<br>> rotate) events on top of Qt 4.6 and WebKit, and the open-sourced
<br>> results can be seen in <a href="http://opensource.nokia.com/Starlight" target="_top" rel="nofollow">http://opensource.nokia.com/Starlight</a><br><br>In order to do really interesting things with multi-touch, the
<br>manipulate API is not enough, for example if applications want to detect
<br>specific gestures (for example a 3-finger 3D rotate/move).
<br>And with the current TouchEvent it would be quite hard to achieve this:
<br>to have easy gesture detection developers need three things:
<br><br>a "history"-function of the event: multi-touch gestures use a lot of
<br>dragging. So it's interesting to know, where the path of a certain
<br>finger started, and how it arrived at the current point. TouchEvents
<br>should include a pointer to a previous TouchEvent (if applicable)
<br>indicating the last position of the finger, effectively creating a
<br>linked list, where the tail node is the "touch down"-event for that
<br>finger, then the subsequent "touch move"-events until the "touch up"-event.
<br><br>a list of current event chains: of course, the application could catch
<br>the touch events and add the chain to a list on "touch down", remove it
<br>on "touch up", but it would be quite work intensive, since, for optimal
<br>comfort, one such "current touches"-list should exist for every element
<br>that would receive the touch events (i.e. when hit).
<br><br>some kind of "tagging": applications would watch for touch events, and
<br>upon receiving them, analyze the "current touches"-list to detect
<br>multi-finger gestures, like "pinch". For example, when exactly two
<br>fingers are pressed down on an object, this is "pinch". Should their
<br>traces accidentally leave the object, they should not be recognized as
<br>some other gesture, thus the application would "tag" them, so they won't
<br>show up in "current touches"-lists higher/lower on the hierarchy. Like
<br>bubble/propagation-prevention, but for the whole chain of touch events
<br>that describe the motion of the "tagged" finger.
<br>(this could be a library function though)
<br><br><br>The reason, why event-chaining should be in the DOM, and not in the
<br>application, is consistency: there are different approaches to tracking,
<br>one might just look for the trace which has its endpoint nearest to the
<br>motion-event to be matched, or consider velocity and curvature of the
<br>trace to resolve conflicts. (for example: many multi-touch frameworks
<br>fail to track correctly two fingers describing an X-shape by doing > and
<br>< motions and end up with / and \-traces)
<br>But maybe that's the OS's or driver's job.
<br><br><br><br>Sorry if my rambling was irrelevant, my last experience with multi-touch
<br>is from 2007.
<br><br>--
<br>pascal germroth
<br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26148759
Travel Notification: Expect Delayed Responses
2009-11-01T00:19:36Z
2009-11-01T00:19:36Z
Doug Schepers-3
Hi, Folks-
<br><br>Like many W3C folks, I will be traveling to the TPAC (Technical Plenary
<br>and Advisory Committee face-to-face meeting in Santa Clara, CA) all next
<br>week, so I will most likely not respond to general emails during that
<br>time. It may also take me some time to catch up after my return. My
<br>apologies in advance for slow response times.
<br><br>Regards-
<br>-Doug Schepers
<br>W3C Team Contact, SVG and WebApps WGs
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26142526
Re: Changes to DOM3 Events Key Identifiers
2009-10-31T06:54:01Z
2009-10-31T06:54:01Z
Giovanni Campagna
2009/10/30 Doug Schepers <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26142526&i=0" target="_top" rel="nofollow">schepers@...</a>>:
<div class='shrinkable-quote'><br>> Hi, Laurens-
<br>>
<br>> Laurens Holst wrote (on 10/30/09 7:02 AM):
<br>>>
<br>>> Op 30-10-2009 10:32, Maciej Stachowiak schreef:
<br>>>>
<br>>>> "\uxxxx" is not a syntax, it is a Unicode string of the actual
<br>>>> character. \u introduces the escape sequence for a unicode code point.
<br>>>> So you can compare it directly to a character.
<br>>>
<br>>> Now I’m confused. The way Doug phrased it, \uxxxx *will* be syntax, i.e.
<br>>> the string "U+xxxx" will be replaced by "\\uxxxx" (a 6-character string
<br>>> containing an identifier). Not "\uxxxx" (a 1-character string containing
<br>>> the actual character) which could be compared directly to a character.
<br>>>
<br>>> Otherwise, I would suggest not to talk in terms of "\uxxxx" strings at
<br>>> all, after all the DOM specification does not need to concern itself
<br>>> with serialisation, but instead to just talk about characters and code
<br>>> points.
<br>>
<br>>
<br>> Just to clarify, are you objecting to the loose way I phrased it in my
<br>> email, or did you review the spec and find problems there? I may have used
<br>> the wrong terminology in the email, but the spec is the definitive source
<br>> that needs to get it right.
<br>>
<br>> So, please clarify if you object to the change described in the spec.
</div><br>Section 6.2.6, point 1.1.1: it says to use the "character value",
<br>which is defined as the Unicode character escape, that is the string
<br>consisting of U+005C REVERSE SOLIDUS, U+0075 LATIN SMALL LETTER U and
<br>four characters in the range U+0061-0066 LATIN SMALL LETTER A to LATIN
<br>SMALL LETTER F and U+0030-0039 DIGIT ZERO to DIGIT NINE, which
<br>interpreted as hexadecimal can be transformed into an Unicode scalar
<br>value / Unicode codepoint (meaning of the Unicode standard, not of the
<br>DOM3Events spec).
<br>Point 1.1.2 instead says to use the "Unicode code point" and encode it
<br>with "\u" (again U+005C REVERSE SOLIDUS, U+0075 LATIN SMALL LETTER U)
<br>followed by 4 or more hexadecimal digits.
<br>Section 2.6.7 finally says to use the most-author friendly between the
<br>"character value" and the "key name".
<br><br>So:
<br>1) What is the difference between 6.2.6, point 1.1.1 and the
<br>following? Both result in a key value like "\u0041" for A U+0041 LATIN
<br>CAPITAL LETTER A (since that is the "character value" for that key in
<br>6.2.7, and that is the encoded Unicode code point as for the Unicode
<br>standard)
<br>2) How do you choose the most author friendly? I think that "A" is a
<br>better name for U+0041 LATIN CAPITAL LETTER A, but spec says to prefer
<br>always the character value, that is "\u0041"
<br>3) Why both the examples and some earlier poster affirmed that instead
<br>the value key is a single character string containing the character
<br>itself?
<br><br>That is, given event instance of KeyboardEvent, event.key in Javascript returns
<br>for a key with label "+ =", in the US layout, shift pressed
<br>- "\u002B", the Unicode code point / character value, represented as
<br>an escaped string
<br>this means that key.length===6 and key.charAt(0) === "\"
<br>also, String(key).length===6 and JSON.parse(key) throws, that is,
<br>there is no good method to get a "+" from that (unicode character
<br>escapes are resolved at the parser layer, they don't leak inside
<br>strings)
<br>- "Plus", the key name from the database
<br>this means that you need convertKeyValue to get the plus, but probably
<br>it is more recognizable or easier to remember than "\u002B"
<br>- "+", the Unicode character
<br>this means that key.length===1 and key.charAt(0) ==="+"
<br>this is probably the better way for an author, although is not what
<br>the spec currently says
<br>for a key with label "% 5", in the US-international layout, AltGr pressed
<br>- "\u20AC" (key.length===6 and key.charAt(0)==="\")
<br>- "Euro"
<br>- "€"
<br>and for an imaginary key corresponding to U+10000 LINEAR B SYLLABLE B008 A
<br>- "\uD800\uDC00" (key.length===12 and key.charAt(0)==="\")
<br>- "\u10000" (key.length===7 and key.charAt(0) ==="\")
<br>- "LinearBSyllableB008A"
<br>- "" (key.length===2 and key.charAt(0) ===String.fromCharCode(55296) )
<br><br>Moreover, given the same events in C++, assuming that WebIDL for C++
<br>said: "use char* for DOMString", what you get?
<br>- "\u002B","\u20AC" and "\uD800\uDC00", meaning that strlen(key)==6
<br>(==12 for U+10000) and *key == 92
<br>- "\u002B", "\u20AC" and "\u10000", meaning that strlen(key) is either
<br>6 or 7 and *key==92
<br>- "Plus", "Euro", "LinearBSyllableB008A"
<br>- "+" ( strlen(key)==1 and *key == 43 ) "€" ( strlen(key)==3 and *key
<br>== 226 ) and "" ( strlen(key)==4 and *key==240 )
<br><br>> Regards-
<br>> -Doug Schepers
<br>> W3C Team Contact, SVG and WebApps WGs
<br>>
<br>>
<br><br>Giovanni
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26140732
Re: [whatwg] focus change inside keypress event handler
2009-10-31T01:54:25Z
2009-10-31T01:54:25Z
Michael A. Puls II
On Fri, 30 Oct 2009 18:56:33 -0400, Boris Zbarsky <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26140732&i=0" target="_top" rel="nofollow">bzbarsky@...</a>> wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On 10/30/09 6:41 PM, Michael A. Puls II wrote:
<br>>>>> Is there a good way to solve that though? Or is that something that
<br>>>>> should just be left as YMMV?
<br>>>>
<br>>>> Well, you could require an alert to block all key event delivery to
<br>>>> the web page, right?
<br>>>
<br>>> Would that be a desirable solution? Is that hard to implement?
<br>>
<br>> I don't know, and I don't know. The answer to the latter question
<br>> depends strongly on the precise event model the browser is using, how it
<br>> interacts with the OS, what it actually does for alert, etc.
</div></div>Another thing I noticed:
<br><br>With the attached, 'keyup' doesn't fire if you use an alert() in the
<br>'keydown' or 'keypress' handler.
<br><br>Well, actually, it fires sometimes in Firefox and Safari, but it's not
<br>very consistent. Avoiding alert()s makes things more consistent.
<br><br>I also noticed that with the attached in Opera, if you press the spacebar
<br>in the field, the alert that pops up disappears right away because the
<br>space somehow gets invoked on the OK button on the alert().
<br><br>--
<br>Michael<br /><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title></title>
</head>
<body>
<p><input></p>
</body>
</html><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26143017
Typo in section 6.2.5
2009-10-30T21:59:22Z
2009-10-30T21:59:22Z
ATSUSHI TAKAYAMA
Hi Doug Schepers,
<br><br>In the latest draft, there is a (very minor) typo. In section 6.2.5,
<br>the third example it says;
<br><br>5. textInput: 'a' @@ shouldn't this be 'é'?
<br><br>but it should be
<br><br>5. textInput: 'e'
<br><br><a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset-key-values" target="_top" rel="nofollow">http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset-key-values</a><br><br>Regards,
<br>Atsushi Takayama
<br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26139637
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T20:39:09Z
2009-10-30T20:39:09Z
Mark Davis ☕
> If you happen to want to interpret<br>
them as UTF-16, you are free to do so, but there is not and never will<br>
be any guarantee that all strings are well-formed UTF-16.<br><br>You never have that guarantee, any more than you have the guarantee that a source purporting to be UTF-8 is in fact well formed. All conscientious recipients need to check the data -- <b>if</b> they are sensitive to ill-formed text. Luckily, the impact of ill-formed UTF-16 is vastly less than that of ill-formed UTF-8.<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Fri, Oct 30, 2009 at 17:47, John Cowan <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26139637&i=0" target="_top" rel="nofollow">cowan@...</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Phillips, Addison scripsit:<br>
<div class="im"><br>
> ECMAScript's "firm commitment" to a 16-bit character model (i.e. UTF-16)<br>
<br>
</div>If only.<br>
<br>
JavaScript and JSON strings aren't sequences of characters, they are<br>
sequences of 16-bit unsigned integers. If you happen to want to interpret<br>
them as UTF-16, you are free to do so, but there is not and never will<br>
be any guarantee that all strings are well-formed UTF-16. What's more,<br>
the built-in JSON serializer provided by ECMAScript 5th edition does<br>
not generate escape sequences for isolated surrogate codepoints, so that<br>
some strings will be written out in CESU-8 rather than UTF-8.<br>
<br>
Worse yet, the JSON RFC is self-contradictory, with the result that it's<br>
not even clear that CESU-8-encoded JSON is illegal.<br>
<font color="#888888"><br>
--<br>
Let's face it: software is crap. Feature-laden and bloated, written under<br>
tremendous time-pressure, often by incapable coders, using dangerous<br>
languages and inadequate tools, trying to connect to heaps of broken or<br>
obsolete protocols, implemented equally insufficiently, running on<br>
unpredictable hardware -- we are all more than used to brokenness.<br>
--Felix Winkelmann<br>
</font></blockquote></div><br>
<p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26138821
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T17:47:38Z
2009-10-30T17:47:38Z
John Cowan
Phillips, Addison scripsit:
<br><br>> ECMAScript's "firm commitment" to a 16-bit character model (i.e. UTF-16)
<br><br>If only.
<br><br>JavaScript and JSON strings aren't sequences of characters, they are
<br>sequences of 16-bit unsigned integers. If you happen to want to interpret
<br>them as UTF-16, you are free to do so, but there is not and never will
<br>be any guarantee that all strings are well-formed UTF-16. What's more,
<br>the built-in JSON serializer provided by ECMAScript 5th edition does
<br>not generate escape sequences for isolated surrogate codepoints, so that
<br>some strings will be written out in CESU-8 rather than UTF-8.
<br><br>Worse yet, the JSON RFC is self-contradictory, with the result that it's
<br>not even clear that CESU-8-encoded JSON is illegal.
<br><br>--
<br>Let's face it: software is crap. Feature-laden and bloated, written under
<br>tremendous time-pressure, often by incapable coders, using dangerous
<br>languages and inadequate tools, trying to connect to heaps of broken or
<br>obsolete protocols, implemented equally insufficiently, running on
<br>unpredictable hardware -- we are all more than used to brokenness.
<br> --Felix Winkelmann
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26138186
Re: [whatwg] focus change inside keypress event handler
2009-10-30T16:09:42Z
2009-10-30T16:09:42Z
Michael A. Puls II
On Fri, 30 Oct 2009 00:34:14 -0400, Doug Schepers <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26138186&i=0" target="_top" rel="nofollow">schepers@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> Hi, Folks-
<br>>
<br>> Scott González wrote (on 10/29/09 11:03 AM):
<br>>> On Thu, Oct 29, 2009 at 9:20 AM, Michael A. Puls II
<br>>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26138186&i=1" target="_top" rel="nofollow">shadow2531@...</a> <mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26138186&i=2" target="_top" rel="nofollow">shadow2531@...</a>>> wrote:
<br>>>
<br>>> Safari and Firefox will allow focus() inside the handler to decide
<br>>> where the character gets inserted, but only with "keydown". With
<br>>> "keypress" (and textInput in webkit) in Firefox and Safari, it
<br>>> appears that the char was already inserted right after keydown, so a
<br>>> focus() change is already too late. Despite that though,
<br>>> preventDefault() still works in Firefox and Safari inside a
<br>>> "keypress" handler to prevent the char from being inserted. So, I'm
<br>>> not exactly sure what's they're doing behind the scenes.
<br>>>
<br>>>
<br>>> DOM Level 3 Events says "The default action of the keypress event
<br>>> depends upon the key and the context: if the key is associated with a
<br>>> character, and if there currently focused element in the document can
<br>>> receive text (such as a form input or an editable text block), the
<br>>> default action is to dispatch a textInput event with the character as
<br>>> the value of the TextEvent.data attribute"
<br>>>
<br>>> The default action of a keypress is not to insert a character in the
<br>>> element that has focus, but to insert a character on the element that
<br>>> represents the context of the keypress. In the given example, the
<br>>> keypress's context is the first field, not the second.
<br>>
<br>> Correct.
</div><br>So, you're saying that changing the focus() to another field inside the
<br>'keydown' handler (or keypress handler in the case of Opera and IE) MUST
<br>NOT change the insertion context (the field in this case that the text
<br>gets inserted into)?
<br><br>If so, that would seem to contradict what browsers do when the focus
<br>changes inside a 'keydown' handler and contradicts Opera and IE for focus
<br>changes inside a 'keypress' handler.
<br><br>Not allowing that would break chase.com's SSI entry for example. (It uses
<br>3 fields and moves to the next field after you've entered 3 numbers, then
<br>2, then 4.
<br><br>I've noticed lots of sites that change focus as you're typing to move the
<br>rest of the text to the next field. I'm not sure how many do the focus
<br>change inside a handler instead of after/before though.
<br><br>--
<br>Michael
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26138120
Re: [whatwg] focus change inside keypress event handler
2009-10-30T16:00:21Z
2009-10-30T16:00:21Z
Michael A. Puls II
On Fri, 30 Oct 2009 18:56:33 -0400, Boris Zbarsky <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26138120&i=0" target="_top" rel="nofollow">bzbarsky@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> On 10/30/09 6:41 PM, Michael A. Puls II wrote:
<br>>>>> Is there a good way to solve that though? Or is that something that
<br>>>>> should just be left as YMMV?
<br>>>>
<br>>>> Well, you could require an alert to block all key event delivery to
<br>>>> the web page, right?
<br>>>
<br>>> Would that be a desirable solution? Is that hard to implement?
<br>>
<br>> I don't know, and I don't know. The answer to the latter question
<br>> depends strongly on the precise event model the browser is using, how it
<br>> interacts with the OS, what it actually does for alert, etc.
</div><br>O.K. Thanks
<br><br>--
<br>Michael
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26138078
Re: [whatwg] focus change inside keypress event handler
2009-10-30T15:56:33Z
2009-10-30T15:56:33Z
Boris Zbarsky
On 10/30/09 6:41 PM, Michael A. Puls II wrote:
<br>>>> Is there a good way to solve that though? Or is that something that
<br>>>> should just be left as YMMV?
<br>>>
<br>>> Well, you could require an alert to block all key event delivery to
<br>>> the web page, right?
<br>>
<br>> Would that be a desirable solution? Is that hard to implement?
<br><br>I don't know, and I don't know. The answer to the latter question
<br>depends strongly on the precise event model the browser is using, how it
<br>interacts with the OS, what it actually does for alert, etc.
<br><br>-Boris
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26137917
Re: [whatwg] focus change inside keypress event handler
2009-10-30T15:41:34Z
2009-10-30T15:41:34Z
Michael A. Puls II
On Fri, 30 Oct 2009 01:29:00 -0400, Boris Zbarsky <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26137917&i=0" target="_top" rel="nofollow">bzbarsky@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> On 10/29/09 9:58 PM, Michael A. Puls II wrote:
<br>>>>> But, in Firefox, Safari and Opera, it's possible to change what
<br>>>>> element
<br>>>>> the text is inserted into by changing the focus in 'keydown'.
<br>>>>
<br>>>> Right; that happens because the keydown and keypress events need not
<br>>>> fire on the same element and because the text entry is the keypress
<br>>>> default action. In Gecko, that is. I can't speak to Safari and Opera.
<br>>>
<br>>> So, just to be sure, you're happy with that behavior?
<br>>
<br>> Which? It being possible to change focus in keydown and thus change
<br>> where the text will go?
</div><br>Yes.
<br><div class='shrinkable-quote'><br>> I'm pretty agnostic on whether that should be possible or not. Whichever
<br>> way makes the event model simpler, I think.
<br>>
<br>>>> This seems wrong to me. If a key is held down, I would expect a single
<br>>>> keydown followed by multiple keypresses.
<br>>>
<br>>> O.K. FF doesn't do that though. If you hold down a key, it'll do:
<br>>> keydown
<br>>> keypress
<br>>>
<br>>> over and over.
<br>>>
<br>>> At quick thought, are you O.K. with FF's current behavior being a bug?
<br>>
<br>> I don't know. It's worth looking up why the behavior is as it is (that
<br>> is, what web sites depend on). Multiple keypresses in this situation
<br>> are a definite necessity.
</div><br>Thanks. Opera seems to get a way with the multiple keydowns. But, its user
<br>base isn't as large, so, I'm not sure how much weight that has.
<br><div class='shrinkable-quote'><br>>>>> Note that 'keyup' may fire before 'keypress' if you release the key
<br>>>>> before an alert() inside the 'keydown' handler shows and blocks.
<br>>>>
<br>>>> This seems unfortunate, but ok.
<br>>>
<br>>> Is there a good way to solve that though? Or is that something that
<br>>> should just be left as YMMV?
<br>>
<br>> Well, you could require an alert to block all key event delivery to the
<br>> web page, right?
</div><br>Would that be a desirable solution? Is that hard to implement?
<br><br>--
<br>Michael
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26136926
RE: Changes to DOM3 Events Key Identifiers
2009-10-30T14:11:34Z
2009-10-30T14:11:34Z
Phillips, Addison
<div class='shrinkable-quote'>> Doug Schepers scripsit:
<br>>
<br>> > 1) DOM3 Events implementations also update their Javascript
<br>> engines to
<br>> > be able to process the additional escape sequence (e.g. one of
<br>> the ones
<br>> > you mention above) in the same way they process the "\u" escape
<br>> > sequence. This is the better long-term solution, and I'd hope
<br>> ECMA TC39
<br>> > could be persuaded to add this to future ECMAScript specs.
<br>>
<br>> I doubt it, given that such escapes are usually programmatically
<br>> generated.
<br>> In any case, ECMAScript is firmly committed to a 16-bit character
<br>> model.
<br>>
</div><br>ECMAScript's "firm commitment" to a 16-bit character model (i.e. UTF-16) is not the problem. Lack of support for supplementary characters (that is, those above 0xFFFF in Unicode), however, is a very real problem. No UTF-16 process can escape the fact that, even if one applies a short-sighted limit to BMP characters, a character may require more than one code point to encode. As long as it is clear that DOM3 Events key identifiers are a string containing possibly more than one code point (and potentially more than one character), the escaping syntax is just a detail of the language.
<br><br>Addison
<br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26136910
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T14:10:01Z
2009-10-30T14:10:01Z
John Cowan
Mark Davis �?? scripsit:
<br><br>> Java is committed to 16-bit code units as well, but a relatively small
<br>> number of additions enabled effective handling of UTF-16 text.
<br><br>Good luck getting any such additions into JavaScript, except as a library.
<br><br>--
<br>They tried to pierce your heart John Cowan
<br>with a Morgul-knife that remains in the <a href="http://www.ccil.org/~cowan" target="_top" rel="nofollow">http://www.ccil.org/~cowan</a><br>wound. If they had succeeded, you would
<br>become a wraith under the domination of the Dark Lord. --Gandalf
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26136855
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T14:04:59Z
2009-10-30T14:04:59Z
Mark Davis ☕
Java is committed to 16-bit code units as well, but a relatively small number of additions enabled effective handling of UTF-16 text.<br><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Fri, Oct 30, 2009 at 13:42, John Cowan <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26136855&i=0" target="_top" rel="nofollow">cowan@...</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Doug Schepers scripsit:<br>
<div class="im"><br>
> 1) DOM3 Events implementations also update their Javascript engines to<br>
> be able to process the additional escape sequence (e.g. one of the ones<br>
> you mention above) in the same way they process the "\u" escape<br>
> sequence. This is the better long-term solution, and I'd hope ECMA TC39<br>
> could be persuaded to add this to future ECMAScript specs.<br>
<br>
</div>I doubt it, given that such escapes are usually programmatically generated.<br>
In any case, ECMAScript is firmly committed to a 16-bit character model.<br>
<font color="#888888"><br>
--<br>
A rabbi whose congregation doesn't want John Cowan<br>
to drive him out of town isn't a rabbi, <a href="http://www.ccil.org/%7Ecowan" target="_blank" rel="nofollow">http://www.ccil.org/~cowan</a><br>
and a rabbi who lets them do it <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26136855&i=1" target="_top" rel="nofollow">cowan@...</a><br>
isn't a man. --Jewish saying<br>
</font></blockquote></div><br>
<p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26136585
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T13:42:59Z
2009-10-30T13:42:59Z
John Cowan
Doug Schepers scripsit:
<br><br>> 1) DOM3 Events implementations also update their Javascript engines to
<br>> be able to process the additional escape sequence (e.g. one of the ones
<br>> you mention above) in the same way they process the "\u" escape
<br>> sequence. This is the better long-term solution, and I'd hope ECMA TC39
<br>> could be persuaded to add this to future ECMAScript specs.
<br><br>I doubt it, given that such escapes are usually programmatically generated.
<br>In any case, ECMAScript is firmly committed to a 16-bit character model.
<br><br>--
<br>A rabbi whose congregation doesn't want John Cowan
<br>to drive him out of town isn't a rabbi, <a href="http://www.ccil.org/~cowan" target="_top" rel="nofollow">http://www.ccil.org/~cowan</a><br>and a rabbi who lets them do it <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26136585&i=0" target="_top" rel="nofollow">cowan@...</a>
<br>isn't a man. --Jewish saying
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26135185
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T11:48:20Z
2009-10-30T11:48:20Z
Doug Schepers-3
Hi, Laurens-
<br><br>Laurens Holst wrote (on 10/30/09 7:02 AM):
<div class='shrinkable-quote'><br>> Op 30-10-2009 10:32, Maciej Stachowiak schreef:
<br>>> "\uxxxx" is not a syntax, it is a Unicode string of the actual
<br>>> character. \u introduces the escape sequence for a unicode code point.
<br>>> So you can compare it directly to a character.
<br>>
<br>> Now I’m confused. The way Doug phrased it, \uxxxx *will* be syntax, i.e.
<br>> the string "U+xxxx" will be replaced by "\\uxxxx" (a 6-character string
<br>> containing an identifier). Not "\uxxxx" (a 1-character string containing
<br>> the actual character) which could be compared directly to a character.
<br>>
<br>> Otherwise, I would suggest not to talk in terms of "\uxxxx" strings at
<br>> all, after all the DOM specification does not need to concern itself
<br>> with serialisation, but instead to just talk about characters and code
<br>> points.
</div><br><br>Just to clarify, are you objecting to the loose way I phrased it in my
<br>email, or did you review the spec and find problems there? I may have
<br>used the wrong terminology in the email, but the spec is the definitive
<br>source that needs to get it right.
<br><br>So, please clarify if you object to the change described in the spec.
<br><br>Regards-
<br>-Doug Schepers
<br>W3C Team Contact, SVG and WebApps WGs
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26135088
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T11:41:24Z
2009-10-30T11:41:24Z
Mark Davis ☕
If the target of this is JavaScript, then the alternative (which Java has also chosen) is to use the UTF16 representation, wherein a pair of \u characters represents each supplementary character (above FFFF). It just needs to be carefully documented.<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Fri, Oct 30, 2009 at 11:38, Doug Schepers <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26135088&i=0" target="_top" rel="nofollow">schepers@...</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi, Mark-<br>
<br>
Mark Davis ☕ wrote (on 10/30/09 12:22 PM):<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I want to point out that Unicode code points can go up to hex 10FFFF.<br>
The standard for \u is exactly 4 digits, so that one can intermix with<br>
characters and know where it terminates. There are a couple of schemes<br>
that are used to extend this to up to 6 digits, and still know where to<br>
terminate.<br>
<br>
\UXXXXXXXX - C++, ICU<br>
\UXXXXXX - C#<br>
\u{xxxxxx} - Ruby<br>
<br>
There needs to be some mechanism for extending to 6 digits. It would be<br>
best to use one of the above rather than a new one. (My personal<br>
favorite is Ruby's.)<br>
</blockquote>
<br></div>
The reason the "\u" escaped character sequence was chosen was that it is the native ECMAScript escape notation, which is easy for browser-based applications to use directly (i.e. they can inject it directly into the markup as a character).<br>
<br>
But, yes, this does have the cap of 4 digits, and I personally would prefer to use a different escape mechanism... but only if one or both of these 2 conditions obtains:<br>
<br>
1) DOM3 Events implementations also update their Javascript engines to be able to process the additional escape sequence (e.g. one of the ones you mention above) in the same way they process the "\u" escape sequence. This is the better long-term solution, and I'd hope ECMA TC39 could be persuaded to add this to future ECMAScript specs.<br>
<br>
2) Script authors could use a normalizing method (c.f. convertKeyValue) to "dumb down" the 6-digit escape sequence into the 4-digit format (by converting to surrogate pairs when necessary).<br>
<br>
Javascript is becoming increasingly important, and so is the need for internationalized and localized language support. With the new font-linking enablers (including my favorite, WOFF [1]), and i18n domain extension policy [2], we're going to see more use of languages I have no chance of ever understanding, and I want DOM3 Events and ECMAScript to be part of that. I'd rather not introduce a not-very-good solution (UTF-16) that we know would not meet all the needs of the world community, just because of a (temporary?) circumstance with a vagary of Javascript.<br>
<br>
But, I also want this spec interoperably implemented... so, any solution needs the buy-in of the implementers. Any arguments on either side of the coin would help make a more informed decision.<br>
<br>
BTW, you stated a preference for the Ruby-style delimited escaped characters... could you say why you prefer that?<br>
<br>
[1] <a href="http://people.mozilla.com/%7Ejkew/woff/woff-2009-09-16.html" target="_blank" rel="nofollow">http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html</a><br>
[2] <a href="http://www.icann.org/en/announcements/announcement-30oct09-en.htm" target="_blank" rel="nofollow">http://www.icann.org/en/announcements/announcement-30oct09-en.htm</a><br>
<br>
Regards-<br><font color="#888888">
-Doug Schepers</font><div><div></div><div class="h5"><br>
W3C Team Contact, SVG and WebApps WGs<br>
</div></div></blockquote></div><br>
<p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26135049
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T11:38:35Z
2009-10-30T11:38:35Z
Doug Schepers-3
Hi, Mark-
<br><br>Mark Davis ☕ wrote (on 10/30/09 12:22 PM):
<div class='shrinkable-quote'><br>> I want to point out that Unicode code points can go up to hex 10FFFF.
<br>> The standard for \u is exactly 4 digits, so that one can intermix with
<br>> characters and know where it terminates. There are a couple of schemes
<br>> that are used to extend this to up to 6 digits, and still know where to
<br>> terminate.
<br>>
<br>> \UXXXXXXXX - C++, ICU
<br>> \UXXXXXX - C#
<br>> \u{xxxxxx} - Ruby
<br>>
<br>> There needs to be some mechanism for extending to 6 digits. It would be
<br>> best to use one of the above rather than a new one. (My personal
<br>> favorite is Ruby's.)
</div><br>The reason the "\u" escaped character sequence was chosen was that it is
<br>the native ECMAScript escape notation, which is easy for browser-based
<br>applications to use directly (i.e. they can inject it directly into the
<br>markup as a character).
<br><br>But, yes, this does have the cap of 4 digits, and I personally would
<br>prefer to use a different escape mechanism... but only if one or both of
<br>these 2 conditions obtains:
<br><br>1) DOM3 Events implementations also update their Javascript engines to
<br>be able to process the additional escape sequence (e.g. one of the ones
<br>you mention above) in the same way they process the "\u" escape
<br>sequence. This is the better long-term solution, and I'd hope ECMA TC39
<br>could be persuaded to add this to future ECMAScript specs.
<br><br>2) Script authors could use a normalizing method (c.f. convertKeyValue)
<br>to "dumb down" the 6-digit escape sequence into the 4-digit format (by
<br>converting to surrogate pairs when necessary).
<br><br>Javascript is becoming increasingly important, and so is the need for
<br>internationalized and localized language support. With the new
<br>font-linking enablers (including my favorite, WOFF [1]), and i18n domain
<br>extension policy [2], we're going to see more use of languages I have no
<br>chance of ever understanding, and I want DOM3 Events and ECMAScript to
<br>be part of that. I'd rather not introduce a not-very-good solution
<br>(UTF-16) that we know would not meet all the needs of the world
<br>community, just because of a (temporary?) circumstance with a vagary of
<br>Javascript.
<br><br>But, I also want this spec interoperably implemented... so, any solution
<br>needs the buy-in of the implementers. Any arguments on either side of
<br>the coin would help make a more informed decision.
<br><br>BTW, you stated a preference for the Ruby-style delimited escaped
<br>characters... could you say why you prefer that?
<br><br>[1] <a href="http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html" target="_top" rel="nofollow">http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html</a><br>[2] <a href="http://www.icann.org/en/announcements/announcement-30oct09-en.htm" target="_top" rel="nofollow">http://www.icann.org/en/announcements/announcement-30oct09-en.htm</a><br><br>Regards-
<br>-Doug Schepers
<br>W3C Team Contact, SVG and WebApps WGs
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26133029
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T09:22:52Z
2009-10-30T09:22:52Z
Mark Davis ☕
I want to point out that Unicode code points can go up to hex 10FFFF. The standard for \u is exactly 4 digits, so that one can intermix with characters and know where it terminates. There are a couple of schemes that are used to extend this to up to 6 digits, and still know where to terminate.<br>
<br>\UXXXXXXXX - C++, ICU<br>\UXXXXXX - C#<br>\u{xxxxxx} - Ruby<br><br>There needs to be some mechanism for extending to 6 digits. It would be best to use one of the above rather than a new one. (My personal favorite is Ruby's.)<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Fri, Oct 30, 2009 at 00:32, Doug Schepers <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26133029&i=0" target="_top" rel="nofollow">schepers@...</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi, Folks-<br>
<br>
(BCC to potentially affected groups: w3c-html-cg, public-webapps, public-i18n-core, wai-xtech, www-svg, public-forms, public-xhtml2, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26133029&i=1" target="_top" rel="nofollow">public-html@...</a>, www-voice... please forward on to any relevant groups or individuals I may have missed, especially outside W3C.)<br>
<br>
As editor of the DOM3 Events specification, I made what some may consider to be drastic changes in the most recent drafts:<br>
* 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.<br>
* I renamed the "key identifier(s)" feature to "key value(s)".<br>
<br>
I've mentioned these ideas before in DOM3 Events telcons, and finally decided to do it, after first consulting with the I18n WG, who generally approved of the scheme (though not without some comments about details that will need to be addressed and resolved).<br>
<br>
The new string format should be easier to deal with for developers, and the new name reflects some confusion I've encountered when explaining what "key identifiers" are... the work "identifier" seems to evoke the concept of a unique identifier for a key, when in fact what the feature does is provides the most appropriate value given the state of keyboard modifiers and modes. I have tried also to clarify this in the prose of the spec.<br>
<br>
We are aware that there may already be implementations and specifications that rely on the previous string format and name (as well as links), back from when this was a W3C Note, and we do not make this decision lightly, but we do believe this is the right decision for a stable and internationalized keyboard interface going forward. For those implementations and specifications that need the previous functionality and name, you may be able to reference the SVG Tiny 1.2 specification [2] instead, which does include the old Key Identifiers feature more or less intact from the previous definition, and is a stable W3C Recommendation.<br>
<br>
You can review the changes in the most recent Editor's Draft [1]. The WebApps WG welcomes your feedback to the <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26133029&i=2" target="_top" rel="nofollow">www-dom@...</a> list. This specification is still a work in progress, though we do hope to go to Last Call soon, so we are open to suggestions. (Note that the spec is mostly feature-complete, so new event types and other changes may have to wait for the next version, but send them on anyway.)<br>
<br>
[1] <a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset" target="_blank" rel="nofollow">http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset</a><br>
[2] <a href="http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet" target="_blank" rel="nofollow">http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet</a><br>
<br>
<br>
Regards-<br><font color="#888888">
-Doug Schepers, on behalf of the WebApps WG<br>
Editor, DOM Level 3 Events<br>
W3C Team Contact, SVG and WebApps WGs<br>
<br>
</font></blockquote></div><br>
<p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26129076
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T05:14:12Z
2009-10-30T05:14:12Z
Alex Danilo
Hi Laurens,
<br><br>--Original Message--:
<div class='shrinkable-quote'><br>>Op 30-10-2009 11:36, Alex Danilo schreef:
<br>>>> "\uxxxx" is not a syntax, it is a Unicode string of the actual
<br>>>> character. \u introduces the escape sequence for a unicode code point.
<br>>>> So you can compare it directly to a character.
<br>>>>
<br>>> Thanks for the clarification.
<br>>>
<br>>
<br>>Well, regardless of whether what Maciej says is actually the case,
<br>>
<br>>> So, how does this provide any advantage over 'keyCode'?
<br>>>
<br>>
<br>>keyCode returns an integer, which in JavaScript is not directly
<br>>comparable to a character (well, it is, but not like in C; 101 ==
<br>>"101"). JavaScript does not have a character type, only a string type.
<br>>Actually I think C does not have a character type either, it is an alias
<br>>for byte, no? Either way, in JavaScript 169 != "©".
<br>>
<br>>> It seemed to me that keyCode is used for the code point, as in maps
<br>>> to the Unicode point and the whole reason there was keyIdentifier
<br>>> was to provide descriptive strings.
<br>>>
<br>>
<br>>keyCode does not map to Unicode code points, e.g. F1-F24 map to values
<br>>112-135 which are not Unicode.
<br>>
<br>>> If I want the Unicode point explicitly I can use
<br>>> keyCode or am I missing something?
<br>>>
<br>>
<br>>Hope this cleared that up.
</div><br>Yes, thanks it did, much appreciated.
<br><br>Alex
<br><div class='shrinkable-quote'><br>>~Laurens
<br>>
<br>>--
<br>>~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
<br>>Laurens Holst, developer, Utrecht, the Netherlands
<br>>Website: www.grauw.nl. Backbase employee; www.backbase.com
<br>>
<br>>
<br>>
<br>>
</div><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26128396
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T04:21:25Z
2009-10-30T04:21:25Z
Laurens Holst-3
Op 30-10-2009 11:36, Alex Danilo schreef:
<br>>> "\uxxxx" is not a syntax, it is a Unicode string of the actual
<br>>> character. \u introduces the escape sequence for a unicode code point.
<br>>> So you can compare it directly to a character.
<br>>>
<br>> Thanks for the clarification.
<br>>
<br><br>Well, regardless of whether what Maciej says is actually the case,
<br><br>> So, how does this provide any advantage over 'keyCode'?
<br>>
<br><br>keyCode returns an integer, which in JavaScript is not directly
<br>comparable to a character (well, it is, but not like in C; 101 ==
<br>"101"). JavaScript does not have a character type, only a string type.
<br>Actually I think C does not have a character type either, it is an alias
<br>for byte, no? Either way, in JavaScript 169 != "©".
<br><br>> It seemed to me that keyCode is used for the code point, as in maps
<br>> to the Unicode point and the whole reason there was keyIdentifier
<br>> was to provide descriptive strings.
<br>>
<br><br>keyCode does not map to Unicode code points, e.g. F1-F24 map to values
<br>112-135 which are not Unicode.
<br><br>> If I want the Unicode point explicitly I can use
<br>> keyCode or am I missing something?
<br>>
<br><br>Hope this cleared that up.
<br><br>~Laurens
<br><br>--
<br>~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
<br>Laurens Holst, developer, Utrecht, the Netherlands
<br>Website: www.grauw.nl. Backbase employee; www.backbase.com
<br><br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (4K) <a href="http://old.nabble.com/attachment/26128396/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26128195
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T04:02:36Z
2009-10-30T04:02:36Z
Laurens Holst-3
Op 30-10-2009 10:32, Maciej Stachowiak schreef:
<br>> "\uxxxx" is not a syntax, it is a Unicode string of the actual
<br>> character. \u introduces the escape sequence for a unicode code point.
<br>> So you can compare it directly to a character.
<br><br>Now I’m confused. The way Doug phrased it, \uxxxx *will* be syntax, i.e.
<br>the string "U+xxxx" will be replaced by "\\uxxxx" (a 6-character string
<br>containing an identifier). Not "\uxxxx" (a 1-character string containing
<br>the actual character) which could be compared directly to a character.
<br><br>Otherwise, I would suggest not to talk in terms of "\uxxxx" strings at
<br>all, after all the DOM specification does not need to concern itself
<br>with serialisation, but instead to just talk about characters and code
<br>points.
<br><br>~Laurens
<br><br>--
<br>~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
<br>Laurens Holst, developer, Utrecht, the Netherlands
<br>Website: www.grauw.nl. Backbase employee; www.backbase.com
<br><br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (4K) <a href="http://old.nabble.com/attachment/26128195/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>
tag:old.nabble.com,2006:post-26127948
Re: Changes to DOM3 Events Key Identifiers
2009-10-30T03:41:16Z
2009-10-30T03:41:16Z
Laurens Holst-3
Hi,
<br><br>I really really don’t see the benefit of that change. It only
<br>complicates things because it looks similar to a JS-string encoded
<br>character but is not actually one. I.e., "\u2018" does not equal
<br>"\\u2018". By introducing a backslash, I can already see people getting
<br>confused by this, writing:
<br><br> if (event.key == "\u2018")
<br><br>instead of
<br><br> if (event.key == "\\u2018")
<br><br>I know I often forget to double-escape the backslash (especially when I
<br>write regular expressions in strings :)), and then scratch my head over
<br>why it doesn’t work.
<br><br>Additionally, using \u gives the impression that it is an encoded string
<br>character, but that is not the case. People are in my experience having
<br>trouble realising the difference between serialisation and the actual
<br>character (e.g. they think that .nodeValue of a textnode containing &
<br>will return & instead of &). I think introducing this ‘encoding in a
<br>string value’ does not help people.
<br><br>Why would the new syntax be more intuitive than the old one? Just
<br>because one implementor says they got author feedback about this? Well,
<br>hereby I give you the feedback that as an author I do not ‘like’ the
<br>UTF-16 escaped character string :). I think it’s nicer to use the
<br>U+-notation, that is also used all over the place in specifications, web
<br>logs, the windows character map, etc. Contrary to that, the JS syntax is
<br>not familiar to me at all, I never use the JS-\u-notation, I encode the
<br>files as Unicode and insert the actual characters, which makes the
<br>strings readable.
<br><br>Also what about characters outside the 16-bit planes? You say escaped
<br>*UTF-16* character string. Does that mean for the U+10000 character, the
<br>resulting string will instead be \uD800\uDC00? In this case, I
<br>definitely think the latter is much more complicated.
<br><br>And of course there is also the matter that here you are changing an
<br>existing property which is referenced in a REC specification (SVN Tiny
<br>1.2). Because you do not really break backwards compatibility as you
<br>change the property name as well, this could be acceptable, however I
<br>can see no arguments for making such a change.
<br><br>To be clear, I do not consider “based on content author and implementer
<br>feedback” to be a well-founded argumentation to justify such a change
<br>:). I hope here I *did* provide some concrete reasons why this change is
<br>*not* a good idea. Especially given the confusing
<br>double-backslash-escaping described above, I do not think the current
<br>change was well thought-through by those who gave the feedback.
<br><br>If you would really want to make things easier, you could not return a
<br>key identifier but the character itself so you can compare it directly.
<br>E.g.:
<br><br> if (event.key == "\u00A9")
<br><br>or
<br><br> if (event.key == "©")
<br><br>~Laurens
<br><br>Op 30-10-2009 8:32, Doug Schepers schreef:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Hi, Folks-
<br>>
<br>> (BCC to potentially affected groups: w3c-html-cg, public-webapps,
<br>> public-i18n-core, wai-xtech, www-svg, public-forms, public-xhtml2,
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26127948&i=0" target="_top" rel="nofollow">public-html@...</a>, www-voice... please forward on to any relevant
<br>> groups or individuals I may have missed, especially outside W3C.)
<br>>
<br>> As editor of the DOM3 Events specification, I made what some may
<br>> consider to be drastic changes in the most recent drafts:
<br>> * I changed the syntax of the key identifier strings from "U+xxxx" (a
<br>> plain string representing the Unicode code point) to "\uxxxx" (an
<br>> escaped UTF-16 character string), based on content author and
<br>> implementer feedback.
<br>> * I renamed the "key identifier(s)" feature to "key value(s)".
<br>>
<br>> I've mentioned these ideas before in DOM3 Events telcons, and finally
<br>> decided to do it, after first consulting with the I18n WG, who
<br>> generally approved of the scheme (though not without some comments
<br>> about details that will need to be addressed and resolved).
<br>>
<br>> The new string format should be easier to deal with for developers,
<br>> and the new name reflects some confusion I've encountered when
<br>> explaining what "key identifiers" are... the work "identifier" seems
<br>> to evoke the concept of a unique identifier for a key, when in fact
<br>> what the feature does is provides the most appropriate value given the
<br>> state of keyboard modifiers and modes. I have tried also to clarify
<br>> this in the prose of the spec.
<br>>
<br>> We are aware that there may already be implementations and
<br>> specifications that rely on the previous string format and name (as
<br>> well as links), back from when this was a W3C Note, and we do not make
<br>> this decision lightly, but we do believe this is the right decision
<br>> for a stable and internationalized keyboard interface going forward.
<br>> For those implementations and specifications that need the previous
<br>> functionality and name, you may be able to reference the SVG Tiny 1.2
<br>> specification [2] instead, which does include the old Key Identifiers
<br>> feature more or less intact from the previous definition, and is a
<br>> stable W3C Recommendation.
<br>>
<br>> You can review the changes in the most recent Editor's Draft [1]. The
<br>> WebApps WG welcomes your feedback to the <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26127948&i=1" target="_top" rel="nofollow">www-dom@...</a> list. This
<br>> specification is still a work in progress, though we do hope to go to
<br>> Last Call soon, so we are open to suggestions. (Note that the spec is
<br>> mostly feature-complete, so new event types and other changes may have
<br>> to wait for the next version, but send them on anyway.)
<br>>
<br>> [1]
<br>> <a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset" target="_top" rel="nofollow">http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset</a>
<br>>
<br>> [2] <a href="http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet" target="_top" rel="nofollow">http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet</a><br>>
<br>>
<br>> Regards-
<br>> -Doug Schepers, on behalf of the WebApps WG
<br>> Editor, DOM Level 3 Events
<br>> W3C Team Contact, SVG and WebApps WGs
<br>>
</div></div><br>--
<br>~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
<br>Laurens Holst, developer, Utrecht, the Netherlands
<br>Website: www.grauw.nl. Backbase employee; www.backbase.com
<br><br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (4K) <a href="http://old.nabble.com/attachment/26127948/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/w3.org---www-dom-f11685.html" embed="fixTarget[11685]" target="_top" >w3.org - www-dom</a></p>