See also: IRC log
<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()
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
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
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]