Re: TouchEvents pull request: add TouchEvent constructor

Ping.  Any opinion on this?  The details are sufficiently non-trivial that
I'd like at least one other editor to approve the change before I merge it
in.

In particular, I had these comments in the PR
<https://github.com/w3c/touch-events/pull/16#issuecomment-119785062>:

A couple areas to pay attention to:

The EventTarget isn't supposed to be nullable, so we can't have a default
value - so I made it required (along with the identifier for good measure).
But note that in blink at least, it is actually nullable -
document.createTouch() will create a Touch object with a null target).

Like for createTouch I didn't allow clientX and clientY to be explicitly
initialized. Instead they're initialized implicitly by pageX and pageY.
This is similar to the MouseEvent constructor, except there it's the client
co-ordinates that are explicit with the page ones computed from them.
Perhaps it's better to follow the MouseEvent pattern?

I initialize the TouchList objects with a sequence<Touch> (not unlike the
FontFaceSetLoadEvent constructor
<http://dev.w3.org/csswg/css-font-loading/#dictdef-fontfacesetloadeventinit>
).



On Tue, Jul 28, 2015 at 9:49 AM, Rick Byers <rbyers@google.com> wrote:

> I added this pull request <https://github.com/w3c/touch-events/pull/16> a
> few weeks ago but apparently there was no notification to
> public-touchevents :-(.  Please take a look.  If there are no objections in
> the next few days I'll merge it in.
>
> My main motivation for doing this now is the InputDevice work
> <https://github.com/rbyers/InputDevice>.  Without a constructor, any new
> properties of UIEvent technically should include an extention to
> initTouchEvent, which I really don't want to do.  As with initTouchEvent, I
> don't expect a lot of use here, but we should have a constructor for
> completeness.
>
> If this group agrees to the spec change, I expect we'll add it to blink
> shortly (and given the low usage, we may even be able to deprecate
> initTouchEvent etc. before long).
>
> Thanks,
>    Rick
>