W3C

- DRAFT -

Web Applications Working Group Teleconference

13 Oct 2010

See also: IRC log

Attendees

Present
Shepazu, Janina_Sajka, Gregory_Rosmaita, Michael_Cooper, Rich, Joseph_Scheuhammer, Olli_Pettay, Art_Barstow, Travis, tonychang, MikeSmith
Regrets
Chair
shepazu
Scribe
jrossi

Contents


<trackbot> Date: 13 October 2010

<Travis> Having a bit of trouble calling in... hang tight.

<Travis> OK.

<oedipus> monday's discussion on DI and DOM3 at PF call: http://www.w3.org/2010/10/11-pf-minutes.html

<smaug_> I think

<tonychang> I'm 1.650.253.aaaa

<tonychang> Zakim 1.650.253.aaaa is tonychang

<tonychang> err

<tonychang> Zakim +1.650.253.aaaa is tonychang

<MikeSmith> tonychang, you need a comma

<MikeSmith> . Zakim,

<tonychang> MikeSmith: thanks

<MikeSmith> cheers

<shepazu> scribeNick: Jacob

<MikeSmith> "First Call" instead of "Last Call"…

<inserted> scribe: jrossi

shepazu: This is the first Last Call....intended to be feature complete last call, not the document last call.
... Apple proposal for UI events for ARIA.

<shepazu> http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html

shepazu: The UIRequestEvent, first interface (Sect. 2), the const list is not intended to be a set of constants that come up with that event. Rather, it's a set of events that use that interface. For ex, MouseEvent hase mousemove/mousedown/etc.
... I think this would be useful. Love to see it in D3E. So we could see an arrangment such that instead of a keyboard evt with key == Undo, we could see an actual Undo Event.
... the undo evt could happen before the keyboard event for the undo key

Travis: Small concern: a series of high level semantic events (the fire as a result of intended meaning by end user, "the result of a particular default action"). Nowhere in D3E (w/ exception of click) do we have the concept of a meta-event. My concern is they dont really jive with the rest of the events which are currently spec'd in our draft (which are more low-level events tied to the likes of hardware actions, etc).
... Clearly value in these events. I just don't see that we just try to graft those into the spec with our current focus.

shepazu: Planning on making a new WG (Touch Interface WG). The intent there is to manage touch interface, but also some higher level events too. Possibly renaming WG to something like Touch Interface and Abstract Events WG
... So that is another possible venue for similar sorts of things.
... related proposal by Google, around textInput event to change it to beforeInput and abstract it out to capture all sorts of changes to the document (undo, redo, etc). Not necessarily in semantic terms, but functionally.

<smaug_> there is some background noise

<anne> HTML5 defines undo/redo events

richardschwerdtfe: Couple points: one thing that I wish we had better tools on mobile devices, but this is the one thing that's really prohibiting us from producing a good mobile device. Keyboards on mobile dont always map correctly. Higher level events would allow for manipulating better and allow us to be more accesible. I wish I had some of the events earlier on.

Travis: To add on to that, w/ D3E today to make your app accesible you have to write your code directly to the input devices you have available (keyboard, mouse) and on some platforms touch.

tonychang: From Google, details on beforeInput. I think UIRequestEvent is fine and will meet a lot of the simliar needs of beforeInput.
... beforeInput was trying to be one evt you listen for that captures all possible inputs.
... downside of UIRequestEvent is that you have to subscribe to a bunch of events (Undo/Redo/etc) to get all input

<shepazu> ?

travis: I think we have to be realisitic. Any spec that tries to define semantic evts is going to be incomplete. We need figure out what the key events that capture the main scenarios we have are.

shepazu: wishes this approach had been taken 15 yrs ago. My concern is that this will take up a really long time (min, several months) to come to agreement. I think that conversation needs to happen. I am concerned that it happens in the scope of D3E.
... I'd like to hear people's reaction to that. Excellent work, excellent ideas. We could have these higher events and we agree it would make it easier.
... But I think we could agree that the conversation won't be settled in the next month and a half.

Travis: It's been 10 years in the making (D3E). Let's get these things done. But I am sensitive to the accesibility needs to have these completed.

richardschwerdtfe: How would the module track for dom events work?

<smaug_> jrossi: do you have microphone near keyboard?

shepazu: It wouldn't be a D3E module. It would be some other spec that uses D3E. D3E underlies things like SVG, HTML5.

