WebApps-ACTION-759: Look into next f2f

2015-10-26 Thread 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

2015-10-06 Thread 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

2015-08-23 Thread 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.

2015-07-21 Thread 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

2014-10-28 Thread 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-734: Start cfc to publish ui events as a gutted wg note

2014-10-27 Thread 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-ACTION-735: Check that the d3e tests are in gh or mercurial, and if needed fix

2014-10-27 Thread 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-736: Work with adrian to find a replacement tc for alex and d3e

2014-10-27 Thread 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-737: Create a new bugzilla component for inner text

2014-10-27 Thread 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-738: Start a cfc to publish a gutted wg note of the fullscreen api

2014-10-27 Thread 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-739: Start a cfc to publish a proposed recommendation of idb

2014-10-27 Thread 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-740: Issue a call for test facilitator for ime spec

2014-10-27 Thread 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-741: Ask cjk interest group and others about ime (use cases, tests, etc.)

2014-10-27 Thread 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-742: Re sse test results, followup on the timeouts with the 2 test facilitators

2014-10-27 Thread 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-744: Work on moving web idl v1 to rec

2014-10-27 Thread 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-743: Try to find someone to help yves, cam and boris on web idl v1

2014-10-27 Thread 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-746: Determine kris' availability to work on the web messaging and web sockets implemenation reports

2014-10-27 Thread 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-745: Followup with simon re running the web workers tests

2014-10-27 Thread 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-747: Start a cfc to gut xhr l2 and publish a wg note

2014-10-27 Thread 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-748: Mark file list as feature @ risk

2014-10-27 Thread 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-749: Start a cfc to publish file api lcwd

2014-10-27 Thread 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-750: Deleted the uc in file api that starts with data should be able to be stored ...

2014-10-27 Thread 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-751: Followup with cameron re pr 27 and the web idl test suite

2014-10-27 Thread 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-752: Do edits on file system spec

2014-10-27 Thread 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-753: Find an msdn page that describes this

2014-10-27 Thread 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-754: Work with doug and chaals re fuzzy pointers stuff for web annotations wg

2014-10-27 Thread 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-755: Solve the rest of the problems related to robust targeting of changing documents.

2014-10-27 Thread 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-ISSUE-181 (FileError-Name): Use case for FileError and FileException name attribute [File API]

2011-06-06 Thread 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-182 (OperationNotAllowed): File API introduces a new OperationNotAllowed exception where other specs have an error code [File API]

2011-06-06 Thread 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-179 (DOMException): DOM Core uses INVALID_STATE_ERR (DOMException) where D3E uses DISPATCH_REQUEST_ERR (EventException)

2011-05-05 Thread 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]

2010-12-09 Thread 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-150: [widgets] Email and param name and value as 'Keyword attributes' is causing confusion in Widgets PC Spec

2010-10-19 Thread Web Applications Working Group Issue Tracker

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

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

Raised by: 
On product: 







ISSUE-151: [widgets] PC 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

2010-10-19 Thread Web Applications Working Group Issue Tracker

ISSUE-151: [widgets] PC 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-152: [widgets] PC test suite needs a few more XML entity cases to check for well-formed XML

2010-10-19 Thread Web Applications Working Group Issue Tracker

ISSUE-152: [widgets] PC 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-149 (missing key values): The multiply and other key values are missing [DOM3 Events]

2010-10-13 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0032.html:
[[
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.
]]

http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0034.html:
[[
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-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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]

2010-10-06 Thread 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 
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.
]]





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

