Re: TouchEvents pull request: add TouchEvent constructor

I left some comments on the PR #16.
<https://github.com/w3c/touch-events/pull/16>

On Tue, Aug 4, 2015 at 6:07 AM, Rick Byers <rbyers@chromium.org> wrote:

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