W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2013

Draft Minutes: 8 January 2013 call

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 08 Jan 2013 12:11:02 -0500
Message-ID: <50EC5326.1080405@nokia.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
The draft minutes from the January 8 voice conference are available at 
<http://www.w3.org/2013/01/08-pointerevents-minutes.html> and copied below.

WG Members - if you have any comments, corrections, etc., please send 
them to the public-pointer-events mail list before 15 January 2013. In 
the absence of any changes, these minutes will be considered approved.

Thanks to Rick for Scribing this meeting.



[1] http://www.w3.org/


Pointer Events WG Voice Conference

08 Jan 2013



See also: [3]IRC log

[3] http://www.w3.org/2013/01/08-pointerevents-irc


Art_Barstow, Rick_Byers, Jacob_Rossi, Doug_Schepers,
Olli_Pettay, Asir_Vedamuthu, Cathy_Chan, Matt_Brubeck


Art, Rick


* [4]Topics
1. [5]Getting started
2. [6]Point events bug
3. [7]pointer events bugs
4. [8]bug 20222 - Pointer events explicitly disallow
compatbility with hover menus used by many web sites
5. [9]bug 20236 - button value -1 isn't possible
6. [10]Bug 20311 - Clarify touch-action is only looked at
during pointerdown
7. [11]Bug 20217 - Expand touch-action property to
include more of the values implemented by IE?
8. [12]AoB
9. [13]implementation status
* [14]Summary of Action Items

<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


<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

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

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


[17] 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> [18]http://msdn.microsoft.com/library/ie/jj583807.aspx

[18] 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

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:

[19] 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

 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

 I think you guys have found a good tradeoff with

Jacob: the attribute is only used on menus

 (I can give more info on the list)

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

[20] 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

<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

Jacob: agree; that section in the spec is Optional


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

[ See bug 20222 for more context from Rick ]

<rbyers> scribenick: rbyers

bug 20236 - button value -1 isn't possible


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

Jacob: Talked to Travis, DOM3 event editor about this


[23] 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

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

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?


[25] 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


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

 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

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

 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

<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

Summary of Action Items

[NEW] ACTION: barstow notify the CSS WG after the next WD of
Pointer Events is published [recorded in
[NEW] ACTION: Doug create a poll re conference time [recorded
[NEW] ACTION: Jacob send Doug an email that explains the https
issues [recorded in

[End of minutes]
Received on Tuesday, 8 January 2013 17:11:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:17:04 GMT