W3C Forms teleconference June 4, 2008

* Present

Charlie Wiecha, IBM (chair)
John Boyer, IBM
Kenneth Sklander, PicoForms
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Rafael Benito, SATEC
Roger Pérez, SATEC
Doug Scheppers, W3C
Steven Pemberton, CWI/W3C
Keith Wells, IBM

* Agenda


* Previous minutes

* Newsletter

Leigh Klotz: I asked last week for people to read the draft http://www.w3.org/MarkUp/Forms/wiki/March-May_2008_Newsletter but got no responses.

* Next FtF (June 9-12, Amsterdam)

Agenda discussion http://www.w3.org/2002/09/wbs/32219/formsftf200806/

John Boyer: Should we have a work session at the F2F?
Steven Pemberton: We did that once before and it worked well.
Leigh Klotz: Test cases, in San Diego, at Netscape.
John Boyer: Yes, this time on spec text. Nick, can you focus on some spec text action items this week? I'll get the stubs set up.
Nick van: I did some spec text on implied submission but didn't finish it.
John Boyer: Do you have a thin spec on that one issue?
Nick van: I was working on the source bundle and have diffs. There are still changes from 1.0 in it. I'm not sure how to remove them easily.
John Boyer: I have a hack program to do that.
John Boyer: Submission is scattered around the spec (send, etc.). I'll try to find one I can write separately but I'm not sure.
John Boyer: If Mark Birbeck shows up he can introduce us to the message module and that can provide clarity.

John Boyer: OK, so we'll have a "work jam" with groups of two people on modules or action items. I'll talk to Leigh about XForms 1.1 issues, and then Nick and Charlie on model and submission.

Steven Pemberton: Is somebody going to volunteer to arrive here before 8:30 to let other people in while I let the kids off at school.
John Boyer: I'll probably be showing up early.
Charlie Wiecha: [irc] I can do Monday.
Nick van: [irc] I can do Monday.
Steven Pemberton: Great, Nick. On Monday we can then arrange Tuesday.

Action 2008-06-4.1: Nick van den Bleeken to arrive Monday at 8:20AM at Pembertonhuisje.

* Non-selected case and non-relevant group


