Pointer Events WG Voice Conference -- 04 Jun 2013

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Tweak agenda

AB: I posted a draft agenda last Friday http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0164.html. Any change requests?
... would someone please scribe today's call? I think most of the topics are going to be relatively quick.

Bug 21951

AB: Bug 21951 is labeled "CR" and titled "pointermove dispatching when button state changes"; https://www.w3.org/Bugs/Public/show_bug.cgi?id=21951
... based on the text of the bug, it appears this will require a short clarification so probably nothing we need to discus but wanted to verify that.

RB: yes, I think it is just a minor clarification

… that Jacob can handle

AV: yes, agree it is a clarification

Answers to questions in new points.js polyfill

AB: we have a thread about points.js and some other related libs and polyfills http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0148.html. It's good to see the interest
... is there anything we need to discuss today or any followup actions?

RB: I think I owe Rich a reply

… we had a good discussion re tradeoffs

… I think we have consensus on how to tradeoff performance on in/out semantics

… preventDefault will be tricky, though

… I need to think and experiment on that

… I've had some other discussions about how we can test this

… and trying to have one polyfill we can recommend

… we should have design discussions on the list

… I think implementers are ready to start hacking on this

AV: yes, need to continue discussions

… not sure if there are any issues that need WG attention

… I don't think so

RB: agree no WG attention needed

… we need to get a high fidelity polyfilll

… but I don't think we need any spec changes

AV: ok, good; I haven't seen any issues that require spec changes

RB: we could add some non-normative notes to the spec

… it is good for the group to participate in the tradeoffs

… and we should continue those on the list

SG: jQuery is working on a polyfill

… we'd rather not have to do so

… but something is needed e.g. old IE

… we have been working with MS Open Tech

<smaug> (it can't be really polyfill, given that old IEs don't even have DOM events)

… of all the events to polyfill, this is one of the hardest

… hope we don't get random inconsistencies

RB: shouldn't need jQuery specific parts for the polyfill

SG: would prefer to just recommend something else

… (and not create our own)

… If we write our own, it will be jQuery specific

RB: may be possible to work with other polyfills

… e.g. Polymer

… the Polymer pollyfill is separable

… not aware of any technical issues why it couldn't support old IE

… I'm sure they would appreciate help, if it doesn't create any perf issues

… I could talke to Daniel Freedman

SG: we've talked to him

… the discussion kinda' died

RB: I can help here, talking to Daniel

… tough to invest when testing is hard

AV: Scott, how did it go when you talked to MS Open Tech people

SG: the conclusion was to create jQuery specific

… ? hand.js ?

AV: I can followup too

<asir> You got the name right

RB: is there a good addEventListener for old IE?

SG: I'm not aware of any

… not aware of a good polyfill for addEvListener for old IE

AV: what version is "old IE"

SG: jQuery UI is IE 7

RB: so that could add significant complexity to polymer to go way back with IE

… wondering about how far back the polyfills need to go

SG: want to eventually stop using mouse events completely

RB: in the short term, there will be some tradeoffs

… going to be hard to polyfill everything and get good performance

SG: two sides: people trying to use PE directly; people that are still using mouse events

… want to get people to stop writing to mouse events

RB: polyfill could have a switch re use touch events or not

SG: things like preventDefault and touch-action will be tricky

RB: ok, I'll reach out to the Polymer guys

… worst case is we must have a separate IE6 polyfill

… if we need that, we should work with MS Open Tech

AV: yes, agree

An update on the Chrome team's stance on implementing pointer events in Chrome

AB: Rick provided an update re Chrome's PE implementation

http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0155.html

AB: there is also the video Rick and Boris Smus gave at G-IO <http://www.youtube.com/watch?v=DujfpXOKUp8>.

RB: we will need touch-action or something like

… it is probably the hardest part of PE

… want to get it working with TouchEvents (TE)

… would make polyfills easier

… I have a design doc for Chrome

… ATM, I see this as experimental

… May need a new property for compatibility with TE

… I landed one CL and another is in progress (touch-action)

… I think we have a couple of months ahead

… before we can turn this on by default

… I talked to Matt about our design and he thinks it is reasonable and applicable for FireFox

… I reached out to Safari people and have to followup with them

… Talking to Scott at MS Open Tech

… Slow progress but it's moving forward

Justification for the touch-action processing model

AB: this topic has a couple of threads, one is http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0163.html.
... there is also a thread titled "Is touch-action implicitly applied to any elements?" http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0156.html

<rbyers> By the way, to follow Chrome's touch-action support, follow crbug.com/241964

AB: do we discuss now or keep discussions on the list?

RB: I think using the list is fine

… I've been getting Qs and I'm passing them on to the list

AV: I think Jacob replied

RB: he did and then I had a followup

… I'm not arguing for a change but more trying to understand the "Whys" of the processing model

… If/when I get a Q like "why is this so different than everything else?", I'd like to have some background and context to reply

<rbyers> ... In particular, making sure my reasons for why I like the design as it is are consistent with the original design goals...

AB: please continue the discussion on the list [Art notes Jacob wasn't on the call]

Testing: status and plans;

AB: yesterday, Matt proposed a submission and approval process http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0167.html and there has been quit

… quite a bit of followup on the list

AB: he also indicated he is willing to move tests from hg into the GitHub PE directory https://github.com/w3c/web-platform-tests/tree/master/pointerevents

… and that's good

AB: there a few sub-issues here ...
... one is, do we create our own repo or re-use the .../w3c/web-platform-tests/?

SG: my comments were more about W3C policy

… I think we should just follow the W3C policy

… my comments were those driving W3C testing effort

AB: ok, thanks for that clarification
... another is how to manage the "notification hell"

… and since, Tobie replied and is gathering requirements on how to address that

AB: we definitely need a solution to that issue

AV: do we need a separate mailing list for testing?

AB: good Q

… my feel now is not yet

AV: I would expect the set of tests to not be as large as other groups

AB: I agree with your expectation
... any comments on Matt's proposal?

AV: I want to thank Matt!

… Matt asked about using the list to signal reviews

… I like the idea to make that email mandatory

… Re fixing/updating tests, how is that done?

… I would expect a PR to be made

… just like a submission

OP: yes, agree

AV: so need to be clear that test updates need to go through the same process

… there front page is missing some information

… e.g. copyrights, obligations, etc.

AB: agree the update process should use the same mechanics as submissions

… and if there is some missing documentation in the home page, then yes, we need to fix that

… if have general OWP questions, issues, feedback, send to public-infr-test

AV: I want to talk to my team about Matt's proposal

AB: ok, sounds good

AV: I think we all need to make a commitment to review the tests

AB: yes, I definitely agree with that

… and it's up to us to define the review and approval process

AV: Matt suggested #2 be mandatory i.e. to notify the group of all submissions and ask for reviews

AB: I agree we should use the list for explicit "call for reviews" of test cases
... anything else on testing for today?
... Scott, did you volunteer to help Matt manage the PE tests?

SG: sure

AB: OK, thanks Scott

Any other Business

AB: any new Implementation status to share?

OP: I need to talk to romaxa to get implementation status

RB: Olli - if romaxa has feedback on my design doc, that would be great

… could make sense for FF to implement touch-action first, independent of PE spec

… that could facilitate a pollyfill experience

AB: anything else for today?
... so we'll have the next call when we have sufficient topics

… If you see a need for a call let me know

AB: meeting adjourned

- DRAFT -

Pointer Events WG Voice Conference

04 Jun 2013

Attendees

Contents