Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minute)
Charlie Wiecha, IBM
Nick van den Bleeken, Inventive Designers
http://lists.w3.org/Archives/Public/public-forms/2009Jul/0006.html
John Boyer: Steven is out, but we
could still have the call as I am the main document contact. We
still don't have a transition call.
Charlie Wiecha: Steven had no news in
the last meeting.
John Boyer: There may be no blackout
period looming, but we should get underway. I'll make some phone
calls.
Erik, Charlie, Nick
Nick van: I did mine yesterday and
updated the zip file.
Erik Bruchez: I'm not sure which one
it was.
John Boyer: It's about a submission
with a root around SOAP envelope. http://www.w3.org/2009/03/04-forms-minutes.html#action06
Erik Bruchez: I need to double check
that.
John Boyer: Do we think there is an
affect on us?
Nick van: I've sent two messages, one
that we're using DOMActivate. For DOMFocusIn and DOMFocusOut, we're
using them too. They want to replace it with click. I asked if
there was a difference, because a double click can give two click
events but one DOMActivate.
Charlie Wiecha: And you or someone
else pointed out the difference in bubbling behavior.
Nick van: Yes, focusing.
John Boyer: I think the mail is going
on but people thinking it's the same. They're asking us to update
"our spec" but it's not from us.
Nick van: Doug Scheppers asked if we
could keep using our events as abstract events, but my response was
that we'd need to deprecate or dispatch all those events again and
we'd have more events. The DOM Level 3 ones provide good
integration, and they don't need to be dispatched twice.
John Boyer: I think Maciej S provided
a reference to quirksmode.org saying they wanted to deprecate them
because of the support issue. If you look into the reference, the
focusin focusout and activate events they want to use aren't
supported by anyone other than IE.
Nick van: ??? wants to go with blur,
focus and click but they don't bubble.
Charlie Wiecha: That's the current
proposal?
Nick van: That's DOM Level 1. Steven
would know, but I think they added DOMActivate for A11Y reasons.
Also DOMFocusIn and DOMFocusOut. Now they're saying that they
aren't necessary for A11Y any more.
John Boyer: I think it was for DI,
with "click."
Nick van: If you read the draft for
DOM Level 3, its says "click" is activated when sent by voice. So
they're trying to make it more generic.
John Boyer: Another interpretation for
DOMActivate we had was that you could have an input receive
DOMActivate if someone hit the enter key. Is that true?
Nick van: We've implemented it like
that. But I think there's something in DOM Level 3 like that.
Charlie Wiecha: Click would not be
allowed on an input field?
Leigh Klotz: What happens when you
click on an input field?
Charlie Wiecha: Do you get focus? Is
it already focused?
John Boyer: It seems like clicking on
it might be a different operation.
Charlie Wiecha: I'm not so concerned
about the name, but double click and bubbling differences are an
issue. I'm not sure the name change is an issue between voice and
GUI.
John Boyer: I wonder if we should send
another message in the thread with another subject, DOMFocusIn !=
focus, DOMFocusOut != blur, etc.
Nick van: Someone sent email about the
difference in bubbling in the thread.
John Boyer: Maybe someone needs to
reply and point out the email which says they are different.
Erik Bruchez: [IRC] I committed a
change to 11.11.1.a on May 8...
John Boyer: [IRC] thanks Erik.
Nick van: I will look for that note
this evening.
John Boyer: I wonder what the status
of the decision is, given that they have pointed out something
that's different. It doesn't say anything about DOMActivate.
Nick van: I believe Anne said it was
only supported by one browser and so shouldn't be in the
spec.
John Boyer: I thought they would be
supporting IE because other browsers might follow.
Nick van: You can implement it in
IE.
John Boyer: As Ubiquity does.
Leigh Klotz: So maybe it's worth
pointing that out.
John Boyer: Anybody wants to send
email about where they're going with this? Any objections?
Nick van: It can be a WG
response.
John Boyer: I can see an email as an
individual. A WG response we should work on more. I'd ask where
they're going and point out we've implemented it in IE.
Nick van: I found the focusin vs
DOMFocusIn e-mail:
http://lists.w3.org/Archives/Public/public-forms/2009Jul/0017.html
John Boyer: So it's bubbling and
whether it gets focus before or after.
Nick van: So we'd need to re-dispatch
events in all implementations that implement DOM Level 3, and then
click vs DOMActivate. (Double click).
John Boyer: This email only talks
about focus in and focus out.
John Boyer: ... other than spelling do
we care?
John Boyer: Also there's no event
context. If we go to DOM Level 3, we'll adopt XML Events 2, which
would have to be based on DOM Level 3.
Leigh Klotz: So we'll have to fix it
ourselves in XML Events 2.
John Boyer: Whenever DOM Level 3
settles down. Anything else?
Charlie Wiecha: What's the system
interpretation for having two events? Are there ways to query
focus? Or do we not care?
John Boyer: That's what I was alluding
to before. There may be some other API to query. If the event
itself identifies the target element, you could ask it using some
alternative API.
Charlie Wiecha: So is there a global
API sense of focus, or is it only an end user concept?
John Boyer: It seems fuzzy.
Charlie Wiecha: I'll poke
around.
John Boyer: You can imagine a screen
reader wanting to read information, and when something new gets
focus, it would read information on the thing that just got focus.
It could use the target element in the event itself for something
that could "soon be getting" focus.
Charlie Wiecha: I've found something
about not finding a current focused element.
John Boyer: Screen readers tend to be
separate processes, sophisticated, and using Windows APIs. They're
doing this stuff already anyway. It reduces to interpretation of
activate.
Charlie Wiecha:
keyboard.focusedelement, a system static property.
John Boyer: Nick?
Nick van: I still need to make some
changes from the vF2F.
John Boyer: We'd talked about
indicating which syntax authors want in expressions. We'd need to
describe each function (invocation, behavior) in XPath 1.0 and
XPath 2.0. It seems like a good transition strategy. For XPath 2.0
we'd say you're enabled to use it (optional or recommended).
Nick van: I was writing that an
implementation could choose: http://www.w3.org/MarkUp/Forms/wiki/XPath_2.0
Nick van: There are some XPath 2.0
mapping issues for our processing model.
John Boyer: What changes do you need
to do?
Nick van: I still need to do the
default namespace for functions. Also there are a couple of
functions in XPath 2.0 that we need to drop from our namespaces. I
will try to do it this week.
Nick van: http://www.w3.org/MarkUp/Forms/wiki/Dialog
Nick van: ...
John Boyer: Do we need SNB on
dialog?
Nick van: People asked for it at the
vF2F.
John Boyer: And that brings relevance.
Or it could be in a group.
Nick van: Or we could make it a
top-level element. It makes it easier and I don't have to worry
about what happens when the node the dialog is bound to becomes
non-relevant.
Leigh Klotz: So it could go anywhere
in a host document but not in a group?
Nick van: Or case, or repeat.
John Boyer: So you can't do a repeat
to get multiple dialogs.
Leigh Klotz: It sounds like separating
dialog from components isn't quite working as we still have
use-mention problems with just one instantiation of the
dialog.
John Boyer: If you're in the dialog
and you type the first name and that goes into the data model and
that commit causes a relevance rule to fire.
Nick van: You have the same with
switch and the switch can become non-relevant. That's why I'm not
firing xforms-dialog-open and close, because for switch we have
select and unselect events and they only fire when the switch is
relevant and non-relevant.
John Boyer: So in other words, it's
another instance of the author can shoot themselves in the
foot.
Leigh Klotz: It's just something you
could do. Is it a problem?
John Boyer: If it's modal and closed,
it's still open.
Nick van: Or we could say it's
non-modal when non-relevant.
John Boyer: Isn't that the same as
closing it? We have "steps a, b, c are taken and then handlers are
disabled." So we could just close it.
Nick van: I tried that but the problem
(?) was that close is cancelable, so someone can cancel the close
event, and the dialog wouldn't close. But for non-relevance, the
dialog will be closed and non-relevant.
John Boyer: The close event default
processing releases the modality?
Nick van: It closes the dialog. When
the node becomes relevant again, the dialog pops up again. The
state isn't changed to closed.
John Boyer: Maybe it would be better
to have the state be non-cancelable. Something might need to be
valid before the dialog closes.
Nick van: ...
John Boyer: If the dialog becomes
non-relevant, it is still open and it releases its modality.
Leigh Klotz: Where is that state
stored?
Nick van: Like switch, somewhere
secret. A secret instance. An xpath function can access it. Same as
for repeat index.
John Boyer: OK. Any problems as
written?
John Boyer: Any context information
the open and close events should have?
Nick van: You should already know the
target.
John Boyer: Our event function doesn't
specify how to get the common event info. That's a weakness of our
event function. Erik?
Erik Bruchez: We offer it in the event
function. Type, Target, Bubbles, Cancelable, ... We put those
values as qnames. That's actually not DOM compatible but it's what
we did.
http://www.orbeon.com/ops/doc/reference-xforms-extensions#event-context
Erik Bruchez: In DOM 2 the context
information cannot be a qname because of the IDL for the events. In
DOM 3 they have two attributes, one for name and one for URI:
John Boyer: The event function is our
function and you defined an extension, in xxforms.
Erik Bruchez: If we did this in XForms
1.2 we don't need the namespace anyway.
Nick van: We use the names that are in
the IDL. http://www.w3.org/TR/DOM-Level-2-Events/idl-definitions.html
readonly attribute DOMString type; readonly attribute EventTarget target; readonly attribute EventTarget currentTarget; readonly attribute unsigned short eventPhase; readonly attribute boolean bubbles; readonly attribute boolean cancelable; readonly attribute DOMTimeStamp timeStamp;
John Boyer: We should have an
action item for XForms 1.2 to do this.
Erik Bruchez: It's very useful.
Action 2009-07-29.1: Erik Bruchez to create XForms 1.2 wiki page about event context info using http://www.orbeon.com/ops/doc/reference-xforms-extensions#event-context and http://www.orbeon.com/ops/doc/reference-xforms-extensions#event-context ending with four dashes, newline, left bracket dquote CategoryXForms12 dquote right bracket.
John Boyer: You exposed type,
target, bubbles, cancelable. There's also currentTarget,
eventPhase, and timeStamp. Do we need those?
Nick van: I added target in
Chiba.
John Boyer: What's
currentTarget?
Nick van: The id vs the node. It only
works because Chiba and probably Orbeon gives an id to every
element.
John Boyer: What's the difference
between target and currentTarget?
Nick van: Not sure...retarget?
John Boyer: They are readonly.
Nick van: It's not the target of the
event, but the element currently processing the event.
John Boyer: It seems like we'd want
that one as well. We could return a string in phase instead of
unsigned short. Then timestamp? Maybe return it as a string?
John Boyer: Erik is that OK to add the
few more things?
Erik Bruchez: We return an id for the
target.
Nick van: I return the real DOM in
Chiba. But that cannot be demanded because we don't require
DOM.
Erik Bruchez: That's why we return
identifiers. So it's a possible difference.
John Boyer: ID or empty string?
Erik Bruchez: Or the actual element if
there is a DOM. We didn't want people to start doing stuff with
that DOM so we used the id.
Nick van: It's readonly.
John Boyer: The node can be readonly
but it can get interesting...
Erik Bruchez: It's OK for us. But what
do we do now?
John Boyer: ID. String, boolean,
number, or XPath node. What's the author likely to ask for
anyway?
Nick van: I needed an attribute on the
element.
John Boyer: Not the ID?
Nick van: It's not a big problem that
it is an extension.
John Boyer: So we can call it
targetID?
Nick van: It's ok.
Leigh Klotz: Any change to the action
item?
Nick van: Erik knows he needs to
rename the target.
John Boyer: Why is the @visible
attribute needed?
Nick van: Whether to display on page
load, for modeless dialogs.
John Boyer: Probably xforms-ready.
Does it come up a lot?
Nick van: Orbeon has it. I dropped
some attributes but not this one. It's more declarative than a
handler on xforms-ready.
Erik Bruchez: It's like
case/@selected.
Nick van: ...
John Boyer: We can add a note in the
thin spec to say that the processing of the @visible attribute
occurs as part of UI construction during
xforms-model-construct-done processing.
John Boyer: And @draggable?
Nick van: It's probably not that good
for non-graphical browsers.
John Boyer: It could be a hint.
Leigh Klotz: Is there some way to say
this in CSS?
John Boyer: It's something you send
for the call itself in these JS libraries. Treat it like
appearance.