John Boyer: In the past, we've made an analogy between them. In the case of a non-relevant group we talk about styling as visible-but-greyed out as opposed to non-visible. In the case of a switch being non-selected, I believe the thinking was that it was more highly unavailable. We haven't really come out and say that it's detectable and stylable.
Mark Birbeck: [joins]
Leigh Klotz: I've got a related notice. When you do xf|input color: red; display: block then disabled elements display. You have to do xf|input:enabled color: red; display: block . Maybe a CSS rule for :disabled is the wrong way implement this.
Nick van: That's correct according to CSS.
Leigh Klotz: It's not the right implementation with regard to the spec. It may be that there's a way to fix it, but I'm not a wizard. Maybe an exclamation point word work; a CSS wizard would know.
John Boyer: What about if the author uses !important
Mark Birbeck: In formsPlayer we use our own rules and make sure they're last so they override.
John Boyer: So it's a little hard implement non-relevant using CSS. And the second issue is that if you use styling for switch, you have no way to do it. It sounds like using styling to control disabled vs greyed-out works but not terribly well; we don't have anything for switch/case. Do we want to do anything about that?
Nick van: [irc] Mark, but with your approach the user can't style the non-relevant controls in another way then not visible.
Mark Birbeck: [out]
Charlie Wiecha: Some implementations can avoid delivering the content. So should we allow some content to be more unavailable? Not there, for events and styling. I'm not sure that was the right decision; I've come to places where I'd like to style the text differently based on whether I've visited those cases, but that's what we discussed in Raleigh.
John Boyer: I recall now a bit more of the discussion; we had some difficulty. We wanted to make it possible for server implementations to not deliver the content, but possible for others not to have to worry about it. So we ended up with this elaborate thing with non-selected cases being like non-relevant groups and detaching action handlers when the case becomes non-relevant. So pure client-side implementations could guarantee behaviors (action handlers wouldn't fire) without removing content from the DOM. They could receive events but do nothing with them.
Charlie Wiecha: That sounds like it.
John Boyer: So we focused on the behavior aspect, implementation neutral. But we didn't consider the presentation aspect of a non-relevant group. That's causing us a problem. In 9.2.2., it says that the content elements within a non-selected case behave as if they were in a non-relevant group. http://www.w3.org/TR/xforms11/#ui-case
John Boyer: So is it intentional that we cannot style non-selected cases? Does anybody allow it?
Mark Birbeck: Yes. A big problem for us was switches with lots of cases slowing down the load of the form. However, since then, we've refined what formsPlayer does and now we use a appearance="minimal" and appearance="full" to determine the behavior. If you say full, then all cases are pre-loaded and controls are there and can be styled, and you get events, so in a sense we break the spec. The non-relevant controls are CSS styled. For appearance="minimal" then we only load the first case on the load of the form, and we switch in the other elements of the relevant case, hooking and rehooking event handlers. The first scenario is useful for a small form with fast switching. The second is for big cases.
John Boyer: That sounds like an appearance, but a mode.
Mark Birbeck: Right, but that would be a new attribute.
John Boyer: There's only one behavior in the spec. The events can be dispatched, but the handlers aren't supposed to do anything. So you said that appearance controls that. That may be an issue for Nick and Erik. They want to receive the xforms-invalid event in the other cases.
Nick van: [irc] we implemented a tab-control in our namespace that does that
Leigh Klotz: It does sound like the spec is at fault. Mark is able to do it with an attribute, but John says that we are breaking the spec as it's appearance, not behavior. Nick used the spec-friendly route of using a new element, but it seems that's too heavyweight. John suggests that we fix this one issue on switch with an attribute. I think together this all means that we are missing a degree of freedom in the spec, though perhaps an annotation is in order.
John Boyer: We have the extension element but not the extensions attribute.
Leigh Klotz: Yes, maybe Mark "should" have used an attribute in his namespace.
Mark Birbeck: Actually, I could argue that appearance isn't just about appearance; consider select1 and its various behaviors. Here's a reason I propose an attribute to a new control: if you use a big switch on an iPhone, the expected performance is that it would switch panels in and out. So a mobile device could choose some way to implement it. The appearance clues tell the processor what you're expecting from the controls that are within the cases. The ability to optimize it shows that there would be further scenarios. So we can say it's a fairly high-level construct, and beyond that we can't be too specific on how it's implemented.
John Boyer: For interoperability, in the past, it's mattered whether the xforms-invalid event is dispatched to non-relevant content (group or case). We picked a direction.
Mark Birbeck: That's an interesting point. I remember being insistent that the events must fire, but then a couple of years of doing forms and projects, I'm not sure whether that level of interop is required. Whether you do put them in a nested case inside a switch inside a group, whether those things really happen.
John Boyer: I'm sure they do for non-relevant groups, for example, if you're not a senior citizen.
Mark Birbeck: There's cases switched out, and there's cases not relevant to the form at all. ... Unless you've put an event handler on the invalid which displays a message (I've never done that) ...
John Boyer: We got rid of part of it in the spec; we said that the rendering is implementation-defined. Alert is roughly associated with an xforms-invalid handler that produces a message that has the behavior. We said people might want after-content rather than a message action. A message action on an xforms-invalid would be one way of doing that.
Mark Birbeck: I thought one of the earliest examples had alert visible or non-visible, like a span displayed or not, inline. That's what I thought. Increasingly I've found that a lot of the things we protected against don't seem to be real, and we shouldn't paint ourselves into corners.

