WebApps-ACTION-759: Look into next f2f

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-759: Look into next f2f

http://www.w3.org/2008/webapps/track/actions/759

Assigned to: Charles McCathie Nevile

ISSUE-187: Https://github.com/w3c/uievents/issues/20

[Web Applications Working Group Issue Tracker]

ISSUE-187: Https://github.com/w3c/uievents/issues/20

http://www.w3.org/2008/webapps/track/issues/187

Raised by: 
On product: 

WebApps-ACTION-758: Ask accesibility people about imes

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-758: Ask accesibility people about imes

http://www.w3.org/2008/webapps/track/actions/758

Assigned to: Charles McCathie Nevile

WebApps-ACTION-757: Collect the various minutes and make them as coherent as the reality of the meeting.

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-757: Collect the various minutes and make them as coherent as 
the reality of the meeting.

http://www.w3.org/2008/webapps/track/actions/757

Assigned to: Charles McCathie Nevile

WebApps-ACTION-756: Make sure webapps has good communication flow with indieui group re editing

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-756: Make sure webapps has good communication flow with indieui 
group re editing

http://www.w3.org/2008/webapps/track/actions/756

Assigned to: Charles McCathie Nevile

WebApps-ACTION-755: Solve the rest of the problems related to robust targeting of changing documents.

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-755: Solve the rest of the problems related to robust targeting 
of changing documents.

http://www.w3.org/2008/webapps/track/actions/755

Assigned to: Robin Berjon

WebApps-ACTION-754: Work with doug and chaals re fuzzy pointers stuff for web annotations wg

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-754: Work with doug and chaals re fuzzy pointers stuff for web 
annotations wg

http://www.w3.org/2008/webapps/track/actions/754

Assigned to: Frederick Hirsch

WebApps-ACTION-753: Find an msdn page that describes this

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-753: Find an msdn page that describes this

http://www.w3.org/2008/webapps/track/actions/753

Assigned to: Travis Leithead

WebApps-ACTION-752: Do edits on file system spec

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-752: Do edits on file system spec

http://www.w3.org/2008/webapps/track/actions/752

Assigned to: Arun Ranganathan

WebApps-ACTION-751: Followup with cameron re pr 27 and the web idl test suite

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-751: Followup with cameron re pr 27 and the web idl test suite

http://www.w3.org/2008/webapps/track/actions/751

Assigned to: Yves Lafon

WebApps-ACTION-750: Deleted the uc in file api that starts with "data should be able to be stored ..."

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-750: Deleted the uc in file api that starts with "data should be 
able to be stored ..."

http://www.w3.org/2008/webapps/track/actions/750

Assigned to: Arun Ranganathan

WebApps-ACTION-749: Start a cfc to publish file api lcwd

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-749: Start a cfc to publish file api lcwd

http://www.w3.org/2008/webapps/track/actions/749

Assigned to: Arthur Barstow

WebApps-ACTION-748: Mark file list as feature @ risk

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-748: Mark file list as feature @ risk

http://www.w3.org/2008/webapps/track/actions/748

Assigned to: Arun Ranganathan

WebApps-ACTION-747: Start a cfc to gut xhr l2 and publish a wg note

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-747: Start a cfc to gut xhr l2 and publish a wg note

http://www.w3.org/2008/webapps/track/actions/747

Assigned to: Arthur Barstow

WebApps-ACTION-745: Followup with simon re running the web workers tests

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-745: Followup with simon re running the web workers tests

http://www.w3.org/2008/webapps/track/actions/745

Assigned to: Arthur Barstow

WebApps-ACTION-746: Determine kris' availability to work on the web messaging and web sockets implemenation reports

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-746: Determine kris' availability to work on the web messaging 
and web sockets implemenation reports

http://www.w3.org/2008/webapps/track/actions/746

Assigned to: Adrian Bateman

WebApps-ACTION-743: Try to find someone to help yves, cam and boris on web idl v1

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-743: Try to find someone to help yves, cam and boris on web idl 
v1

http://www.w3.org/2008/webapps/track/actions/743

Assigned to: Charles McCathie Nevile

WebApps-ACTION-744: Work on moving web idl v1 to rec

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-744: Work on moving web idl v1 to rec

http://www.w3.org/2008/webapps/track/actions/744

Assigned to: Yves Lafon

WebApps-ACTION-742: Re sse test results, followup on the timeouts with the 2 test facilitators

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-742: Re sse test results, followup on the timeouts with the 2 
test facilitators

http://www.w3.org/2008/webapps/track/actions/742

Assigned to: Arthur Barstow

WebApps-ACTION-741: Ask cjk interest group and others about ime (use cases, tests, etc.)

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-741: Ask cjk interest group and others about ime (use cases, 
tests, etc.)

http://www.w3.org/2008/webapps/track/actions/741

Assigned to: Charles McCathie Nevile

WebApps-ACTION-740: Issue a call for test facilitator for ime spec

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-740: Issue a call for test facilitator for ime spec

http://www.w3.org/2008/webapps/track/actions/740

Assigned to: Arthur Barstow

WebApps-ACTION-739: Start a cfc to publish a proposed recommendation of idb

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-739: Start a cfc to publish a proposed recommendation of idb

http://www.w3.org/2008/webapps/track/actions/739

Assigned to: Arthur Barstow

WebApps-ACTION-738: Start a cfc to publish a "gutted" wg note of the fullscreen api

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-738: Start a cfc to publish a "gutted" wg note of the fullscreen 
api

http://www.w3.org/2008/webapps/track/actions/738

Assigned to: Arthur Barstow

WebApps-ACTION-737: Create a new bugzilla component for inner text

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-737: Create a new bugzilla component for inner text

http://www.w3.org/2008/webapps/track/actions/737

Assigned to: Arthur Barstow

WebApps-ACTION-736: Work with adrian to find a replacement tc for alex and d3e

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-736: Work with adrian to find a replacement tc for alex and d3e

http://www.w3.org/2008/webapps/track/actions/736

Assigned to: Arthur Barstow

WebApps-ACTION-735: Check that the d3e tests are in gh or mercurial, and if needed fix

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-735: Check that the d3e tests are in gh or mercurial, and if 
needed fix

http://www.w3.org/2008/webapps/track/actions/735

Assigned to: Travis Leithead

WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note

http://www.w3.org/2008/webapps/track/actions/734

Assigned to: Arthur Barstow