2010-10-05 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0013.html:
[[
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

2010-10-02 Thread 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 http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0106.html:
[[
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.)
]]

http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0175.html:
[[
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]

2010-09-29 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0195.html:
[[
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]

2010-09-16 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0160.html:
[[
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-123 (feature strings): Rationale for feature strings [DOM3 Events]

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html:
[[
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-124 (reword examples): Remove RFC2119 keywords from examples [DOM3 Events]

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html:
[[
RFC2119 keywords in examples is bad style. Please replace RFC2119 keywords
in non-normative sections and examples with other words.
]]





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

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html:
[[
{
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=4947to=4948
]]





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

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html:
[[
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-127 (cancelBubble / srcElement): Consider adding cancelBubble and srcElement [DOM3 Events]

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html:
[[
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-128 (preventDefault): Define preventDefault to account for pre-propagation default actions [DOM3 Events]

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html:
[[
The definition of preventDefault does not talk about default actions that
happen before the event propagation (like 'change' on checkboxes).
]]





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

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html:
[[
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-130 (Web IDL): Consider using Web IDL for the IDL fragments [DOM3 Events]

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html:
[[
I think this specification should use WebIDL for the IDL fragments.
]]





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

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html:
[[
{
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-132 (event.returnValue): Consider adding event.returnValue [DOM3 Events]

2010-09-15 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0142.html:
[[
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-120 (scroll basic event): Consider returning 'scroll' from UIEvent to Event interface [DOM3 Events]

2010-09-10 Thread 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-121 (beforeInput): Consider generalizing the 'textInput' event to cover all user-initiated changes [DOM3 Events]

2010-09-10 Thread 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 http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0096.html 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-122 (add mousewheel): Consider adding 'mousewheel' again [DOM3 Events]

2010-09-10 Thread 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-118 (dispatchEvent links): Consider allowing dispatchEvent for generic event duplication for links [DOM3 Events]

2010-07-21 Thread 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 
http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0041.html :
[[
Is it defined what should happen in the following case?

div onclick=document.links[0].dispatchEvent(event)click me/div
a href=http://example.org/;test/a

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 
canvas 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 PC 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.

2010-06-24 Thread Web Applications Working Group Issue Tracker

ISSUE-117: In Widget PC 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-114 (CORS-credentials): CORS does not define the effect of the credentials flag in sufficient detail [CORS]

2010-02-03 Thread 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-115 (xhr-referer): XHR does not specify what URL to use for Referer [XHR]

2010-02-03 Thread 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-113 (resize): Clarify when resize events fire [DOM3 Events]

2010-01-31 Thread 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]

2009-11-22 Thread 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]

2009-11-03 Thread 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]

2009-11-02 Thread 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]

2009-10-19 Thread 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]

2009-10-18 Thread 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]

2009-09-27 Thread 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-103: accessing status/statusText/getResponseHeader()/getAllResponseHeaders() [XHR]

2009-09-25 Thread 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-104: supporting structured clones [XHR2]

2009-09-25 Thread 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-101 (Marcin Hanclik): Event's generation [ViewModes]

2009-09-04 Thread 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]

2009-09-04 Thread 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]

2009-08-27 Thread 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:

http://www.w3.org/mid/6fc58d0d0904241431n290e8166m1e126cc02e735...@mail.gmail.com





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

2009-08-26 Thread 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-98 (Relation to DOM3Events): Cargo-culting [ViewModes]

2009-08-26 Thread 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-94: PC CR: Try to fallback to default start files when src path is invalid or not existing [Widgets]

2009-08-12 Thread Web Applications Working Group Issue Tracker

ISSUE-94: PC 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 PC CR:

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





ISSUE-95: PC CR: Conformance checker behavior intermixed with UA behavior [Widgets]

2009-08-12 Thread Web Applications Working Group Issue Tracker

ISSUE-95: PC 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 PC CR:

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





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

2009-06-16 Thread 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-91: Origin and redirects [CORS]

2009-06-16 Thread 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-86 (rewrite-suggestion): Consider splitting out events and rewriting definitions [DOM3 Events]

2009-03-24 Thread 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-84 (Read-only cutting): Should cut work like copy on read-only content? [Clipboard Operations]

2009-03-08 Thread 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-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]

2009-03-08 Thread 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-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]

2009-02-22 Thread 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 access and Widget access element [Widgets]

2009-02-19 Thread Web Applications Working Group Issue Tracker

ISSUE-82 (Access element naming conflict): potential conflict between the XHTML 
access and Widget access 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 access 
element defined in the Widgets 1.0: Packaging and Configuration specification 
[1] and the access 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]

2009-02-12 Thread 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:

[[
http://www.w3.org/2009/02/12-wam-minutes.html#item06

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]

2009-02-02 Thread 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 base folder
 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 img src=flag.png
 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 img src=images/flag.png 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
img src=flag.png 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





ISSUE-78: HTML5 stalled and suspend progress events [Progress Events]

2008-10-25 Thread Web Applications Working Group Issue Tracker

ISSUE-78: HTML5 stalled and suspend progress events [Progress Events]

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

Raised by: Philip Jägenstedt
On product: Progress Events

http://www.w3.org/html/wg/html5/#mediaevents

The events in HTML 5 fired for the media elements (video+audio) are called 
ProgressEvents and are intended to eventually refer to the Progress Events spec.

Currently the HTML5 draft specifies two events not covered by the Progress 
Events draft: stalled and suspend

These should be added to the draft, I suggest the following phrasing:

Name / Description / How often? / When?

stalled / The operation is unexpectedly not progressing / zero or more / May be 
dispatched zero or more times after a loadstart event, before any error, abort 
or load event is dispatched

suspend / The operation is temporarily suspended / zero or more / May be 
dispatched zero or more times after a loadstart event, before any error, abort 
or load event is dispatched

Rationale:

Stalled is used to signal that the download is for some reason not progressing, 
but the user agent has not yet given up and fired an error event. In HTML5 this 
happens when no data has been received for approximately 3 seconds.

Suspend is used to signal that the user agent is deliberately pausing the 
download. In the case of audio/video, the user agent may initially download 
only a portion of the file and fetch the rest only when/if the user plays the 
audio/video to a point where it is needed.






ISSUE-75: Document pointer needs fixing [XHR]

2008-09-26 Thread Web Applications Working Group Issue Tracker

ISSUE-75: Document pointer needs fixing [XHR]

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

Raised by: Anne van Kesteren
On product: XHR

In the following scenarios it's not clear what should happen to the Document 
pointer:

var randomObj = {};  
randomObj.XMLHttpRequest = someWindow.XMLHttpRequest;  
new randomObj.XMLHttpRequest();

or

window.foreignXHR = otherWindow.XMLHttpRequest
new foreignXHR();

Needs testing in Internet Explorer since we followed that for the definition of 
Document pointer so far. (Thanks to Sam and Maciej.)






ISSUE-76: Document pointer needs fixing [XHR]

2008-09-26 Thread Web Applications Working Group Issue Tracker

ISSUE-76: Document pointer needs fixing [XHR]

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

Raised by: Anne van Kesteren
On product: XHR

In the following scenarios it's not clear what should happen to the Document 
pointer:

var randomObj = {};  
randomObj.XMLHttpRequest = someWindow.XMLHttpRequest;  
new randomObj.XMLHttpRequest();

or

window.foreignXHR = otherWindow.XMLHttpRequest
new foreignXHR();

Needs testing in Internet Explorer since we followed that for the definition of 
Document pointer so far. (Thanks to Sam and Maciej.)






ISSUE-45 (Extensible metadata): Do we need an extensible metadata hook? [Widgets]

2008-08-07 Thread Web Applications Working Group Issue Tracker

ISSUE-45 (Extensible metadata): Do we need an extensible metadata hook?  
[Widgets]

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

Raised by: Marcos Caceres
On product: Widgets

Krzysztof Maczyński recommended that we need some kind of generic extensible 
metadata hook. If there a use case for such a thing? can it be achieved in some 
other way? 






ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]

2008-07-28 Thread Web Applications Working Group Issue Tracker

ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events 
and the Window object? [DOM3 Events]

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

Raised by: Ian Hickson
On product: DOM3 Events

We need to decide whether HTML5 or DOM3 Events (or another spec) defines how 
events interact with the Window object that browsers have.

Right now HTML5 says this:
http://www.whatwg.org/specs/web-apps/current-work/#events0
and DOM3 Events says this:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-flow






ISSUE-41 (New Non-NS Event Methods): Should all event methods have namespaced and non-namespaced equivalents?

2008-07-23 Thread Web Applications Working Group Issue Tracker

ISSUE-41 (New Non-NS Event Methods): Should all event methods have namespaced 
and non-namespaced equivalents?

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

Raised by: Doug Schepers
On product: 

From Olli Pettay in 
http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0260.html:

[[
IMO CustomEvent should have also initCustomEvent(), not only 
initCustomEventNS().
Having only initCustomEventNS doesn't prevent anyone to create events with null
namespace and it is just annoying if initCustomEvent isn't there.

Similar with MouseWheelEvent, it has only initMouseWheelEventNS, but should 
have also initMouseWheelEvent.


WheelEvent should also have non-NS initialization method.
]]






ISSUE-42 (simpler custom events): Should we simplify custom events? [DOM3 Events]

2008-07-23 Thread Web Applications Working Group Issue Tracker

ISSUE-42 (simpler custom events): Should we simplify custom events? [DOM3 
Events]

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

Raised by: Doug Schepers
On product: DOM3 Events

From Cameron McCormack in 
http://lists.w3.org/Archives/Public/www-svg/2005Oct/0005.html:

I'd like to make another suggestion about DOM 3 custom events; this time
a great simplification.

Currently any custom event object that is to be dispatched to listeners
must implement the CustomEvent interface, and hence also the Event
interface.  For ECMAScript, this means writing 10 methods for that
object--plus one more to get event dispatching working properly[1] and
another to make it work under sXBL[2].  For Java it's even worse, since
getter methods must be provided for the attributes, bringing the number
of methods to 20.  Though a Java implementation could provide an
abstract custom event class to extend to ease that burden, this isn't
possible for ECMAScript if it's to be non-UA-specific.

The main reason for custom events is to associate extra attributes with
the event object specific to the event.  As such, I think it's likely
overkill to allow user objects to be dispatched by the events
implementation.  Instead, we could have a custom event object created
by the implementation, if this object has an attribute of type DOMObject
that holds all of the custom event object information.

  interface CustomEvent : Event {
readonly attribute DOMObject details;

void initCustomEventNS(in DOMString namespaceURIArg,
   in DOMString typeArg, 
   in boolean canBubbleArg,
   in boolean cancelableArg,
   in DOMObject detailsArg);
  };

These custom event objects could be then created with a call to
DocumentEvent.createEvent(CustomEvent).  For example in ECMAScript:

  var currentTime = ...;
  var evt = document.createEvent(CustomEvent);
  evt.initCustomEventNS(http://example.org/timer;,
tick,
true, false, { time: currentTime });
  document.documentElement.dispatchEvent(evt);

If specifying whether custom events should be retargetted or stopped at
shadow scope boundaries under sXBL is a desirable feature (and I think
it is), then a separate interface to set this information is probably
the way to go.

  interface EventXBL {
attribute boolean retargetable;
  };

All event objects created by an sXBL capable events implementation would
implement this interface.  The retargetable attribute would be set to
the appropriate value when methods such as UIEvent.initUIEventNS,
MutationEvent.initMutationEventNS, etc. are called.  For events without
an intrinsic retargetability (such as those initialised with
Event.initEventNS or CustomEvent.initCustomEventNS), it would default to
a particular value (not sure what would be the more appropriate default
here).

If a CustomEvent were retargetted, its details attribute would be copied
to the clone.

I think this is much simpler than what is currently specified, as
demonstrated by this[3] ECMAScript example.

Please let me know your thoughts on this suggestion.

Thanks,

Cameron

[1] http://lists.w3.org/Archives/Public/www-svg/2005Apr/0208.html
[2] http://lists.w3.org/Archives/Public/www-svg/2005Sep/0072.html
[3] http://wiki.apache.org/xmlgraphics-batik/CustomJavaScriptEvents






  1   2   >