Nick van den Bleeken, Inventive Designers
John Boyer, IBM (chair)
Charlie Wiecha, IBM
Leigh Klotz, Xerox (minutes)
Erik Bruchez, Orbeon
Steven Pemberton, CWI/W3C
Leigh Klotz: I didn't list the
individual dependencies, just asked that they go in the other
direction.
John Boyer: Any objections? Can you
send this answer?
Charlie Wiecha: I recall some pushback
before.
Steven Pemberton: They are other
people arguing that "window" be moved out of HTML5, but their point
is that they don't have an editor for it.
Action 2009-11-25.1: Leigh Klotz to respond to XHR last call with http://lists.w3.org/Archives/Public/public-forms/2009Nov/0016.html
John Boyer: I'm approved to host
the meeting in March. Steven said is available as well.
Steven Pemberton: It was either
Victoria or Amsterdam.
Nick van: The Olympics are in your
area in March; when do they end?
Steven Pemberton: The AC meeting is in
Boston week 12 in March in Boston. April 12th is Easter.
Charlie Wiecha: I can host it in
Cambridge if we need.
Nick van: Hotels will be crowded until
the end of March.
Steven Pemberton: In Victoria?
Nick van: No, Vancouver.
John Boyer: March 23? March 30 is too
closer to the Easter weekend. April 3rd is a holiday.
Steven Pemberton: And April 2nd for
us.
John Boyer: How about 22-25 to have a
longer meeting and then the Tech Plenary and avoid travel.
Leigh Klotz: Looks ok for me.
Charlie Wiecha: I can host on the East
Coast as well.
Erik Bruchez: What are the
options?
John Boyer: Amsterdam, New York,
Victoria.
Erik Bruchez: Victoria's closer for me
and might work better.
John Boyer: Would you be able to make
it regardless of location?
Erik Bruchez: It's too hard to
say.
Nick van: For me, Holland is easier,
but I think the AC Meeting will be close by, so having it on the
same continent is a good idea.
Steven Pemberton: The AC Meeting is in
Boston.
Nick van: I meant the TPAC, having the
meeting and the TPAC in the same continent.
John Boyer: It may be too early to
choose.
Steven Pemberton: We'll also be
issuing a call for new members. We should let the new members join
in the decision making.
John Boyer: OK.
Steven Pemberton: So let's pencil in
the date and re-ask the question.
John Boyer: Anyone given thought to
co-chair?
Steven Pemberton: It would have to be
done in the 25%.
Leigh Klotz: Charlie, you offered to
co-chair for the rest of this year.
Charlie Wiecha: I don't know about
chairing next year.
Leigh Klotz: Erik?
Erik Bruchez: I can't.
Nick van: Same here.
Leigh Klotz: I guess that leaves
me.
John Boyer: OK, we'll see how the
request goes.
John Boyer: There was no action item on this yet. Looks like we need to spend time on it. It will stay on the agenda, perhaps for December 10th.
John Boyer: Uli isn't here.
Leigh Klotz: I have a question about
related events; do you get an xforms-select on all your cases at
startup?
John Boyer: I don't know
offhand.
Leigh Klotz: This issue may be about
startup.
Nick van: You get them multiple times
when nothing has changed.
Leigh Klotz: That's the problem and
our solution involved not sending events at startup, and the two
different event types upset Uli. So I've shown here that we can't
offhand answer another question about cases at startup.
John Boyer: So we say the UI is
constructed, and select1, and we don't say it in event sequencing.
We talk about when the user changes something. That may be another
disconnect.
Leigh Klotz: So that means you have to
listen for two events: xforms-ready (not
xforms-model-construct-done) for the default cases and then
xforms-select for the changes.
John Boyer: We don't say it's sent
when the case is initialized.
Leigh Klotz: So we have the XForms 2.0
switch/select1/@ref idea, but if you want to do that now you have
to start out with correct initial instance data and then maintain
it with xforms-select.
John Boyer: That's what we do in our
implementation.
Leigh Klotz: So I think this is
another way of looking at Uli's concern.
Nick van: The xforms-out-of-range and
xforms-in-range events aren't sent on startup either.
Charlie Wiecha: Is the concern startup
performance time?
Nick van: No, it's because most of the
time the form has to be filled in anyway and you know the data
isn't right.
Leigh Klotz: It seems like it's not
easy or in some cases not possible to track these states from the
events.
Nick van: An opinion: if you want to
know when the control becomes relevant, it doesn't hurt to listen
for xforms-enabled. If you have enough information in the event
context it's fine.
Leigh Klotz: What would the case get
sent then?
John Boyer: The switch, if it had
@ref, would get sent xforms-enabled. If you have a switch or group
within another switch or group and the outer one becomes
non-relevant, the inner ones becomes non-relevant but there is no
event dispatched to it unless it had a ref that also became
non-relevant.
Leigh Klotz: But it might be bound to
something unrelated.
Erik Bruchez: I would think a nested
group without a ref would get xforms-disabled. Relevant, unlike
other MIPs, is a more fundamental concept and doesn't requires a
SNB.
John Boyer: Right, we do say group
receives xforms-disabled even if it doesn't have a ref. And atomic
form controls.
Leigh Klotz: So how would you know
what case is selected.
Erik Bruchez: There was talk about
having a case function. Or dispatch xforms-select after
xforms-enabled. So we have two ways to communicate the properties:
dispatching events, or accessing through functions. Clearly there
are ways of obtaining that information.
Leigh Klotz: I'll send up an example
and see if we can find out case statements at startup and see if
that illuminates the concern.
Erik Bruchez: Uli said he wanted
listeners on xforms-enabled and xforms-disabled only.
John Boyer: We don't dispatch any
xforms-select events on startup and we don't have xforms-deselect
dispatched when the object becomes disabled.
Erik Bruchez: There's a general
pattern: validity, current selection, repeat index (we don't have
an event for that) and it would be nice to address the state
changes in the same way.
John Boyer: Right now the general
pattern is that you don't get new events when an object becomes
enabled for the first time, or when it becomes enabled after being
disabled. We don't send it a lot of events.
Nick van: In my opinion, that doesn't
hurt if we provide the information in the enabled event. Most of
the time, you won't listen for the enabled event, but only when the
control becomes invalid by the user.
John Boyer: Once the object has become
enabled, further state changes are when it gets the events. Maybe
Uli's point is that if we're going to fix it, we should fix it by
dispatching the events more frequently.
Nick van: Then the events become
unusable again or you have to use @if with complex
information.
Erik Bruchez: We started along that
path saying that we wanted to get enabled and disabled to be
sufficient, and dispatching more events (before disabled). Another
was controls keeping state. So we have some solutions but they
don't seem appealing. My feeling was that we might need to decide
on a tradeoff. Either you dispatch more events in situations where
they don't make sense (xforms-valid just before xforms-disabled) or
you need to be more flexible and use more than one event type.
Personally I feel that dispatching less events might be the better
solution, because a large form can dispatch thousands of
events.
Charlie Wiecha: The tradeoff is that
is it more complex for the author.
Nick van: Initial state for the author
is one thing, and after that listen for xforms-valid or
xforms-invalid.
Leigh Klotz: So how do I apply that to
case?
Nick van: The enabled event at the
switch can contain the selected initial case in the context
information. If you just listen for lifetime events, then you
listen for xforms-selected and xforms-deselected.
Leigh Klotz: So if my case becomes
re-enabled and becomes re-enabled does it get the xforms-enabled
event?
John Boyer: Yes.
Leigh Klotz: So here's a problem. How
does a group-relevant context-sensitive help switch find out the
state of a companion switch of form controls when the
context-sensitive help switch becomes relevant?
John Boyer: The case function.
Leigh Klotz: So we need case() and the
context info.
John Boyer: I think we already decided
on case. I'm not sure the context info is necessary.
Erik Bruchez: It's directly associated
with the event and is useful.
John Boyer: I'm not sure that it's
more powerful. We'd also need it in xforms-select when selecting an
item, and there's no id on them. It's relatively hopeless to add
for xforms-select.
Erik Bruchez: I think the idea is to
add it to xforms-enabled with optional context information; for
example, switch could have a selected-case-item. I'm not sure if
there are other examples. That information would be done by
overloading; xforms-enabled might or might not have
selected-case-item depending on the target.
John Boyer: Why add the complexity
when I know what the switch is and I can call the case
function.
Erik Bruchez: You can put listeners at
the appropriate level for id-resolution context, but for generic
operations (tracking errors) and you listen on a toplevel group or
form and so nested repeats give you issues for id resolution.
John Boyer: I think you have those
problems anyway; once you know the case, you don't know which
object it came from.
Erik Bruchez: In our implementation,
we add the hierarchy of repeats. Otherwise we cannot make
distinctions between one object and another. If it were
object-oriented, we'd have a reference to the object, but all we
get is a path, and we need some idea of iteration. It's hard to
avoid passing that if you need a unique object.
John Boyer: That's if you listen on an
ancestor of the target of the event.
Erik Bruchez: Yes. Both scenarios are
valid. Locality is the right way sometimes. There are benefits to
being as local as possible. On the other hand, if you want to
maximize re-use, having something with context information is
useful.
John Boyer: So it's useful for the
non-local case.
Erik Bruchez: We do repeat-hierarchy
but not case.
John Boyer: So you'd need that
information on both xforms-enabled and xforms-select in order to be
able to track what's been selected at a higher level.
Nick van: For select you have the id
of the element,
Leigh Klotz: Erik's point is that you
don't have the id of the element if it was in the repeat.
John Boyer: xforms-select is targeted
at the item or case; in the case of item, you likely don't have an
id. In the case of case, you have an id but it could be
repeated.
John Boyer: That's an orthogonal
point: a single event, or two events, enabled and select. So do we
want to tell people they need two events: enabled and state-change
events?
Nick van: There are cases where you
want states from the beginning, and cases where you want only the
changes.
John Boyer: What is one such
case?
Nick van: Only after. To show
help.
Leigh Klotz: Steven points out we're
running out of time.
John Boyer: I'm interested in the
CSS pseudo class for a control invalid in its initial state. I've
recently been doing more work on "providing a list of what's wrong
with the form." From a styling standpoint, we tend to want to show
that something is not quite right with a control, but don't want to
list it as broken.
Nick van: Most implementations have a
"visited" class. So you can have a css selector that says visited
and invalid.
John Boyer: I'd like to pick up with
that on the next call.