Leigh Klotz: I think it's telling that Mark had already implemented, based on real needs, what John was asking about with styling non-selected switch cases. Nick's approach is in the letter of the spec, with a new element. But my reaction is that it seems heavyweight. So perhaps the problem lies with the spec, and appearance isn't enough.
Nick van: ..
John Boyer: There's appearance and there's event behavior, and we need both.
Mark Birbeck: Right, there's two things: the driver (appearance="full" or banana:foo="foo") and what's driven (events). If I were teaching someone to write XForms, I would say not to rely on things that happen inside a case; don't put controls that need to receive xforms-invalid inside case, no matter what the spec says.
John Boyer: We need to discuss switch/case.
Leigh Klotz: And this behavior issue.
John Boyer: I think foreign-namespaced attributes and the xforms extension element ought to be enough.
Mark Birbeck: That only gives us the semantic hook. If I'd used banana:foo then I'd have changed the behavior in a way that's not consistent with a processor that uses ignores it. That's against the spec to say appearance="full". appearance="minimal" is the current spec. geo:map="true" would make an input display as a map. The events are the same.
Mark Birbeck: If someone said I've added a new behavior with my own xf:extension, I'd be against it, because I believe it's ok to use hooks, but they shouldn't change the underlying abstract behavior of things that are in our namespace.
John Boyer: My comment about @appearance is that I interpret it as literally affecting the appearance on the glass, as opposed to behavioral changes. So I believe it's a fairly minor point; some ought to be controlled by a differently-named attribute that we don't have at the moment. If we had @mode or something that wasn't so semantically tied to how it looks, you could use QNames or CURIES to indicate that. It's just the name. But secondly, your interpretation of the word "extend" is that it adds behaviors without changing existing behaviors; we're saying that you can "overload" behaviors with switch when extending it.
Mark Birbeck: I think that would be wrong.
Leigh Klotz: That's what you're doing though.
Mark Birbeck: Yes, I don't like it.
Leigh Klotz: I think you have the best solution so far. I'd like to push on this with you and Nick and find out where to take it. Right now, you can stick on an attribute, drop into XBL in Mozilla, or C++ in formsPlayer, or JavaScript in Ubiquity XForms, and do it there. So it may be that that's the right answer, and we just need that degree of freedom.
Mark Birbeck: I guess this will be on the F2F. I would argue that appearance is the right attribute. ... It's like having only one case element as a container into which you drop the other cases. You could argue that that's two different controls. Except I'd argue not, because it could be handled by a processor to display it. So it's the same conceptual thing to me, rather than inventing a new element. You look at a real-life thing and try to see how to express that in terms of our language. We found we almost have it, and need one tweak. switch/case is a general construct you find everywhere, but with minor differences, which we express with appearance.
John Boyer: So you need an attribute, like appearance, to express minor differences that are appearance and behavior. It sounds like you're doing add/change/delete of behavior. I typed this in IRC. I know we had mustUnderstand as an attempt to describe extensions; we got rid of it because we thought CDF would handle it. It's one thing to say that the Schema processor ignores foreign-attributes but it's another to say the XForms processor ignores.
Leigh Klotz: I think that adding mustUnderstand doesn't help. I think there needs to be a level of indirection that allows a blurring of the line between authors and implementers, so authors can write intent and then implement it elsewhere in a processor-dependent way (XBL, JavaScript, Java, XSLT in Chiba, whatever) without having to have code inside their markup. I think the mustUnderstand is for people who aren't going to implement it, which is a much less interesting issue than trying to figure out what simple markup to write to indicate the behaviors that are then going to be implemented.
Mark Birbeck: I agree but I think that we should also have the spec tie less stuff down to improve interoperability. Suppose we let the author find out in the event whether the switch is in a full or minimal model and choose to ignore the events. There are different ways of doing this. We want to hide the behavior again. We need to teach people not to rely on behavior in certain situations.
John Boyer: That runs a little counter to the philosophy that says I ought to be able to write content and aggregate it and have it still work in combination. So if I write a form that turns out to be one case of a switch and use xforms-invalid handlers, as soon as I put that in a case, everything is now wrong.
Mark Birbeck: This goes back to the earlier point. An xforms-invalid handler that displays a message I wouldn't do; I'd use styled alerts. If the subform is invisible, so what?
John Boyer: That's a bad example. In general, it's turning out that one of our biggest problems is that our UI events aren't terribly great.
Mark Birbeck: And too numerous. Our original version of switch/case had every control so every control would have every event. But now we don't. So you couldn't have depended on it. The first wasn't correct and now we're discovering the second isn't.
John Boyer: So is it undefined or can the form author say what he wants? In a couple of cases where we find non-interoperability, we've been picking a away. And maybe we need to a new way to control the behaviors instead. We've picked before because we were averse to adding attributes or values, but we need to quit doing that.
Mark Birbeck: Perhaps we shouldn't be too hard on ourselves; one criterion was performance with four megabyte forms. So switch/case was ideal for that. But I agree that remembering at each junction why we had the prior solution...
John Boyer: ...
Mark Birbeck: Part of the issue is that our abstract constructs could define many real-world thing. Consider tabs, with switch/case/labels and all cases visible, and hide child elements on non-selected cases. But to do that you need the cases visible so the labels show but not the children. So just slightly tweak what we have. So if you said appearance="tabbed-dialog" it might bring a bit of tweaking.
John Boyer: We were careful about the wording for case. It doesn't say the case is not relevant, but that their contents of their form controls behave as if they are non-relevant. That was to allow appearance to create compact dialog because the label on the case is not a form control.
Mark Birbeck: That's true. Remember correctly selected cases and repeats. Linking back to your point about memory, I hope we can put these samples up with wiki and the reason with sample markup.

John Boyer: Sounds like we need to reexamine switch more closely.

* IRC Log


* Meeting Ends