Rather than introduce another method similar to the now deprecated init* methods, I would rather extend the initMouseEvent and initKeyboardEvent dictionaries with the relevant modifier initializers.

Perhaps:
* boolean modifierStateCapsLock
* boolean modifierStateNumLock
* boolean modifierStateScrollLock
* boolean modifierStateOS
* boolean modifierStateAltGraph
* boolean modifierStateSuper
* boolean modifierStateHyper
etc.

The dictionary format is perfect for this kind of extensibility.

Yeah, if they can be initialized with constructor, it's the best.

(In reply to Masayuki Nakano from comment #2)
> Yeah, if they can be initialized with constructor, it's the best.

I've got a private copy of this change now, and while writing it I made a few assumptions that I'd like to discuss:

1. Some of the getModifierState params duplicate existing attributes, e.g., "Alt" and the altKey IDL attribute. Consequently, I've not created the new initializers for "Alt", but have made it explicit (in the prose for the existing "altKey" initializer on the dictionary) that is also sets the internal modifier state of the event such that calls to getModifierState('Alt') also return true. This avoids the duplication.

2. When initializing "ctrlKey" or "metaKey" I define that the internal states for getModifierStates "Control" and "Meta" are set (as described above), but also that the virtual "Accel" modifier is also set. So initializing "ctrlKey" to true will cause calls to getModifierState("Control") and getModifierState("Accel") to also return true.

3. Given #2 above, I'm going to assume that if either "ctrlKey" OR "metaKey" is true, then "Accel" is also true, rather than using ("ctrlKey" AND "metaKey") logic.

(In reply to Travis Leithead [MSFT] from comment #3)
> (In reply to Masayuki Nakano from comment #2)
> 1. Some of the getModifierState params duplicate existing attributes, e.g.,
> "Alt" and the altKey IDL attribute. Consequently, I've not created the new
> initializers for "Alt", but have made it explicit (in the prose for the
> existing "altKey" initializer on the dictionary) that is also sets the
> internal modifier state of the event such that calls to
> getModifierState('Alt') also return true. This avoids the duplication.

I believe that it's right approach. If D3E allows two names for a state, following case is really a problem:

new Event("", altKey: true, modifierStateAlt: false);

So, I agree with that modifier states which can be represented by legacy fooKey shouldn't be initialized with modifierState*.

> 2. When initializing "ctrlKey" or "metaKey" I define that the internal
> states for getModifierStates "Control" and "Meta" are set (as described
> above), but also that the virtual "Accel" modifier is also set. So
> initializing "ctrlKey" to true will cause calls to
> getModifierState("Control") and getModifierState("Accel") to also return
> true.

I think that it's not problem. Additionally, web apps can test which modifier is the "Accel". E.g.,

var ctrlEvent = new KeyboardEvent("", { ctrlKey: true });
var metaEvent = new KeyboardEvent("", { metaKey: true });

var accelText = ctrlEvent.getModifierState("Accel") ? "Ctrl" :
                metaEvent.getModifierState("Accel") ? "Command" : ...;

Like this, web apps can show proper modifier key label dynamically.

> 3. Given #2 above, I'm going to assume that if either "ctrlKey" OR "metaKey"
> is true, then "Accel" is also true, rather than using ("ctrlKey" AND
> "metaKey") logic.

However, depending on the prefs on Firefox. Firefox can also set "Alt" or "OS" (and "Super", "Hyper" soon) as a modifier for acceleration. Although, it must be rare case. Anyway, modifierStateAccel should not exist in the dictionary.

Travis, note that if your initialization process is not covered by http://dom.spec.whatwg.org/#constructing-events we need to figure out how to make that work. You might have to define the entire constructor yourself.

I landed v1 of this change.

Anne, I need to look and see what magic flags may be available to define this more specifically--I wanted to land this much now, since it refactors some of the event dictionaries...

(In reply to Travis Leithead [MSFT] from comment #6)
> I landed v1 of this change.
> 
> Anne, I need to look and see what magic flags may be available to define
> this more specifically--I wanted to land this much now, since it refactors
> some of the event dictionaries...

https://dvcs.w3.org/hg/dom3events/rev/8034c1f1c711

(In reply to Anne from comment #5)
> Travis, note that if your initialization process is not covered by
> http://dom.spec.whatwg.org/#constructing-events we need to figure out how to
> make that work. You might have to define the entire constructor yourself.

Mmm. DOM doesn't seem to have the hooks I need. I need some internal state that can represent the possible values used by the getModifierState function... I should be able to whip that up.

(In reply to Travis Leithead [MSFT] from comment #8)
> (In reply to Anne from comment #5)
> > Travis, note that if your initialization process is not covered by
> > http://dom.spec.whatwg.org/#constructing-events we need to figure out how to
> > make that work. You might have to define the entire constructor yourself.
> 
> Mmm. DOM doesn't seem to have the hooks I need. I need some internal state
> that can represent the possible values used by the getModifierState
> function... I should be able to whip that up.

Committed a rough extension to Anne's algorithm in the DOM spec.
https://dvcs.w3.org/hg/dom3events/rev/ad15280ceb0c