WebApps-ISSUE-182 (OperationNotAllowed): File API introduces a new OperationNotAllowed exception where other specs have an error code [File API]

[Web Applications Working Group Issue Tracker]

WebApps-ISSUE-182 (OperationNotAllowed): File API introduces a new 
OperationNotAllowed exception where other specs have an error code [File API]

http://www.w3.org/2008/webapps/track/issues/182

Raised by: Adrian Bateman
On product: File API

The File API adds an OperationNotAllowed exception with a single 
NOT_ALLOWED_ERR code. [1] Other specs, such as IndexedDB, include 
NOT_ALLOWED_ERR as one code within their existing exception object. [2]

We'd prefer to avoid the overhead of creating a new type just for this error 
and instead add NOT_ALLOWED_ERR as a new code to the existing object in the 
spec.

[1] http://dev.w3.org/2006/webapi/FileAPI/#not-allowed-error
[2] 
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBDatabaseException-NOT_ALLOWED_ERR

WebApps-ISSUE-181 (FileError-Name): Use case for FileError and FileException name attribute [File API]

[Web Applications Working Group Issue Tracker]

WebApps-ISSUE-181 (FileError-Name): Use case for FileError and FileException 
name attribute [File API]

http://www.w3.org/2008/webapps/track/issues/181

Raised by: Adrian Bateman
On product: File API

FileError [1] and FileException [2] both define a DOMString attribute called 
name that contains the name of the error/exception constant as a string. Since 
this is not a useful "human readable" error message, and developers should be 
encouraged to write code that compares against the code attribute, it's not 
clear what the purpose of 'name' is. We'd prefer to remove it.

[1] http://dev.w3.org/2006/webapi/FileAPI/#dfn-nameError
[2] http://dev.w3.org/2006/webapi/FileAPI/#dfn-name-exception

WebApps-ISSUE-179 (DOMException): DOM Core uses INVALID_STATE_ERR (DOMException) where D3E uses DISPATCH_REQUEST_ERR (EventException)

[Web Applications Working Group Issue Tracker]

WebApps-ISSUE-179 (DOMException): DOM Core uses INVALID_STATE_ERR 
(DOMException) where D3E uses DISPATCH_REQUEST_ERR (EventException)

http://www.w3.org/2008/webapps/track/issues/179

Raised by: Jacob Rossi
On product: 

DOM Core uses INVALID_STATE_ERR (DOMException) where D3E uses 
DISPATCH_REQUEST_ERR (EventException). 

ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File API: Writer]

[Web Applications Working Group Issue Tracker]

ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File 
API: Writer]

http://www.w3.org/2008/webapps/track/issues/173

Raised by: Eric Uhrhane
On product: File API: Writer

When a FileWriter successfully completes a write, currently it:
* dispatches a write event
* sets readyState to DONE
* dispatches a writeend event

If you want to start a new write, you can't do it in onwrite, since readyState 
is still WRITING.  Those events should be queued for asynchronous delivery, so 
that readyState is DONE by the time they get handled.  If you set up a new 
write in onwrite, you'll still run the risk of getting confused by the 
subsequent writeend from the previous write, but that's detectable.

I'll have to look and see what other events should be marked as queued.

ISSUE-152: [widgets] P&C test suite needs a few more XML entity cases to check for well-formed XML

[Web Applications Working Group Issue Tracker]

ISSUE-152: [widgets] P&C test suite needs a few more XML entity cases to check 
for well-formed XML

http://www.w3.org/2008/webapps/track/issues/152

Raised by: 
On product: 

ISSUE-151: [widgets] P&C Spec.... If feature-name is not a valid IRI, and required-feature is true, then the user agent must treat this widget as an invalid widget package. but doesnt say anything abo

[Web Applications Working Group Issue Tracker]

ISSUE-151: [widgets] P&C Spec If feature-name is not a valid IRI, and 
required-feature is true, then the user agent must treat this widget as an 
invalid widget package. but doesnt say anything about the case when it is not 
required.

http://www.w3.org/2008/webapps/track/issues/151

Raised by: 
On product: 

ISSUE-150: [widgets] Email and param name and value as 'Keyword attributes' is causing confusion in Widgets P&C Spec

[Web Applications Working Group Issue Tracker]

ISSUE-150: [widgets] Email and param name and value as 'Keyword attributes' is 
causing confusion in Widgets P&C Spec 

http://www.w3.org/2008/webapps/track/issues/150

Raised by: 
On product: 

