W3C Forms teleconference November 25, 2009

* Present

Nick van den Bleeken, Inventive Designers
John Boyer, IBM (chair)
Charlie Wiecha, IBM
Leigh Klotz, Xerox (minutes)
Erik Bruchez, Orbeon
Steven Pemberton, CWI/W3C

* Agenda


* LC response on XHR


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

* Schedule and choose site for Next Face to Face

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.

* Recharter request

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.

* normalizedString


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.

* Improvements to UI events

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.

* IRC Minutes


* Meeting Ends