Pointer Events WG Voice Conference -- 08 Jan 2013

<ArtB> Scribe: Art

<ArtB> ScribeNick: ArtB

Date: 08 January 2013

<rbyers> Art, yep looking at it now

<rbyers> (again)

Getting started

AB: we need a Scribe for today's meeting

<scribe> ScribeNick: rbyers

<ArtB> Scribe: Rick

<ArtB> AB: any change requests for today's draft agenda http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0001.html?

<ArtB> Asir: can we get an update from Rick re implementation

<ArtB> AB: yes, let's add that to AoB

Point events bug

pointer events bugs

Jacob: server is redirecting from http to https, causing mixed content issues

Doug: knew that they were switching over, not sure why it's a problem

Jacob: doesn't render in Chrome, get warning in IE

Doug: please summarize issues in e-mail and send it to me

Jacob: ok

<ArtB> ACTION: Jacob send Doug an email that explains the https issues [recorded in http://www.w3.org/2013/01/08-pointerevents-minutes.html#action01]

<trackbot> Created ACTION-13 - Send Doug an email that explains the https issues [on Jacob Rossi - due 2013-01-15].

Rick: yes I see this too. I used to explicitly switch back to http, but now that doesn't work.

<jrossi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20222

bug 20222 - Pointer events explicitly disallow compatbility with hover menus used by many web sites

<smaug> shepazu: thanks

This spec text:

"For input devices that do not support hover, a user agent must also fire a pointerout event after firing the pointerup event."

<ArtB> [ Rick expands on Bug 20222; citing techcrunch as an example with it's More widget ]

Rick: should we really restrict implementations from supporting such sites
... what was the thinking in IE?

Jacob: instead of loosening restrictions, would like to see us converge - on whats best for the web

<ArtB> scribenick: ArtB

Rick: don't want to break css hover

… we trigger css hover and active

… we are exploring some options

… when you touch somewhere, move the mouse and trigger events

… we aren't happy with current impl

… and need to make some changes

Jacob: agree we need to do some work here

<jrossi> http://msdn.microsoft.com/library/ie/jj583807.aspx

… aria attribute has poppup

… added a behavior that sticks hover and not fire mouseout when user taps

… we can try to get sites to add haspopup

… but that is hard to do (scaling issue)

Rick: a solution that requires sites to change just doesn't work

Jacob: need some type of gesture to "stick hover"

… not crazy about what we shipped so looking at improving what we have done

… I can chat with my group about the design Rick described

Rick: we are experimenting (not finished)

<rbyers> Here's a bug tracking the work we want to do in chrome for this: https://code.google.com/p/chromium/issues/detail?id=153784

Rick: the list of events we were thinking about using is not in this bug

Jacob: I think we need to figure out how to fix this problem

… I don't want the spec to just say "do what you want"

… We need to determine what is best for the web and then Spec It

… We don't see a magic bullet here

… Olli - do you have some input on this bug?

Olli: I think FF behaves the same way as WebKit

Jacob: but is Webkit in flux here?

Rick: what I described has not been checked in

Olli: I'll need to check FF; there have been some changes to hover and link

Jacob: would like to get Mozilla's input on this

Olli: we need to be practical and minimize web sites that break

… agree we need to do something

Rick: are you getting a lot of complaints Jacob?

Jacob: we have received some feedback

… and we need to do something

Jacob: instead of using the attribute, some move their menus to click-based solutions

… agree it is kinda' the tail of the Web

Rick: I like that you can give sites guidance that is clean and simple

… I think you guys have found a good tradeoff with pointerevents

Jacob: the attribute is only used on menus

… (I can give more info on the list)

<rbyers> Another example: http://www.sky.fm/

<rbyers> hover menu here is so long you need to be able to scroll when it's up

Rick: there are some other corner cases like huge hover areas/text

<rbyers> but we're ok not supporting such sites with touch

Jacob: think we need more discussion on the list

… need to be careful about making some scenarios work and breaking others

Rick: I'll talk to our group about what IE is doing

… what is the status of ARIA?

Jacob: spec is done but implementation is still a WIP

Rick: perhaps we need to define a new attribute

… re hover effect

… Agree we need to focus on long-term and what's best for the Web

Jacob: agree; that section in the spec is Optional

<jrossi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20236

[ See bug 20222 for more context from Rick ]

<rbyers> scribenick: rbyers

bug 20236 - 3.1.1.1 button value -1 isn't possible

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20236

Jacob: Talked to Travis, DOM3 event editor about this

<jrossi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20311

… going to ask WebApps folks to change from unsigned to signed

Bug 20311 - Clarify touch-action is only looked at during pointerdown

Jacob: saw Rick's comments saying he liked the proposed text

<jrossi> When a user touches an element, that element's -touch-action property determines the default touch behaviors permitted for that contact, like panning or zooming. The touch behavior is then performed on the nearest ancestor element that is capable of that behavior, unless an intermediate ancestor element specifies that the behavior is not permitted.

… anyone else? Like this? Does it clarify it sufficiently or more detailed needed?

… (and yes, -ms is a typo)

… action applies to nearest ancestor - so it's sort of a strange inheritance

… but it's pretty straight forward

<asir> s/-ms-touch-action/touch-action/

Rick: IE10 implementation is really this simple?

<ArtB> ACTION: barstow notify the CSS WG after the next WD of Pointer Events is published [recorded in http://www.w3.org/2013/01/08-pointerevents-minutes.html#action02]

<trackbot> Created ACTION-14 - Notify the CSS WG after the next WD of Pointer Events is published [on Arthur Barstow - due 2013-01-15].

Jacob: for the most case yes, might be a couple edge cases

… in Win8 there are different default actions depending on the context (new style app or desktop)

… eg. flicking left/right to navigate

… So I propose adding this text, if anyone has additional concerns please post to the list

Art: Let's wait for additional feedback until the end of the week, then make the proposed change

Rick: I'll ping Daniel to see if he's happy

Bug 20217 - Expand touch-action property to include more of the values implemented by IE?

<jrossi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217

Jacob: Nothing new to share yet, but everyone I need to talk to is now back - hoping to get some traction on this soon

Summary: 20311 probably has consensus, so there are three bugs remaining

AoB

Art: should we publish a new working draft sometime soon?

… one of our values was to publish often

Jacob: think it's a good thing

… how close do we think we are to last call?

Rick: I expect we'll come up with questions/issues as another implementation (firefox or WebKit) works to become feature complete

… what is the bar for last call?

Art: last call is feature complete, group agrees on content of spec, want wider review (eg. web apps)

… review length period is a minimum of 3 weeks, can be as long as we want

… at the end, we make a decision about making a call for implementation (CR)

… then we decide what the criteria is, the minimal being 2 implementations implementing each feature

… so we can publish last call with zero implementations

… and expect implementations to occur afterwards

… To me it feels like there would be value to getting to last call sooner (not waiting for implementations), then a longer review period

… of course we might start implementation, find out we have bugs, go back to last call, etc.

Doug: that's a good summary

Jacob: we've made some good changes, if we want to publish a working draft then I'm happy to do it

… we should close on the touch-action issue before (bug 20217) before last call

… but would like to do it sooner rather than later

Jacob: do we want to do a "heart beat draft" later this week after the changes we've discussed?

Art: if we do, I'll make sure to ask the CSS WG for feedback
... any other feedback?

… realistically, would be published as technical report 1/14 or 1/16 at the earliest

Doug: would love to publish very frequently

Art: yes, sends a good signal

Jacob: proposed resolution: publish new WD on 1/14 including these changes

Art: any objections?

… hearing none

RESOLUTION: publish new WD on 1/14 including the latest agreed changes

implementation status

<smaug> asir: could you mute yourself

<smaug> echoing

<smaug> sangwhan: I assume you're not online atm?

asir: Any update from Opera on their approach to implementation?

… or on changing the time to accommodate them?

Doug: I will put together a poll for time
... do we want a call next week?

… not clear we need one

<ArtB> ACTION: Doug create a poll re conference time [recorded in http://www.w3.org/2013/01/08-pointerevents-minutes.html#action03]

<trackbot> Created ACTION-15 - Create a poll re conference time [on Doug Schepers - due 2013-01-15].

Jacob: if I'm prepared to talk about touch-action by next week, I'd love to have a call

… otherwise I don't have anything

… we will decide by Friday if we have enough information for a call next week

Art: ok, may or may not have call next week

- DRAFT -

Pointer Events WG Voice Conference

08 Jan 2013

Attendees

Contents