See also: IRC log
<Tina> Zakim: +04670855aaaa is Tina
<scribe> scribe: Steven
Roland: My regrets for the next 4 weeks
Roland: We want them to align
... Doug can you update us on DOM 3 Events?
Doug: Having reviewed XML Events 2, I didn't
see any incompatibilities
... but it is good to coordinate
... we have changed mutation events a bit
... Mozilla are not going to implement certain mutation events
... so there is no consensus on them
Roland: We have no dependencies on the mutation events, but what is the problem?
Doug: I'm sorry, I don't have that to hand
... but it is something that requires a significant change, and performance
hit for browsers
Roland: Are these new events?
Doug: No, also in DOM 2, so we may be
deprecating them
... SVG Tiny has a problem with them too
... because of performance hit
... so there is a challenge of finding something that has consensus
... We are also planning on defining event ordering
... Also changing the key identifiers
... a better model for providing values for key identifiers
... also an order for event firing
... but I saw no clash iwth XML Events 2
Steven: XML Events is just a syntactic binding to DOM Events, so it would be bad if there was a clash
Roland: Have you dealt with the I18N problems with key events?
Doug: We are working on it
... including the issues of shifting characters
... to upper case
... I do have a couple of minor comments on XML Events 2; I will send them
in
Roland: We want to go to last call really soon; what is the status of DOM 3 Events?
Doug: Q1 for CR
... I wouldn't make a dependency on DOM 3
Roland: Well, we want namespaced events
Doug: The WHAT WG are trying to get me to
remove namespaced events
... but that hasn't happened
Shane: I think it should be changed from QNames to CURIEs
Doug: Unlikely
<oedipus> SP: independent of qnames and curies - Dom3 uses event space and event name - 2 are never combined into URI as such; up to syntax, not Dom3 - would be surprised if you have to mention curies; whichever you use, they will work identically
Shane: I disagree
... at processing level it is a URI
<oedipus> SP: never combined into single URI - always separate - qnames better solution
Steven: But you have a namespace, and an event name; they never get combined into a URI, so QNames are a better choice if you have to use them at all
Doug: There are a couple of new non-namespaced
events
... We want to go to CR at latest Q1 2009
... so where is your implementer base?
Steven: XForms would where we expect them to come first
<oedipus> SP: use case for "while" being able to delete all elements in a tree that match a certain condition
Doug: Where is the use case for your while= in XML Events 2?
Steven: Being able to delete all noeds that match a certain condition
<Roland> http://www.w3.org/MarkUp/2008/ED-xml-events-20080620/#section-listener-element
Doug: We are trying to make the target phase more visible
Roland: The default phase is for compatibility with the old version
Doug: The reasons for the handlers wasn't clear
Steven: To allow people to be able to use something already defined wihtout having to invent it themselves (as with XML Events 1)
<oedipus> XML2 Events will eventual break out into Handler, Listener, and Script module
<Zakim> oedipus, you wanted to say question from PFWG - "Does mixing roles and ids with targetrole and targetid for @order OK, or does it pose problems, and if so what problems?" (i am
Gregory: About access key; is there a problem
with roles and ids?
... I think the current solution is a good one, but we want confirmation
Doug: I don't see where it would cause a problem
Shane: You can only have one or the other, not both
Doug: Well, one is ignored if you have both
Shane: Right
<ShaneM> targetrole is ignored if both are specified.
Gregory: Thanks, I'm glad we agree
Greg: With @order, we want people to be able to go through primary content, and then secondary content and so on.
Shane: And where do you start?
Doug: Document order from the current focus
Shane: Doesn't that clash with @order?
Doug: I need to think about that
... if I want to tab from my current focus,
... then without @order then the next in document order is selected
... with @order, then it goes to the first in the list
<oedipus> SP: stateless - regardless of current state, defaults back to same?
<oedipus> SP: if in a b carry on going to other bs
<oedipus> SM: possible to make stateless if defined "if no item that would be selected has focus currently, start with first one in document order, otherwise find next one in navigation order
Doug: This allows for a richer way to navigate
<oedipus> DS: jump to Bs with mouse, when in there, can keyboard navigate the Bs
Doug: jump to the Bs and then navigate around them
Shane: Also solves the problem of what happens with a DOM mutation
Steven: Absolutely
Shane: I will write this up
... I am editing the document now
Roland: When will you publish your next draft, and what stage will it be at?
Doug: It will be a WD
... in a month or so
... we are working on SVG at the moment
... so I don't think I can do it this month
... and there are still some unsolved problems
Roland: Thanks, we will keep in touch
<oedipus> thank you very much, shepazu
Doug: One other thing
... no, I'll send it by email
[Doug leaves]
Roland: Any news?
Steven: I haven't scratched the surface of my email since I got back last night. I'll keep you in touch
Shane: I looked at the comments
... related to the DOM 3 Events issues
<oedipus> i18n comments start at: http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0006.html
Shane: the issue is that @key is inadequate
<oedipus> key attribute inadequate: http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0007.html
Shane: and I'm not sure that there is a right answer. We took it over from HTML4
<oedipus> "The term 'access key' seems to be used to refer to the value of the key attribute in one part of this section, and to a key on a physical keyboard in other places."
Roland: We should work on a way to deal with the problem
<shepazu> I also raised a similar point, and I think you should use the keyIdentifier
Shane: I'm not sure there is a solution
<oedipus> PF's Proposed Requirements for Access/Accesskey in HTML5: http://esw.w3.org/topic/PF/XTech/HTML5/AccesskeyRequirements
<oedipus> SP: what do people do in japan with keyboard shortcuts? idea is use a key that matches a character
Roland: Multiple key depressions in Japanese
<oedipus> RM: keys don't generate kanji characters - part of character
Kaz: We use ascii characters for shortcuts
Shane: There are also some editorial comments
<oedipus> "It isn't clear that this section has taken into account the potential difference between key codes and the characters that may result from a key press on a given keyboard. It seems to assume that the character on a key cap == the key code identifier == the character produced by pressing that key == the character that is the value of the key attribute." - http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0008.html
Shane: I still need to work on the policy of evolution of modules
<kaz> input "nihon" -(Imput Method software converts it to)-> "日本"
<oedipus> thought we agreed to 3 modules from Events: Handler, Listener, and Script
Roland: We had an email from Noah
Steven: I see that the TAG can't respond on our timescale
Shane: Didn't we ask for last call comments in
May?
... I think we should extend our timeline to accomodate them
... even though we asked 5th May originally
... The TAG wasn't on our original list
Steven: No, we didn't think CURIEs had architectural ramifications
Shane: But we should wait
Steven: Agreed
<alessio> +1
Steven: Their FtF is September, ours October, so we can accomodate them with no pain
<oedipus> plus 1
Steven: You're away for 4 weeks, so have a good holiday
<oedipus> enjoy your well-earned rest, rolland
[ADJOURN]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/non-/new non-/ Succeeded: s/;/'/ Succeeded: s/order/order?/ Succeeded: s/;/'/ Succeeded: s/ on / with / Succeeded: s/thinkl/think/ No ScribeNick specified. Guessing ScribeNick: Steven_ Found Scribe: Steven Default Present: Kazuyuki, +04670855aaaa, Shepazu, Roland, Gregory_Rosmaita, ShaneM, Alessio, Steven, +1.914.255.aabb, Tina_Holmboe Present: Kazuyuki +04670855aaaa Shepazu Roland Gregory_Rosmaita ShaneM Alessio Steven +1.914.255.aabb Tina_Holmboe Agenda: http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0004.html Got date from IRC log name: 06 Aug 2008 Guessing minutes URL: http://www.w3.org/2008/08/06-xhtml-minutes.html People with action items:[End of scribe.perl diagnostic output]