ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events]
ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/137 Raised by: Doug Schepers On product: DOM3 Events Hallvord R. M. Steen http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0176.html: [[ current spec text says about the keypress event: This event type shall be generated after the keyboard mapping but before the processing of an input method editor, normally associated with the dispatching of a compositionstart, compositionupdate, or compositionend event. I think this is wrong, if an IME is actively processing the input no keypress event should fire. ]]
ISSUE-138 (keyboard mapping): Define keyboard mapping [DOM3 Events]
ISSUE-138 (keyboard mapping): Define keyboard mapping [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/138 Raised by: Doug Schepers On product: DOM3 Events Hallvord R. M. Steen http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0177.html: [[ what exactly does the spec mean when it says this event type shall be generated after the keyboard mapping? I don't quite understand what after keyboard mapping refers to. I think it might mean figuring out the state of a character taking modifier keys and dead keys into account, but then why does the spec say the keydown event shall be generated after a keyboard mapping? ]]
ISSUE-139 (clarify key repeat): Define which events repeat when a key is held down [DOM3 Events]
ISSUE-139 (clarify key repeat): Define which events repeat when a key is held
down [DOM3 Events]
http://www.w3.org/2008/webapps/track/issues/139
Raised by: Doug Schepers
On product: DOM3 Events
Hallvord R. M. Steen
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0178.html:
[[
spec currently says:
Depending on the system configuration, holding down a key
results may result in multiple consecutive keydown events,
keypress events, and textInput events, for appropriate keys
Leaving aside the grammatical mistake ('results may result'), the spec is
too vague here. Web content requires that we repeatedly send
keydown+keypress [1]. Implementations that support this should also repeat
textInput and input events after keypress.
Suggested replacement text:
Holding down a key must result in repeating the events keydown, keypress
and textInput in this order, at a rate determined by the system
configuration.
(And I'm absolutely sure this is an issue and must be fixed, because Opera
currently breaks docs.google.com by not repeating correctly :-p)
]]
ISSUE-140 (textInput keydown keypress): textInput event as default action of both keydown and keypress? [DOM3 Events]
ISSUE-140 (textInput keydown keypress): textInput event as default action of both keydown and keypress? [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/140 Raised by: Doug Schepers On product: DOM3 Events Hallvord R. M. Steen http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0179.html: [[ spec currently says about keydown event: if the key is associated with a character, the default action shall be to dispatch a textInput event with the character as the value of the TextEvent.data attribute and about the keypress event (in the table): Default actionVaries: textInput event; So an implementation that follows this spec to the T might end up firing textInput twice for all input, once as the default action of keydown and once as the default action of keypress.. What implementations actually do (and current web content requires) is to fire *keypress* as the default action of the keydown event. Then the keypress event's default action is to fire textInput. I suggest fixing the spec to say keydown's default action is a keypress event. (Firefox has a small quirk that the spec IMO can ignore in that preventDefault() on keydown doesn't actually prevend the keypress event from firing - but it fires pre-cancelled. At some point in time, some legacy content required this behaviour - but other browsers align on making keypress entirely preventable.)]]
ISSUE-141 (IME examples): IME examples [DOM3 Events]
ISSUE-141 (IME examples): IME examples [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/141 Raised by: Doug Schepers On product: DOM3 Events Hallvord R. M. Steen http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0180.html: [[ In the text about Input Method Editors [1], the examples do keydown: 's' (U+0073, Latin Small Letter S key) compositionstart: '' keyup: 's' (U+0073, Latin Small Letter S key) keydown: 'i' (U+0069, Latin Small Letter I key) keyup: 'i' (U+0069, Latin Small Letter I key) keydown: 'Convert' Now, I'm not a developer - merely a black box QA tester - but is it possible to implement this in a cross-platform way? AFAIK, on Windows, Windows mobile and perhaps other platforms all the implementation will get in a keydown event is a VK_PROCESS virtual key code. How is the implementation then supposed to map that to an 's', an 'i' and so on? What sensible implementations currently do is to fire keydown with keyCode set to 220 (VK_PROCESS) and keyup with the actual key's virtual key code - if the platform makes it available in keyup events, otherwise 229. (Sorry about the number of separate E-mails today. I've tried to read the spec carefully earlier, but it's funny how you overlook things and they suddenly jump at you..) [1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keys-IME ]]
ISSUE-142 (multiple keypress): one keydown might fire multiple keypress/textInput events [DOM3 Events]
ISSUE-142 (multiple keypress): one keydown might fire multiple
keypress/textInput events [DOM3 Events]
http://www.w3.org/2008/webapps/track/issues/142
Raised by: Doug Schepers
On product: DOM3 Events
Hallvord R. M. Steen
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0181.html:
[[
Spec text on keydown event
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keydown
if the key is associated with a character, the default action
shall be to dispatch a textInput event with the character as
the value of the TextEvent.data attribute
uses singular forms ('a textInput event') which doesn't take into account
that a single keydown event might cause several keypress (- textInput)
events.
Trivial example: press a dead key twice. The default action of the second
keydown will be to fire two keypress and two text input events.
More far-fetched: use a keyboard layout where some keys are mapped to
input several characters. Chrome, Firefox and IE (on Windows) agree on
firing keydown, multiple keypress (and multiple textInput if supported),
single keyup.
Suggested text:
liif the key inserts one or more characters, the default action shall be
to dispatch one a class=eventtype
href=#event-type-textInputcodetextInput/code/a event for each
character inserted, with that character as the value of the a
href=#events-TextEvent-datacodeTextEvent.data/code/a attribute
(Leaving aside for a moment the issue that I would also like to replace
textInput with keypress in that text..)
]]
ISSUE-143 (editorial d3e): DOM3 Events section 3 editorial errors [DOM3 Events]
ISSUE-143 (editorial d3e): DOM3 Events section 3 editorial errors [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/143 Raised by: Doug Schepers On product: DOM3 Events Daniel Barclay http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0188.html: [[ In reading the Document Object Model (DOM) Level 3 Events Specification, specifically, the version currently (2010-09-23) at http://www.w3.org/TR/DOM-Level-3-Events/ (Draft 07 September 2010), I noticed a number of mostly editorial errors in Section 2: * Section 2: The definitions are written in two different styles (some in complete-sentence style, some in noun-phrase-only style). They probably should be more consistent. (When you read several in the complete-sentence style and then start reading one without a main verb, your parsing of the (partial) sentence gets thrown off.) * Section 2, dead key: combination of key should be combination of keys * Section 2, dead key: e.g. should be e.g., * Various locations: There are other occurrences of e.g. and of i.e. without the standard following comma. * Section 2, delta: The specification of positive and negative directions still seems to be ambiguous. For example, a mouse wheel is in a vertical plane but has a horizontal axis, so it's not clear whether it would be vertically- aligned device or a horizontally-aligned device. (Although much less so, the reference to the wheel['s being] rotated towards the user is also ambiguous. Ideally at least, it should probably refer to the part of the wheel that the user touches (since other parts move in other directions).) * Section 2, event order: unpaired comma a mousedown event from the trackpad, followed by a mouseup event from the mouse would not result in a click event. should be: a mousedown event from the trackpad, followed by a mouseup event from the mouse, would not result in a click event. or: a mousedown event from the trackpad followed by a mouseup event from the mouse would not result in a click event. * Section 2, event order: in an environment with a a mouse * Section 2, event type: The text says: The name of an event object which defines particular trigger conditions and other characteristics which distinguish it from other event types. Is name of an event object really correct? (It sounds like it's referring to an object as opposed to a type/kind/class of object, and like it's specifically referring to the _name_ of that type as opposed to referring to the type itself (its characteristics).) * Section 3, focus: Each element has different behavior when focused, depending on its functionality, such as priming the element for activation (as for a button or hyperlink) or toggling state (as for a checkbox), receiving text input (as for a text form field), or copying selected text. Are the commas (and occurrences of or) correct? As the text is written, priming and copying are siblings, which doesn't seem right for typical UI behavior (although it does seem like some X11 selection behavior). * Section 3, hysteresis: and no immediately closing a nested menu should be and not ... * Section 3, key value: inconsistent singular vs. plural: Control keys, function keys, modifier keys, dead keys, and others keys always have a key value, whether or not it has a character value. That should probably be: A control key, function key, ... always has (Making is consistently singular will be clearer than the alternative fix of making everything plural.) Section 3, phase: ... along the DOM tree, from the defaultView (window), to the Document object, root element down to the event target (...), at the event target itself (target phase), and back up to the same chain ... Something's not quite right with the wording to the Document object, root element down to the event target section. Maybe that part should be: to the Document object, the root element, and down to the event target Also, shouldn't the wording back up to the same chain be back up the same chain? Section 3, propagation path: .. As the event propagates, each event target in the propagation path shall in turn be set as the Event.currentTarget. ... Shouldn't that shall be will? (Isn't it the case that some other part of the specification specifies that behavior (and needs to use shall), and that the glossary entry should just describe what happens/will happen with will? (The rest of the glossary entries say what happens, not what must happen). The propagation path is initially comprised of one or more event phases ... (Also see the topmost event target entry.) That is comprised of should be comprises (or is composed of, etc.). (The whole comprises the parts. The whole is not comprised
ISSUE-144 (propagation exceptions): exceptions in handlers during event propagation [DOM3 Events]
ISSUE-144 (propagation exceptions): exceptions in handlers during event propagation [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/144 Raised by: Doug Schepers On product: DOM3 Events Sergey Ilinsky in http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0191.html: [[ How do execution exceptions occurred in handlers during the event propagation affect the event flow? Should the event propagation be stopped, should it continue? Is this specified? ]]
ISSUE-145 (event handler ordering): Ordering event handlers registered by different means [DOM3 Events]
ISSUE-145 (event handler ordering): Ordering event handlers registered by different means [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/145 Raised by: Doug Schepers On product: DOM3 Events Sergey Ilinsky in http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0192.html: [[ Has the issue of ordering execution of handlers added by the following means been addressed? a) node.oneventx = f; b) node.setAttribute(eventx, f) c) node.addEventListener(eventx, f) There is a chance DOM Events is not a right place to specify this behaviour but can the author then make sure this is specified somewhere else so that the modern browsers would implement same behaviour? ]]
ISSUE-146 (capture-phase targets): Capture-phase listeners invoked on targets [DOM3 Events]
ISSUE-146 (capture-phase targets): Capture-phase listeners invoked on targets [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/146 Raised by: Doug Schepers On product: DOM3 Events Sergey Ilinsky in http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0193.html: [[ As far as I know there are modern browsers which handle capture-phase event handlers on targets. Is this behaviour wrong or correct? Is the correct behaviour specified anywhere in the specification? ]]
ISSUE-147 (event re-dispatching): re-dispatching an event that already has its flow started [DOM3 Events]
ISSUE-147 (event re-dispatching): re-dispatching an event that already has its flow started [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/147 Raised by: Doug Schepers On product: DOM3 Events Sergey Ilinsky in http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0194.html: [[ I could not find details regarding if it is legal to call dispatchEvent function with an event object that is already being propagated as its argument. Should this result into exception? ]]
ISSUE-148 (modularize d3e): Consider modularizing DOM3 Events [DOM3 Events]
ISSUE-148 (modularize d3e): Consider modularizing DOM3 Events [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/148 Raised by: Doug Schepers On product: DOM3 Events Garrett Smith in http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0003.html: [[ I think we're all well aware of the monstrosity that has become D3E. D3E should be cut way back; it is too large and too complicated. Individual events and keyboard specificity are not core features; they are details and particulars of specific events. These events should be moved each to a separate specification. Moving specific event specification details to independent specifications will help reveal the real core of DOM 3 Events; so that core can be looked at more closely and independently questioned; e.g. should useCapture be optional and ditto for the extracted/moved event Should we specify keyCode and charCode. To put this idea to action, I suggest starting with the a complicated part of the spec that seems the least core. For example, keyboard events, which itself is about 30 pages long. I would extract that from the spec and move it to another document and see how it reads on its own. If further help is wanted, then a request can be made for an associate editor. ]]
Re: ISSUE-145 (event handler ordering): Ordering event handlers registered by different means [DOM3 Events]
On 10/5/10, Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: ISSUE-145 (event handler ordering): Ordering event handlers registered by different means [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/145 Raised by: Doug Schepers On product: DOM3 Events Sergey Ilinsky in http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0192.html: [[ Has the issue of ordering execution of handlers added by the following means been addressed? a) node.oneventx = f; b) node.setAttribute(eventx, f) c) node.addEventListener(eventx, f) [...] Yes. I explained this in thread event.returnValue, which was filtered out. Then Hallvord reposted to the list and cc'd me, and it was again filtered. Then Hallvord I believe reposted my post with a bcc to me and it made it. The thread (please look it up) explains that order is covered in HTML 5. Garrett
Re: [widgets] Seeking review of Widgets Dig Sig Test Suite
Hi Marcos, especially for widget signing we started the adventure of adding EC support to our signing server and got a little bit suprised by the poor support by the crypto libs. Nevertheless I guess we can track down one of our EC-problems to the ecdsa.cert.pem certificate. Despite using an EC keypair the certificate structure claims to be using sha1WithRSAEncryption . I build a certificate with ( mostly ) the same settings as your original ( but with serial #995 ) and the same keypair. Maybe this will ease the pain of setting up an EC test environment. Greetings Andreas - original Nachricht Betreff: [widgets] Seeking review of Widgets Dig Sig Test Suite Gesendet: Mi, 08. Sep 2010 Von: Marcos Caceresmarc...@opera.com Opera would like to announce the first release of the test suite for the Digital Signatures for Widgets specification [1]. The test suite is here: http://dev.w3.org/2006/waf/widgets-digsig/test-suite/ The WebApps WG is seeking review of the test cases from members of XMLSec and WebApps, the community at large, as well as any vendors who are implementing. The deadline for comment is the 30th of September. We are particularly interested in feedback on the completeness of testing (i.e., have we tested enough? do we need more tests)? Can the test suite actually be run on devices and runtimes? All and any comments are welcomed!:) Please send feedback to public-webapps public-webapps@w3.org Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-digsig/ -- Marcos Caceres Opera Software --- original Nachricht Ende ecdsa_cert_995.pem Description: Binary data
[Bug 10985] New: The sentence The subprotocol names must all be non-empty ASCII strings with no control characters and not spaces in them (i.e. only characters in the range U+0021 to U+007E). shou
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10985 Summary: The sentence The subprotocol names must all be non-empty ASCII strings with no control characters and not spaces in them (i.e. only characters in the range U+0021 to U+007E). should actually read: The subprotocol names must all be non-empty ASCII strin Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#the -websocket-interface OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-websocket-interface Comment: The sentence The subprotocol names must all be non-empty ASCII strings with no control characters and not spaces in them (i.e. only characters in the range U+0021 to U+007E). should actually read: The subprotocol names must all be non-empty ASCII strings with no control characters and no spaces in them (i.e. only characters in the range U+0021 to U+007E). Posted from: 220.235.101.140 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[widget] Draft agenda for 7 October 2010 voice conf
Below is the draft agenda for the October 7 Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged as it can result in a shortened or canceled meeting. Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/09/23-wam-minutes.html -Art Barstow Agenda: 1. Review and tweak agenda 2. Announcements a. October 26 is the deadline for comments re October 5 LCWD of Widget Packaging and Configuration ( http://www.w3.org/TR/2010/WD-widgets-20101005/ ) b. TPAC: widgets group will not meet; registration after October 22 results in increased registration fee ( http://www.w3.org/2010/11/TPAC/#Registration ) 3. Widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. Comment and ensuing thread from Addison Philips: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0728.html 4. URI Scheme spec - status and plans http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ 5. AOB Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 60 minutes max Zakim Bridge:+1.617.761.6200, +33.4.26.46.79.03 or +44.203.318.0479 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/member-bin/irc/irc.cgi Confidentiality of minutes: Public
Re: ISSUE-144 (propagation exceptions): exceptions in handlers during event propagation [DOM3 Events]
On Tue, Oct 5, 2010 at 11:47 PM, Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: ISSUE-144 (propagation exceptions): exceptions in handlers during event propagation [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/144 Raised by: Doug Schepers On product: DOM3 Events Sergey Ilinsky in http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0191.html: [[ How do execution exceptions occurred in handlers during the event propagation affect the event flow? Should the event propagation be stopped, should it continue? Is this specified? ]] Something that would be useful for at least IndexedDB is to at least find out that an exception has been thrown by some event handler. Similar to how you can find out if an event handler has called preventDefault(). If an exception has been thrown by a handler we can expect that the event wasn't properly handled and can take action based on that information. / Jonas
[Bug 10977] Properties should be on prototypes, not on objects, in the ECMAScript binding
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10977 Cameron McCormack c...@mcc.id.au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Cameron McCormack c...@mcc.id.au 2010-10-06 22:41:19 UTC --- And done for exceptions now too: http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.221r2=1.222f=h -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