yeah, muted the mic. better?

<smaug_> better, thanks

shepazu: It also goes into a few low level evts.

<smaug_> er, no

must be something else

shepazu: Example, event propagation, contstruction of events, dispatching, etc. It's the architecture of events and a few particular events on top of that.
... This new events spec would not talk about the architecture that D3E lays as a framework. It would simply define a set of interfaces and events, the order in which they're fired, etc. So just the evts themselves and not the mechanisms.
... Logistically, we could start iterating on the spec to come to a conclusion while we're still working on D3E.
... Probably be ready for first public WD before the 2nd D3E last call.
... Key factor, unlike a lot of other specs, this has the interest of Google,Microsoft, other browser vendors.
... with that, things could happen very quickly.

richardschwerdtfe: Seems like a reasonable approach.

shepazu: Does anyone have a problem with that approach?

richardschwerdtfe: In line with what you're thinking, we could actually use all the ARIA spec and make it applicable for mobile.

shepazu: Don't understand...

<oedipus> http://www.w3.org/WAI/PF/aria-practices/

richardschwerdtfe: We could take the define the relation between device input events and application control with accessibility in mind.

<oedipus> http://www.w3.org/WAI/PF/aria/

shepazu: Topic interests me. Would be interested in being one of the editors; but probably not the only one.
... I'm hearing general agreement that htis work is worthwhile.

richardschwerdtfe: alignment with last call?

shepazu: I think that's useful. Talk about this potential spec and have it's first public WD align with the real Last Call for D3E for gap analysis. Make sure D3E doesn't define something that hampers us latter.
... I would expect 1st public WD sometime in Jan.
... I think that's doable. Especially if we get Google and Apple togethre to talk about these things.

