<Tina> Zakim: +04670855aaaa is Tina

<scribe> scribe: Steven

Roland: My regrets for the next 4 weeks

DOM 3 Events and XML Events 2

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]

M12N

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

Access

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

CURIEs

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

AOB

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: