Draft Minutes: 8 January 2013 call

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.

-ArtB

[1]W3C

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

- DRAFT -

Pointer Events WG Voice Conference

08 Jan 2013

[2]Agenda

[2] 
http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0001.html

See also: [3]IRC log

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

Attendees

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

Regrets
Chair
Art

Scribe
Art, Rick

Contents

* [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 - 3.1.1.1 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
[15]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0001.html?

[15] 
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
[16]http://www.w3.org/2013/01/08-pointerevents-minutes.html#act
ion01]

<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>
[17]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20222

[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
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:
[19]https://code.google.com/p/chromium/issues/detail?id=153784

[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
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: [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
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>
[21]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20236

[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 - 3.1.1.1 button value -1 isn't possible

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

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

Jacob: Talked to Travis, DOM3 event editor about this

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

[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
[24]http://www.w3.org/2013/01/08-pointerevents-minutes.html#act
ion02]

<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>
[25]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217

[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
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
[26]http://www.w3.org/2013/01/08-pointerevents-minutes.html#act
ion03]

<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
[27]http://www.w3.org/2013/01/08-pointerevents-minutes.html#act
ion02]
[NEW] ACTION: Doug create a poll re conference time [recorded
in
[28]http://www.w3.org/2013/01/08-pointerevents-minutes.html#act
ion03]
[NEW] ACTION: Jacob send Doug an email that explains the https
issues [recorded in
[29]http://www.w3.org/2013/01/08-pointerevents-minutes.html#act
ion01]

[End of minutes]

Received on Tuesday, 8 January 2013 17:11:30 UTC