<smaug_> background noise is getting even worse :(

MichaelC: Which WG owns this?
... still a webapps thing? maybe somebody from PS? joint publication? How do we get all the right people at the table?

shepazu: I think PF is needed. But also whoever else we need to have the right people here to find common ground.
... I'd be happy to technically join the PF WG.

Rich: We're also going to use the D3E architecture as well, correct?

shepazu: Yes, but most groups use D3E as a fundamental grounding for their events. That's just an assumption.
... Some groups don't use dom events, but we're trying to bring them into the fold to.

MichaelC: I wouldn't want this to have the flavor of an accesibility only spec.

<smaug_> to get more input from browser implementors, webapps wg should be actively involved

shepazu: Wouldn't want to slow this down by making it go through a new charter revision.
... Wouldn't want to be in Touch WG because of IP issues.
... But I agree if it were best if it weren't seen simply as accesibility.

richardschwerdtfe: In terms of PF charters, can we do this in PF?

MichaelC: It's not chartered to do something like this. But we could charter this as an informal related thing. But we can deal with that offline.

Resolution: We will deal with high level intentional events in a separate spec that builds on DOM3 Events.

shepazu: Intend to do it in a timeframe that overlaps with the real last call of D3E.
... Probably need to have some email about scroll request and wheel events.

<MikeSmith> getting Chris Fleizach on a telcon might be worthwhile too

shepazu: with regards to beforeInput and this directio we're taking, does it make sense to you that we would look at this in a larger scope?

tonychang: yes, this seems fine to me. The end goal is the same. How we get there....I don't have a strong preference.

shepazu: Let's talk about graphics. mouse getCoordsAt()

MouseEvent.getCoordsAt

Travis: when you transform an element, most properties are relative to viewport.

shepazu: (doesn't agree)

Travis: the ones that aren't are the ones we want to talk about.

shepazu: (sees the light)

Travis: The offset are relative to the coordinates of the element. So what how should those be affected by transforms?
... Why on MouseEvents instead of just doc?
... Unles mouse event provides some sort of info that isn't intrinsically available.

<shepazu> http://jwatt.org/svg/tmp/mouse-relative-positioning.svg

jrossi: I don't think mouse events are the only place you deal with the issue of translating coordinates between different contexts (the viewport, transformed elements, etc)

shepazu: Agreed. It's surprisingly difficult to do this in a way that's logical and makes sense. It's unintuitive even after much work on SVG.
... I code SVG by hand and yet I don't remember this.
... The key part is that you have to get clientX/clientY. Generally this comes from the mouse. But sometimes it's just some generic point.
... should have been screenX/screenY but...

Travis: one example: getClientBoundRect

jrossi: needs to be abstracted from SVG.

shepazu: nothing SVG-specific, other than where concept of transforms originated. We can define in a way that you pass in a "point object" (regardless of type) or even the x and y and get back a point object.
... not taking in a point would actually be nice. Could be seen as a point contructor....pass in x/y and returns point object.

Travis: write it out like an API.....please?

<Travis> document.getElementById('transformedElement').transformedX;

<Travis> document.getElementById('transformedElement').transformedY;

<Travis> ??

<smaug_> This all should perhaps go to http://dev.w3.org/csswg/cssom-view/

<shepazu> Point DocumentInterface.getGlobalCoords(x, y);

Point getCoordsAt(x,y,element)

<Travis> Element.transformedClientX;

Travis: data is local to the element, right? It's the element that's transformed that's relative to. Why not put it on element itself?

jrossi: like on on Element, if you had elm you could just say elm.getCoordsAt(x,y)

smaug_: seems quite natural to go in css-om

<Travis> CSSOM-Views; seems like the right place to me too.

shepazu: I can see that. Only concern, would like to see this defined and in browsers. IE9?

Travis: tight timeline, can't commit, would need to discuss internally
... workaround is available

shepazu: workaround is somewhat obtuse

<MikeSmith> shepazu: ↑

shepazu: would like to take a stab at defining this in D3E. Wouldn't mind marking as "at risk" and it could be taken out in Last Call and go in css-om?

smaug_: Why do you want to have it in D3E?
... But what part goes in events? Doesn't make sense that D3E events is the place for this?

jrossi: agrees

shepazu: Put another way,...

Travis: <sings>

shepazu: <joins in>
... I think that putting it in D3E events might persuade MSFT to implement.

Travis: probably can't justify putting it in already. Fundamentally seems wrong to ram in through D3E.

<smaug_> jcraig: the ARIA part of the meeting started over an hour ago

Travis: Our SVG folks are interested in this. Could work with Anna to put this in CSS-Om.

shepazu: I'll recommend this goes in SVG/CSS transforms spec.

Travis: could mention we debated it and felt that it wasn't an events-related issue and felt like it was better suited for Element

shepazu: Feel like MouseEvent is missing this thing. Would like to put these as attributes on the MouseEvents rather than separate method.

<MikeSmith> scribe: jrossi

Travis: I think we're wise to push to another location so that the details could be more paid attention to.

Resolution: We will suggest this lives in CSS-OM or CSS/SVG Transforms spec.

shepazu: Wondering if we should take another shot at DOMActivate in this other events spec.

Travis: Certainly valid. Once again would want to understand why click isn't dragged back in the mix.

shepazu: Click doesn't do everything. If you just want to listen to an activation, click is cumbersome.

Travis: but now we'll be firing more specific events, hopefully, with this new spec

jrossi: yes, DOMActivate seemed too generic to me. More specific events with more meaning (in this new spec) will be more useful.

<shepazu> http://www.w3.org/2008/webapps/track/products/2

Missing .key values

shepazu: Issues raised by Microsoft

or not actually raised.....emailed to list...

shepazu: happy to add back multiple, also think there's some remote control type things that could be added

<shepazu> ISSUE-149?

<trackbot> ISSUE-149 -- The multiply and other key values are missing -- raised

<trackbot> http://www.w3.org/2008/webapps/track/issues/149

Resolution: add "multiply" back. Need to discuss if add and plus are the same thing.

<shepazu> trackbot: end telcon

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/10/13 18:24:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/MichaelC/Rich/
Succeeded: i/This is the first Last Call/scribe: jrossi
Found ScribeNick: Jacob
Found Scribe: jrossi
Inferring ScribeNick: jrossi
WARNING: No scribe lines found matching previous ScribeNick pattern: <Jacob> ...
Found Scribe: jrossi
Inferring ScribeNick: jrossi
ScribeNicks: Jacob, jrossi
Default Present: Shepazu, Janina_Sajka, Gregory_Rosmaita, Michael_Cooper, Rich, Joseph_Scheuhammer, Olli_Pettay, Art_Barstow, Travis, tonychang, MikeSmith
Present: Shepazu Janina_Sajka Gregory_Rosmaita Michael_Cooper Rich Joseph_Scheuhammer Olli_Pettay Art_Barstow Travis tonychang MikeSmith
Found Date: 13 Oct 2010
Guessing minutes URL: http://www.w3.org/2010/10/13-webapps-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]