ISSUE-149 (missing key values): The multiply and other key values are missing [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-149 (missing key values): The multiply and other key values are missing 
[DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/149

Raised by: Doug Schepers
On product: DOM3 Events

Travis Leithead 
:
[[
During implementation of the 'key' and 'char' properties in IE9, we discovered 
that there appears to be a missing key from the Key Values Set (6.2.7).

For the number-pad keys, there are already keys provided in the list in the 
current draft of the spec for:

* "Add"

* "Subtract"

* "Divide"

* "Decimal"

* "Subtract"

However, "Multiply" is missing.

I do not know if this is a deliberate omission because of the text in the final 
paragraph of section 6.2, which says: "due to the lack of a multiplication key 
on many keyboard".

The Windows OS is providing this named key ["Multiply"] to IE, and therefore to 
other browsers as well. I propose that "Multiply" be added to the list of Key 
Value Set.
]]

:
[[
In implementation of IE9's support for the 'key' and 'char' properties of the 
Keyboard event, we found that additional named keys provide char values, which 
are not explicitly called out in the current editor's draft of section 6.2.7.

The subset we have identified so far, which we expect users to want char values 
for are listed below:

key NameChar value
'Add'   +
'Decimal'   .
'Divide'/
'Enter' \n
'Multiply'  *
'Subtract'  -

It is our recommendation that these 'char' values be added to the spec's list 
of Key Values Set.
]]

ISSUE-148 (modularize d3e): Consider modularizing DOM3 Events [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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.
]]

ISSUE-147 (event re-dispatching): re-dispatching an event that already has its flow started [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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-146 (capture-phase targets): Capture-phase listeners invoked on targets [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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-145 (event handler ordering): Ordering event handlers registered by different means [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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-144 (propagation exceptions): exceptions in handlers during event propagation [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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-143 (editorial d3e): DOM3 Events section 3 editorial errors [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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

ISSUE-142 (multiple keypress): one keydown might fire multiple keypress/textInput events [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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:

if the key inserts one or more characters, the default action shall be  
to dispatch one textInput event for each  
character inserted, with that character as the value of the TextEvent.data attribute

(Leaving aside for a moment the issue that I would also like to replace  
textInput with keypress in that text..)
]]

ISSUE-141 (IME examples): IME examples [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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-140 (textInput keydown keypress): textInput event as default action of both keydown and keypress? [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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-139 (clarify key repeat): Define which events repeat when a key is held down [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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-138 (keyboard mapping): Define "keyboard mapping" [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events]

[Web Applications Working Group Issue Tracker]

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 
:
[[
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-136 (getCoordsAt): Consider adding MouseEvent.getCoordsAt(element)

[Web Applications Working Group Issue Tracker]

ISSUE-136 (getCoordsAt): Consider adding MouseEvent.getCoordsAt(element)

http://www.w3.org/2008/webapps/track/issues/136

Raised by: Doug Schepers
On product: 

Jonathan Watt 
:
[[
Background:

Positioning elements based off the position of a pointer event is regularly
tripping people up in SVG, and with the advent of CSS-transforms, I imagine also
in HTML.

To position an element based off the position of a pointer event you need to get
the coordinates of the event in the local coordinate system of the element. To
do that currently authors have to get the *correct* element-to-root transform,
invert it, create an SVGPoint, copy the event coordinates to the SVGPoint, then
use the inverted transform to transform the point and read back the coordinates.
For something so simple, it's not obvious that this is what you need to do, or
even how to do it.

Proposal:

To make life easier for authors I'd like to propose the addition of a
'getCoordsAt' method to the MouseEvent interface. This method would be passed
the element at which the local coordinates of the event are required, and return
an object implementing the SVGPoint interface[1] (or a new interface
implementing 'x' and 'y' properties).

I've uploaded a JavaScript implemented demo of this method here:

  http://jwatt.org/svg/tmp/mouse-relative-positioning.svg

See also the comments in the source code.
]]

[[
// This is a demonstration of getCoordsAt() - a proposed addition to the DOM
// interface 'MouseEvent' - that would save authors from having to work with
// matrices when positioning elements based on the location of a pointer event.
//
// This file demonstrates getCoordsAt for SVG only, but it would be just as
// useful in HTML, especially with the advent of CSS-transforms.

// JavaScript implementation of getCoordsAt for SVG:
 
if (!MouseEvent.prototype.getCoordsAt) {
  MouseEvent.prototype.getCoordsAt = function(element) {
var SVGNS = 'http://www.w3.org/2000/svg';
var svg = document.createElementNS(SVGNS, 'svg');
var pt = svg.createSVGPoint();
pt.x = this.clientX;
pt.y = this.clientY;
return pt.matrixTransform(element.getScreenCTM().inverse());
  }
}
]]

ISSUE-135 (DOMAttributeChangeRequestEvent): Consider adding DOMAttributeChangeRequestEvent

[Web Applications Working Group Issue Tracker]

ISSUE-135 (DOMAttributeChangeRequestEvent): Consider adding 
DOMAttributeChangeRequestEvent

http://www.w3.org/2008/webapps/track/issues/135

Raised by: Doug Schepers
On product: 

James Craig :
[[
The following proposal is for consideration by the PF Working Group, DOM 
Working Group, and HTML Working Group. It specifically solves a few outstanding 
accessibility problems, but has much broader implications, and could affect 
several recommendations, including ARIA 2, DOM 3, and HTML 5. (Note: duplicate 
emails are going out to a few relevant lists.)
]]

:
[[
I have not received any response to this from the DOM group, and because DOM 3 
has moved to Last Call, I want to make sure it's clear that this proposal was 
intended, in part, as an alternative for the deprecated DOMAttrModified in DOM 
3. 

See DOMAttributeChangeRequestEvent, but please read it in the context of the 
larger document.
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html#DOMAttributeChangeRequestEvent
]]

ISSUE-134 (optional useCapture): Consider making useCapture parameter of add/removeEventListener optional [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-134 (optional useCapture): Consider making useCapture parameter of 
add/removeEventListener optional [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/134

Raised by: Doug Schepers
On product: DOM3 Events

Sergey Ilinsky 
:
[[
There are modern browsers that made 3rd argument in the
addEventListener/removeEventListener be optional. Is this a legal step?
If I understand correctly, specification requires 3rd argument to be passed,
thus the new behaviour not backed by the change
in specification only destabilizes web as a platform.

Personally, I like the behaviour, but cannot use it as long as not every
browser does that.
]]

ISSUE-133 (keyCode and charCode): Consider specifying keyCode and charCode [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-133 (keyCode and charCode): Consider specifying keyCode and charCode 
[DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/133

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
Please specify keyCode and charCode, even if marked as 'obsolete'. I'm  
pretty sure no browser is going to ship without at least one of them. (I  
notice that charCode is undefined in Opera, keyCode always returns 0 in  
Firefox, and in WebKit they both work.)
]]

ISSUE-132 (event.returnValue): Consider adding event.returnValue [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-132 (event.returnValue): Consider adding event.returnValue [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/132

Raised by: Doug Schepers
On product: DOM3 Events

Hallvord R. M. Steen 
:
[[
IE lets you prevent the default action of an event by setting  
event.returnValue to false. Since both Opera and WebKit support this  
property it might be a good idea to standardise it?
]]

ISSUE-131 (defaultView load ): Define load event to fire on defaultView [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-131 (defaultView load ): Define load event to fire on defaultView [DOM3 
Events]

http://www.w3.org/2008/webapps/track/issues/131

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
{
Note: for legacy reasons, the load event does not propagate to the
defaultView in HTML implementations.
}

It's *fired* on the defaultView in HTML implementations, as specified in
HTML5.

]]

ISSUE-130 (Web IDL): Consider using Web IDL for the IDL fragments [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-130 (Web IDL): Consider using Web IDL for the IDL fragments [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/130

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
I think this specification should use WebIDL for the IDL fragments.
]]

ISSUE-129 (event constructors): Revist event constructors [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-129 (event constructors): Revist event constructors [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/129

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
An idea for creating events is to support [Constructor] on all event  
IDLs, which makes the createEvent method unnecessary.

Maybe we could even make the arguments to the constructor be called to  
initFooEvent() directly, so instead of doing

var e = document.createEvent('MouseEvents');
e.initMouseEvent('click', ...);
foo.dispatchEvent(e);

you could do

foo.dispatchEvent(new MouseEvent('click', ...))

Another thing we could change is to make all but the first arguments to  
initFooEvent() optional and let them have sensible defaults, so that if  
all you care about is the event type, you can include just the first  
argument.

If the constructor is called with no arguments, then initFooEvent() would  
not be called.
]]

ISSUE-128 (preventDefault): Define preventDefault to account for pre-propagation default actions [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-128 (preventDefault): Define preventDefault to account for 
pre-propagation default actions [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/128

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
The definition of preventDefault does not talk about default actions that
happen before the event propagation (like 'change' on checkboxes).
]]

ISSUE-127 (cancelBubble / srcElement): Consider adding cancelBubble and srcElement [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-127 (cancelBubble / srcElement): Consider adding cancelBubble and 
srcElement [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/127

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
Looking at [6], I notice that Opera and WebKit have cancelBubble and
srcElement. WebKit and Gecko have more constants on Event.

[6] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/611

]]

ISSUE-126 (isTrusted): Consider changing 'trusted' to 'isTrusted' [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-126 (isTrusted): Consider changing 'trusted' to 'isTrusted' [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/126

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
Gecko has a property called isTrusted that does the same as trusted, and
seems to be used in the wild. [4][5] Please rename trusted to isTrusted.

[4] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/610
[5] http://www.google.com/codesearch?q=event%5C.isTrusted+lang%3Ajs

]]

ISSUE-125 (DOM Views): Consider dropping DOM Views reference for HTML5 defaultView [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-125 (DOM Views): Consider dropping DOM Views reference for HTML5 
defaultView [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/125

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
{
The defaultView is an object which implements the AbstractView interface
of the Document's DocumentView interface, which serves as a reference to
the containing frame or window.
}

I think the idea is to drop support for DOM Views. HTML5 has added
defaultView on the Window interface. 
 http://html5.org/tools/web-apps-tracker?from=4947&to=4948
]]

ISSUE-124 (reword examples): Remove RFC2119 keywords from examples [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-124 (reword examples): Remove RFC2119 keywords from examples [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/124

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
RFC2119 keywords in examples is bad style. Please replace RFC2119 keywords
in non-normative sections and examples with other words.
]]

ISSUE-123 (feature strings): Rationale for feature strings [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-123 (feature strings): Rationale for feature strings [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/123

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters 
:
[[
What's the use case for extended feature strings for event types
(hasFeature('Events.click', ''))? Opera, WebKit and Gecko don't support
this. [1]

What's the use case for feature strings for event interfaces
(hasFeature('KeyboardEvent', '') or hasFeature('Events.KeyboardEvent'))?
The spec says it's for backwards compatibility, but Opera, WebKit and
Gecko don't support this. [2] It's easier to test for event interfaces by
checking if the interface object exists as a property on the global
object, i.e. window.KeyboardEvent. (Opera currently doesn't expose
KeyboardEvent on window, but that's something we should fix.)

]]

ISSUE-122 (add mousewheel): Consider adding 'mousewheel' again [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-122 (add mousewheel): Consider adding 'mousewheel' again [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/122

Raised by: Doug Schepers
On product: DOM3 Events

Defining the 'mousewheel' event and interface was an early decision by the 
group, and this was specified along with the 'wheel' event and interface, and a 
detailed description of the interactions between the two.  

'mousewheel' was later dropped based on feedback from implementers (Mozilla, 
Microsoft), who expressed a reluctance to implement 'mousewheel', and a lack of 
useful interoperability and concern that any change to improve interop would 
likely break a number of sites.

However, the group may wish to consider adding it again, see:
* http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0103.html

ISSUE-121 (beforeInput): Consider generalizing the 'textInput' event to cover all user-initiated changes [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-121 (beforeInput): Consider generalizing the 'textInput' event to cover 
all user-initiated changes [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/121

Raised by: Doug Schepers
On product: DOM3 Events

>From  by 
>Ojan Vafai:
[[
I don't see the need for a textInput event if we have the beforeInput event.
They are exactly the same except that beforeInput covers more cases. Stated
differently, textInput is a strict subset of beforeInput, so if we implement
beforeInput, we don't need textInput. Developers that only care about
character data can check the value of the data property and get the same
effect.

The changes are actually not that dramatic in my view:
1. Add more cases to the list of InputMethodCodes:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-ID-TextEvent-InputMethodCode
2. Rename the event
3. Modify the text under
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-textevents
 to change from talking about "text input" to something like "anytime the user 
causes the DOM to be modified".
4. Modify
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-TextEvent-data
 to specify that the data property is the empty string for inputMethods that do 
not insert plain text.
]]

ISSUE-120 (scroll basic event): Consider returning 'scroll' from UIEvent to Event interface [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-120 (scroll basic event): Consider returning 'scroll' from UIEvent to 
Event interface [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/120

Raised by: Doug Schepers
On product: DOM3 Events

'scroll' was moved from the Event interface to the UIEvent interface, so 
UIEvents are grouped logically and are detectable as such for script library 
use.  This is a proposal to change it back to the Event interface, since the 
additional .detail and .view properties are not needed:

* http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0074.html

ISSUE-119 (input/keyboard locale): Consider adding input/keyboard locale to text and keyboard events [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-119 (input/keyboard locale): Consider adding input/keyboard locale to 
text and keyboard events [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/119

Raised by: Doug Schepers
On product: DOM3 Events

This is a proposal for a new 'locale' property on the TextEvent and 
KeyboardEvent
interfaces, indicating the locale of the keyboard or other input device used to 
input text.

See these messages on the thread:
* http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0024.html
* http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0104.html
* http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0114.html

ISSUE-118 (dispatchEvent links): Consider allowing dispatchEvent for generic event duplication for links [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-118 (dispatchEvent links): Consider allowing dispatchEvent for generic 
event duplication for links [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/118

Raised by: Doug Schepers
On product: DOM3 Events

Simon Pieters wrote in 
 :
[[
Is it defined what should happen in the following case?

click me
http://example.org/";>test

It seems Firefox and Opera throw an exception, while WebKit allows the event to 
be dispatched.

I think it seems like a neat thing to be able to do, for making table rows or 
 clickable. (However the event shouldn't be a 'trusted' event in that 
case, of course.) To make it work today you'd have to create a new event and 
copy over all properties, which is annoying.
]]

ISSUE-117: In Widget P&C Spec, need to clarify in the spec that dir attribute does not apply to attributes that are IRIs, Numeric, Keywords, etc. The dir attribute only affects human readable strings.

[Web Applications Working Group Issue Tracker]

ISSUE-117: In Widget P&C Spec, need to clarify in the spec that dir attribute 
does not apply to attributes that are IRIs, Numeric, Keywords, etc. The dir 
attribute only affects human readable strings.

http://www.w3.org/2008/webapps/track/issues/117

Raised by: 
On product: 

ISSUE-116: Need to flesh out the security considerations for the openURL method in the Widget Interface spec

[Web Applications Working Group Issue Tracker]

ISSUE-116: Need to flesh out the security considerations for the openURL method 
in the Widget Interface spec

http://www.w3.org/2008/webapps/track/issues/116

Raised by: 
On product: 

ISSUE-115 (xhr-referer): XHR does not specify what URL to use for Referer [XHR]

[Web Applications Working Group Issue Tracker]

ISSUE-115 (xhr-referer): XHR does not specify what URL to use for Referer [XHR]

http://www.w3.org/2008/webapps/track/issues/115

Raised by: Maciej Stachowiak
On product: XHR

XHR does not specify what URL to use for Referer. HTML5 specifies this in the 
Resource Fetch algorithm, but XHR does not use that. This should be specified, 
and in particular if the XHR is being made with a unique identifier origin it 
should not send a referer at all.

ISSUE-114 (CORS-credentials): CORS does not define the effect of the credentials flag in sufficient detail [CORS]

[Web Applications Working Group Issue Tracker]

ISSUE-114 (CORS-credentials): CORS does not define the effect of the 
credentials flag in sufficient detail [CORS]

http://www.w3.org/2008/webapps/track/issues/114

Raised by: Maciej Stachowiak
On product: CORS

It looks like the only actual statement about the effect of the credentials 
flag is:

"Whenever the make a request steps are applied, make a request to request URL, 
using method request method, entity body request entity body, including the 
custom request headers, and include credentials if the credentials flag is true 
(e.g. HTTP authentication data and cookies)."

There's two problems with this:

(1) It's not normatively defined what constitutes a credential.
(2) It says to include credentials when the credentials flag is true, but it 
doesn't say they must not be included when the credentials flag is false.

I think the credentials flag should specifically affect cookies, http 
authentication, and client-side SSL certs, but not proxy authentication (or, 
obviously, Origin). 

ISSUE-113 (resize): Clarify when resize events fire [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-113 (resize): Clarify when resize events fire [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/113

Raised by: Doug Schepers
On product: DOM3 Events

Emails:
 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1017.html
 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1061.html
 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1248.html

Bugs:
 https://bugzilla.mozilla.org/show_bug.cgi?id=227495
 https://bugs.webkit.org/show_bug.cgi?id=17969

ISSUE-111 (mouse z): Add z attribute to mouse events? [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-111 (mouse z): Add z attribute to mouse events? [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/111

Raised by: Doug Schepers
On product: DOM3 Events

With CSS and SVG both adding 3D (2.5D) transformations to the language, with a 
position on the z-axis, there may well be cause to add z/tz/clientZ attributes 
to mouse events along with the traditional x and y attributes.  This would 
return the element's z-position, with a default of 0, in case there are any z 
transforms applied to the element.

Note that the z-axis position is different than z-index.

ISSUE-110 (code-point conversion): Should we remove the code-point conversion from the D3E spec? [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-110 (code-point conversion): Should we remove the code-point conversion 
from the D3E spec? [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/110

Raised by: Charles McCathieNevile
On product: DOM3 Events

The suggestion is that the conversion from character to codepoint doesn't 
belong in DOM 3 Events, since it needs to be available all over the place and 
is either a short bit of JS code, or should be fixed deeper in the language.

ISSUE-108: confused deputy problem [CORS]

[Web Applications Working Group Issue Tracker]

ISSUE-108: confused deputy problem [CORS]

http://www.w3.org/2008/webapps/track/issues/108

Raised by: Anne van Kesteren
On product: CORS

See http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html and 
follow up. Also see minutes of Santa Clara F2F.

ISSUE-107 (multi-object end events): End state events in multi-object transactions [Progress Events]

[Web Applications Working Group Issue Tracker]

ISSUE-107 (multi-object end events): End state events in multi-object 
transactions [Progress Events]

http://www.w3.org/2008/webapps/track/issues/107

Raised by: Charles McCathieNevile
On product: Progress Events

Where a transaction has multiple objects (i.e. there is a loadedItems attribute 
present, and a value other than 1 for totalItems), should the end events 
(load/abort/error be fired for each object, or only on the completion of the 
entire transaction?

I am assuming loadend should only fire at the end of the complete transaction 
(that might be a dumb assumption) but my current thinking is that it makes 
sense to fire a final event for each transaction (for example to learn what 
happened to each object, potentially allowing a request for only those that 
didn't come through cleanly the first time.

For now this is left open in the editor's draft.

ISSUE-106 (mouse capture): Consider adding mouse capture/release API [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-106 (mouse capture): Consider adding mouse capture/release API [DOM3 
Events]

http://www.w3.org/2008/webapps/track/issues/106

Raised by: Doug Schepers
On product: DOM3 Events

It's sometimes desirable to redirect all events of a certain type to a 
particular element (for example, when dragging a scrollbar or a shape, you may 
want to allow the mousemove events to all be directed to that element).

To do this, IE implements SetCapture, ReleaseCapture, and GetCapture:
* http://msdn.microsoft.com/en-us/library/ms646262%28VS.85%29.aspx
* http://msdn.microsoft.com/en-us/library/ms646261%28VS.85%29.aspx
* http://msdn.microsoft.com/en-us/library/ms646257%28VS.85%29.aspx

Mozilla has recently added this as well:
 http://enndeakin.wordpress.com/2009/08/27/mouse-capturing/

We should consider adding this to DOM3 Events or DOM4 Events.

ISSUE-105 (what is loading?): How should we count progress of things which are not measured in bytes? [Progress Events]

[Web Applications Working Group Issue Tracker]

ISSUE-105 (what is loading?): How should we count progress of things which are 
not measured in bytes? [Progress Events]

http://www.w3.org/2008/webapps/track/issues/105

Raised by: Charles McCathieNevile
On product: Progress Events

HTML 5 wants to count some file transfers using progress events. There are 
various UI components around that do that already. So should we have a flag or 
attribute that says what is being counted and keep using the total/loaded 
attributes, or should we have new atributes for this?

ISSUE-104: supporting structured clones [XHR2]

[Web Applications Working Group Issue Tracker]

ISSUE-104: supporting structured clones [XHR2]

http://www.w3.org/2008/webapps/track/issues/104

Raised by: Anne van Kesteren
On product: XHR2

It would be nice to support the HTML5 concept of structured clones for both 
sending and receiving. Prerequisite of that is getting a serialization format 
defined and preferably some kind of media type for it. (I think this would be 
better than supporting JSON.)

ISSUE-103: accessing status/statusText/getResponseHeader()/getAllResponseHeaders() [XHR]

[Web Applications Working Group Issue Tracker]

ISSUE-103: accessing 
status/statusText/getResponseHeader()/getAllResponseHeaders() [XHR]

http://www.w3.org/2008/webapps/track/issues/103

Raised by: Anne van Kesteren
On product: XHR

After invoking abort() Internet Explorer throws for getting these members as 
per the specification. (And probably also in general when no request has been 
made yet.)

Firefox apparently does not. Someone from WebKit conveyed to me that they would 
like to change to match Firefox.

I personally have these requirements:

a) All implementations should end up doing the same in the end.
b) I would like to know exactly what needs to be changed in the current 
specification so there is a lot less chance of me making a mistake.

Of course, all of this depends on everyone agreeing with changes being needed 
in the first place.

ISSUE-102 (focus and focus()): Behavior of focus events when interacting with focus()/blur() methods needs to be defined [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-102 (focus and focus()): Behavior of focus events when interacting with 
focus()/blur() methods needs to be defined [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/102

Raised by: Doug Schepers
On product: DOM3 Events

Boris Zbarsky wrote 
: 
[[
Jacob Rossi wrote:
> Yes, so in response to that action, here's how IE handles focus events:
> 
> focus, blur, focusin, and focusout can be registered on any element which is 
> "focusable."
> 
> During a focus change from elementA to elementB, the following events are 
> fired in this order:
> 
> 1. focusout:   srcElement is elementA, toElement is elementB, bubbles, not 
> cancelable
> 2. focusin:  srcElement is elementB, fromElement is elementA, bubbles, not 
> cancelable
> 3. Focus changes from elementA to elementB
> 4. blur: srcElement is elementA, does not bubble, not cancelable
> 5. focus: srcElement is elementB, does not bubble, not cancelable

That's a great start (assuming we want to spec focusout/focusin).  We 
also need to spec what happens if a handler during any of steps 1, 2, 4, 
5, calls focus() or blur() on some element (possible cases being 
elementA, elementB, elementC).  That's been by far the biggest source of 
compatibility problems we've run into with Gecko.
]]



Jacob Rossi wrote 
:
[[
On 9/15/09 4:21 PM, Travis Leithead wrote:
> Do we really need eventTarget? It seems to me that focusin/focusout can 
> remain UIEvents, and if web developers want to know what the "releatedTarget" 
> is, then can simply register for both: focusout is the element loosing focus, 
> focusin is the element gaining focus. You don't even have to know which Node 
> to register them on because these events bubble, you can simply listen at the 
> document level.

It's likely that one *could* solve this problem by listening to both.
But for complex systems it could get nasty simply because these events
don't fire concurrently.

In other words, for a single code path that needs to know both the
source and the destination of the focus change, your code would have
to save the target of the focusout event, wait for the focusin event,
and then proceed through the code path. While this is certainly
doable, it's much more elegant and straight forward to be able to just
grab both targets in during one event. (Also, see how the scenario
below might complicate this further.)

On Tue, Sep 15, 2009 at 4:02 PM, Doug Schepers  wrote:
> In fact, it's worth thinking about changing focusin and focusout to be
> cancelable, to prevent the focus from changing.  I doubt there is any
> content that relies on them not being cancelable... what would people think
> of this idea?

My last email (http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0321.html)
had the wrong quote above it at the end. It was supposed to be the one
above. I was worried about the ability to trap focus. But I suppose
this is already possible with the ability to call focus() or blur().
This leads me to my next question:

What is the firing order when the focus is redirected during the focus
change (either if you can cancel the focusin event or by calling
focus( ) or blur() )? Example:

1. The focus is on element A
2. focusout fires on element A
3. focusin fires on element B Note: the focus hasn't actually changed yet.
3.1   A listener for focusin calls focus( ) on another element (element C)

At this point, which events fire and in what order?
I can see 2 possible options:

a) Simply redirect where the focus is going and fire the following events:
 4.  focusin on element C
 5.  Move focus to C
 6.  Blur on A
 7. Focus on C

b) Assume that focus() effectively cause  stopImmediatePropagation
to happen. Now start a new focus change:
   4. focusout fires on element A
   5. focusin fires on element C
   6. Focus moves to C
   7. Blur on A
   8. Focus on C

Which option you pick could depend on whether the event object has a
relatedTarget on it. If it does not, then you can get away with option
(a) because  there's no need to refire focusout on A because you'd
effectively be firing the same event your fired in step 2 again. If it
does, then you probably need option (b) because you need to fire
focusout with relatedTarget set to element C.

Furthermore, how does this order change if focus() is instead called
during a listener of the focusin event? during the blur event? during
the focus event?
]]

ISSUE-101 (Marcin Hanclik): Event's generation [ViewModes]

[Web Applications Working Group Issue Tracker]

ISSUE-101 (Marcin Hanclik): Event's generation [ViewModes]

http://www.w3.org/2008/webapps/track/issues/101

Raised by: Marcin Hanclik
On product: ViewModes

Should the events [1] be triggered before or after the actual values change?
  (implies naming "change" vs. "changed")

[1] http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html

ISSUE-100 (Marcin Hanclik): Event's bubbling and cancelation [ViewModes]

[Web Applications Working Group Issue Tracker]

ISSUE-100 (Marcin Hanclik): Event's bubbling and cancelation [ViewModes]

http://www.w3.org/2008/webapps/track/issues/100

Raised by: Marcin Hanclik
On product: ViewModes

Should the view modes interfaces' [1] events bubble and be cancelable?
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0230.html

[1] http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html

ISSUE-99 (listen): Add shorter method names for addEventListener, et al? [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-99 (listen): Add shorter method names for addEventListener, et al? [DOM3 
Events]

http://www.w3.org/2008/webapps/track/issues/99

Raised by: Doug Schepers
On product: DOM3 Events

Alex Russell suggests that since addEventListener() and removeEventListener() 
are so commonly used, it would be good to add a lump of syntactic sugar by 
aliasing them with shorter names: listen() and unlisten().  He also suggests 
adding listenOnce() as a further shortcut method:

ISSUE-98 (Relation to DOM3Events): Cargo-culting [ViewModes]

[Web Applications Working Group Issue Tracker]

ISSUE-98 (Relation to DOM3Events): Cargo-culting [ViewModes]

http://www.w3.org/2008/webapps/track/issues/98

Raised by: Marcin Hanclik
On product: ViewModes

Should we enable creation of the events with initXXXEvent [NS] methods?
May/Shall the event's instances be modified?
Discuss with www-dom.

Discussion initiated with:
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0218.html

ISSUE-97 (ViewModes vs. CSSOM): How is ViewModes DOM related to CSSOM? [ViewModes]

[Web Applications Working Group Issue Tracker]

ISSUE-97 (ViewModes vs. CSSOM): How is ViewModes DOM related to CSSOM? 
[ViewModes]

http://www.w3.org/2008/webapps/track/issues/97

Raised by: Marcin Hanclik
On product: ViewModes

Should we relate ViewModes to CSSOM [http://dev.w3.org/csswg/cssom/]?

ISSUE-96 (Split of the specification): Should we split the ViewModes specification? [ViewModes]

[Web Applications Working Group Issue Tracker]

ISSUE-96 (Split of the specification): Should we split the ViewModes 
specification? [ViewModes]

http://www.w3.org/2008/webapps/track/issues/96

Raised by: Marcin Hanclik
On product: ViewModes

There seems to be architectural inconsistency regarding what is specified where.
More details in the mail thread:
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0764.html

ISSUE-95: P&C CR: Conformance checker behavior intermixed with UA behavior [Widgets]

[Web Applications Working Group Issue Tracker]

ISSUE-95: P&C CR: Conformance checker behavior intermixed with UA behavior 
[Widgets]

http://www.w3.org/2008/webapps/track/issues/95

Raised by: Marcos Caceres
On product: Widgets

On 11-Aug-2009, Marcos raised this Issue against the 23-July-2009 P&C CR:

 http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0552.html

ISSUE-94: P&C CR: Try to fallback to default start files when src path is invalid or not existing [Widgets]

[Web Applications Working Group Issue Tracker]

ISSUE-94: P&C CR: Try to fallback to default start files when src path is 
invalid or not existing [Widgets]

http://www.w3.org/2008/webapps/track/issues/94

Raised by: Marcos Caceres
On product: Widgets

On 31-July-2009, Marcos raised this Issue against the 23-July-2009 P&C CR:

 http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0453.html

ISSUE-93: P&C CR: deprecated, grandfathered, and redundant tags should be skipped [Widgets]

[Web Applications Working Group Issue Tracker]

ISSUE-93: P&C CR: deprecated, grandfathered, and redundant tags should be 
skipped [Widgets]

http://www.w3.org/2008/webapps/track/issues/93

Raised by: Marcos Caceres
On product: Widgets

On 31-July-2009, Marcos raised this Issue against the 23-July-2009 P&C CR:

 http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0452.html

ISSUE-91: Origin and redirects [CORS]

[Web Applications Working Group Issue Tracker]

ISSUE-91: Origin and redirects [CORS]

http://www.w3.org/2008/webapps/track/issues/91

Raised by: Anne van Kesteren
On product: CORS

In

  http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1000.html

Anne van Kesteren raises the issue whether the Origin header should expose 
information about the request redirect trail. More information can be found in 
that email. (And presumably the thread that follows, if any.)

ISSUE-90: Exposing more (~infinite) response headers [CORS]

[Web Applications Working Group Issue Tracker]

ISSUE-90: Exposing more (~infinite) response headers [CORS]

http://www.w3.org/2008/webapps/track/issues/90

Raised by: Anne van Kesteren
On product: CORS

In

  http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0967.html

Mark Nottingham comments on the asymmetry of exposing the body of the response 
but only a tiny subset of the headers. He argues for

 * Expanding this whitelist and
 * Giving responses of resources a way to indicate which headers are ok to 
expose

or

 * Turning it into a blacklist

He indicated he was not satisfied deferring this issue to CORS2 and considers 
it a showstopper for CORS1.

ISSUE-89: Reduce the length of the header names? [CORS]

[Web Applications Working Group Issue Tracker]

ISSUE-89: Reduce the length of the header names? [CORS]

http://www.w3.org/2008/webapps/track/issues/89

Raised by: Anne van Kesteren
On product: CORS

In

  http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0643.html

Mark Nottingham suggests that we rename the headers used in the protocol as 
such:

 * CORS-Allow-Origin
 * CORS-Max[-A]ge
 * CORS-Allow-Cred
 * CORS-Allow-Methods
 * CORS-Allow-Headers
 * CORS-Method
 * CORS-Headers

I have explained that we have shipping implementations already, but Mark 
suggests there could be some grace period where implementations support both.

ISSUE-87 (wheel targets): Target node types for mousewheel/mousemultiwheel events [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-87 (wheel targets): Target node types for mousewheel/mousemultiwheel 
events [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/87

Raised by: Doug Schepers
On product: DOM3 Events

Per Sergey Ilinsky 
:
[[
According to overview of event types 
http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTypes-complete 
the Document node is a valid target for mousewheel/mousemultiwheel events. 
However, this seems to be wrong to me since other MouseEvent interface events 
do not have Document as valid target and mousewheel event is not different from 
them either (consider mousemove). 
]]

ISSUE-86 (rewrite-suggestion): Consider splitting out events and rewriting definitions [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-86 (rewrite-suggestion): Consider splitting out events and rewriting 
definitions [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/86

Raised by: Doug Schepers
On product: DOM3 Events

Ian Hickson, per http://krijnhoetmer.nl/irc-logs/whatwg/20090325#l-147 :
[[
i'd recommend splitting out the events into a separate doc that actually 
defines when they fire, i'd recommend rewriting all the dom api definitions to 
actually be phrased as requirements not descriptions, and i'd suggest making 
everything be defined in terms of the event loop mechanism
]]

ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]

[Web Applications Working Group Issue Tracker]

ISSUE-85 (clipops security practice): What are common sucrity practices for 
Clipboard APIs? [Clipboard Operations]

http://www.w3.org/2008/webapps/track/issues/85

Raised by: Charles McCathieNevile
On product: Clipboard Operations

What are the common security restrictions and considerations that should be 
listed in the clipboard apis spec?

ISSUE-84 (Read-only cutting): Should cut work like copy on read-only content? [Clipboard Operations]

[Web Applications Working Group Issue Tracker]

ISSUE-84 (Read-only cutting): Should cut work like copy on read-only content? 
[Clipboard Operations]

http://www.w3.org/2008/webapps/track/issues/84

Raised by: Charles McCathieNevile
On product: Clipboard Operations

What should happen when a user tries to cut a piece of content that is 
read-only?

ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]

[Web Applications Working Group Issue Tracker]

ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not 
be able to read digital signature [Widgets]

http://www.w3.org/2008/webapps/track/issues/83

Raised by: Mark Priestley
On product: Widgets

Need to mention somewhere that the digital signature must not be accessible by 
the start file once the widget is running.

ISSUE-82 (Access element naming conflict): potential conflict between the XHTML and Widget element [Widgets]

[Web Applications Working Group Issue Tracker]

ISSUE-82 (Access element naming conflict): potential conflict between the XHTML 
 and Widget  element [Widgets]

http://www.w3.org/2008/webapps/track/issues/82

Raised by: Doug Schepers
On product: Widgets

In [4], Doug Schepers identified a potential conflict between the  
element defined in the Widgets 1.0: Packaging and Configuration specification 
[1] and the  element defined in the XHTML Access Module specification 
[2] (most recent draft also available [3]).

[1] http://www.w3.org/TR/widgets/#the-access-element
[2] http://www.w3.org/TR/xhtml-access/#sec_3.1.
[3] http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081023/
[4] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0507.html

ISSUE-81: ECDSAwithSHA256 as required algorithm in place of DSAwithSHA256? [Widgets]

[Web Applications Working Group Issue Tracker]

ISSUE-81: ECDSAwithSHA256 as required algorithm in place of DSAwithSHA256?  
[Widgets]

http://www.w3.org/2008/webapps/track/issues/81

Raised by: Frederick Hirsch
On product: Widgets

During the 12-Feb-2009 widgets voice conference, Frederick raised this issue:

[[


ECDSAwithSHA256 as required algorithm in place of DSAwithSHA256? related to XML 
Signature 1.1 outcome as well
]]

ISSUE-80: Runtime localization model for widgets [Widgets]

[Web Applications Working Group Issue Tracker]

ISSUE-80: Runtime localization model for widgets [Widgets]

http://www.w3.org/2008/webapps/track/issues/80

Raised by: Josh Soref
On product: Widgets

Below is a discussion I had with Josh about the localization model for
widgets. Josh identifies an issue that may affect localization at
runtime that may be overcome by having the widget engines dynamically
change folders when it can't find resources.

timeless.b...@gmail.com:  how do localized folders work anyway?
 Sent at 12:01 AM on Sunday
 timeless.b...@gmail.com:  oh, it's hidden in 
 me:  you put folders that follow the "lang-place" pattern into a
folder called "locale". The UA looks for a folder that matches the
user's locale prefs
 timeless.b...@gmail.com:  i'm not quite sure i understand or like that
imagine i have 100 images
and only want to localize 2
if base-folder means that i have to copy the whole set, i'm unhappy
 me:  no, just make all your refs absolute. it's no problem
 timeless.b...@gmail.com:  no, definitely bad
that means i have to know in advance if i need to localize a path
instead of just having 1 locale that needs to localize a file
 me:  yes. But it supports multiple models of localization. So the
model is quite flexible.
 timeless.b...@gmail.com:  supporting a virtual mapping would have
been better :(
 me:  we can always change it if you have a better proposal
 timeless.b...@gmail.com:  i guess the simplest question is would you
ever have a localized file foo.bar and want access to the original
unlocalized file
 timeless.b...@gmail.com:  i claim no
 me:  no, you wouldn't
the idea is that you only localize what you want.
 timeless.b...@gmail.com:  yeah
so, in my model, instead of 'base folder'
a localized file i18n/en-GB/index.html appears as /index.html if the
UA selects en-GB
 me:  I'm sure we are thinking of the same thing here, but now I'm
worried I've done this wrong.
 timeless.b...@gmail.com:  (so searches go first to i18n/en-GB/ and then to /)
if index.html has 
 me:  flag.png gets resolved to  i18n/en-GB/flag.png
 timeless.b...@gmail.com:  then whether it's /index.html, or
/i18n/fr-FR/index.html if the UA locale is fr-FR, it first looks in
/i18n/fr-FR/flag.png and then /flag.png
yeah, but that's not what i want
it's a disaster
 me:  no, it only goes to one location
 timeless.b...@gmail.com:  yeah, that sucks.
you end up w/ millions of included files in dozens of locales
because only one needed an override
or you have to fork each html file just to make something happy
 me:  hmmm
I'm not convinced... I thought I had sorted this out
I need to do some tests
 timeless.b...@gmail.com:  we have a VFS, and our UA has a cache,
which means having it try two paths won't hurt
(and it's a readonly VFS, so if  i do  and
my locale doesn't have /i18n/fr-FR/images/, then the UA can skip the
check for the file there and go straight to /images/flag.png
 Sent at 12:12 AM on Sunday
 timeless.b...@gmail.com:  basically, when people try to localize,
they often end up forking html files. and often they create stale
versions w/o noticing
 me:  I kinda get where you are going, but it seems like the behavior
is kinda unpredictable. I'm kinda seeing the problem now.
 timeless.b...@gmail.com:  it's fairly easy to make a tool to show
which version of a file would be used
 me:  does it matter that you dont need to have a html file in the
localized folders?
that way you only need to branch when you need a special layout
 timeless.b...@gmail.com:  if all i have is /index.html and it has
 then it should search /i18n/fr-FR/flag.png then
/flag.png
having to branch html files is dangerous
 me:  ah!
/me gets it now :)
 timeless.b...@gmail.com:  note that i switched from en-GB to fr-FR as my locale
:)
 me:  ok, that should be easy to specify.
it's just a minor extension to what we already have
kinda fallback behavior