W3C Forms teleconference March 2, 2011

* Present

Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Leigh Klotz, Xerox (minutes)
John Boyer, IBM
Kurt Cagle
Uli Lissé, DreamLabs
Erik Bruchez, Orbeon
Alain Couthures, AgenceXML [joined late]

* Agenda


* Previous Minutes

* Restful Design Workshop


Steven Pemberton: The paper deadline has passed.
Kurt Cagle: Dan MacCreary is putting together a NO-SQL conference.

* US Daylight Savings Time

Leigh Klotz: It begins March 13, 2011. Our teleconference is set by the time in Cambridge, Massachusetts, so it will be one hour earlier if you're not on daylight savings time (Summer Time).
Steven Pemberton: For two weeks it will affect us in Europe.

* W3C HTML/XML Task Force


Kurt Cagle: I caught the last half of this week's meeting. Ian Hixson laid out his plans of XBL 2. He said he's trying to eliminate namespaces and make it work within constraints. The activity of the last few weeks has died down. There is some discussion on micro-XSD. They're beginning to add edge-case support back in and it's getting back to not-quite-micro.
Steven Pemberton: What was the XBL 2 about?
Kurt Cagle: There were some comments from Norm Walsh about people using dozens of namespces, but there is a core contingent convinced that namespaces are evil. I didn't catch anything about the HCG meeting.
Steven Pemberton: We confirmed the next date for XBL discussion, March 11. Art Barstow is chair of the group that XBL 2 is meant to be happening in, and has time difficulties, but he will try to turn up for that meeting.

* Form Control Labels, label/@xml:lang, label/@for

Steven Pemberton: I looked at my usage of labels and found that context nodes would make mine break. Erik replied that it covers a lot of cases. I would prefer a solution that covers all the cases, and we should try find a general solution.
John Boyer: The solution you're proposing is the same one we're doing in our design environment, for the same reasons. We associate the XForms label with the control, for context node and accessibility. I may want to see that differently in a 2-d channel (display), so we use a separate presentation label mechanism that can refer to the label of an XForms input. One tells the XForms input to suppress the visual display of that label, and another that tells a "column header" label to display from elsewhere. We do that in XFDL, but mechanically it's the same idea and seems to work best.
Erik Bruchez: I already tried to make a case for simple label/@for. There are lots of benefits to the approach I had proposed. The two main benefits are (1) it's what people are used to with HTML, and we can also do hint and help. (2) The syntax is important. I understand the use case for the indirection, but we should try to make the syntax lightweight. If the use case is strong, we can certainly see whether more needs to be done, but we need something lightweight.
Leigh Klotz: Why don't we do both?
John Boyer: I'd agree that we do it that way and we'd like to have the current XForms schema valid. The bulk of the issue is more about making sure the processor knows about accessibility message to render.
Steven Pemberton: I agree it shouldn't be heavyweight. I don't agree that doing it like HTML makes it easy to use. I imagine that authors wouldn't have trouble learning it if it's likeweight.
Erik Bruchez: It's an obvious opportunity to do something not too different.
Steven Pemberton: I'd like to see all the cases addressed.
Erik Bruchez: I haven't see a good case. We put the label inline and have proposals for @xml:lang with on-the-glass localization. In other circumstances, labels can be in a separate instance or a separate model. That's how people have addressed I18N of forms with the ability to have resources in a separate XML document, and the context isn't important because it's a different document, and I'd argue that's good practice. We have had cases with a "UI definition schema" with a big XML document containing input/label/data all mixed, generated from an external form description, and that does happen, but it doesn't seem like it's the common scenario.
Steven Pemberton: I use it and I'd be cross if there were disallowed use cases because of the choice of moving labels out of the control.
John Boyer: I'd like to make an observation about the raw mechanics involved. If you look at label/@for for colum headers, there's only one thing you have to do: you provide the label with @for for the column header. It feels like you're doing one thing. When you do the other way around, where the label is inside the XForms input, it seems like you have to do two things: another separate construct to tell the label to appear as a column header, and tell the label not to show itself. That preserves the context node but is more work.
Kurt Cagle: When I put that proposal together, I thought about column headers. In order to maintain cohesiveness, your context is row-based. If the input field appears within a given repeat element, the @for is based on what the current index for the repeat is. One implication is that potentially, different elements could have different labels. That's a fairly minor use case, but it's something you almost have to do.
Leigh Klotz: <label for="foo"> ...<input ref="a" id="foo"><label appearance="none">here we go</label>.
Steven Pemberton: <labelfor label="foo"/> ... <input ref="a"><label ref="..."/>
John Boyer: The user has to do only one thing then.
Nick van: I'm still worried about inputs in the repeat; it's confusing that it's bound to the current repeat. Outside it's not repeated. If the label isn't in the same repeat level that's a bit strange.
John Boyer: Your semantic Steven with id with id would drill into the repeat and display the label from the current indexed label. Your labelfor content would change.
Leigh Klotz: If you change labels you probably want that. If you don't change labels you won't notice.
Erik Bruchez: It seems like it has value. The prime use case is a homogeneous list of rows with a header at the top of the table. The point is well made that if the context of the label is ambiguous you have a problem. This solution make that problem go away.
Kurt Cagle: It comes down to the fact that the data model requires it for the context. If it either contains a text node or a reference to a string, it's just a question of the context of the label, and logically it seems to be the current indexed entity within the row.
Steven Pemberton: So you're saying that if you have a label outside the thing itself, it inherits the context from that thing.
Erik Bruchez: How does that relate to index? The index is a little funny. It gives the currently-selected row. You could say the context depends on it, but we don't need to have that. It's complex but doesn't cover a use case.
Kurt Cagle: If you have a label outside the control you have to go with an index if you pull it from the control.
Erik Bruchez: The case is clear and well-made. For usability, I could well imagine that if you click on the label outside the repeat, in today's browsers (without repeat of course) it would focus on the control. It's good for A11Y as well. So we could allow the user agent to associate with the row with the current index. Now from an XPath context point of view, I think that's confusing. You'd have to know about its context and know somewhere else and that would be the only place that would happen. If there's a pure indirection, it's less of a problem because.
John Boyer: For the table use case, the most typical thing is a group that binds to the parent node of the set of nodes that are being repeated and put the labels so that it inherits that group's context node. If you want labels associated with a repeating construct, that's when you'd use a group.
Kurt Cagle: I'd be inclined to say that makes sense, but if you did create the strong binding that would happen. I think the argument are strong in saying you need to maintain the local context.
Steven Pemberton: I think it would be a change for us to say something inherits its context from something other than the textual environment it's now in.
John Boyer: I agree. Steve are the use cases to do with tables?
Steven Pemberton: I'd have to go check. Some are related to the data binding and not to a table or a repeat. In some cases the label came froma preceeding-sibling.
John Boyer: Or an attribute. But was it inside a table?
Steven Pemberton: Yes, an attribute. But not inside a table.
John Boyer: We're not talking about getting rid of the current element.
Steven Pemberton: We are addressing a use case and I think CSS should have addressed it.
John Boyer: With repeat/input/label I'm not sure that's moving the label about. That's 20 labels for 20 rows. I just want one column header.
Steven Pemberton: In many of those cases the labels are the same.
John Boyer: From a runtime object standpoint, I wouldn't want 20 labels anyway. So I don't look at the repeated issue as one of moving the label around.
Steven Pemberton: Here is another point of view. If you want to do this, you need a heading with empty text or blank. On the other hand, the reason you have label/@for is because in HTML controls don't have labels and you want to link the label with the thing. That's important for A11Y. In XForms, the fact that you might use some other presentation for labels isn't non-accessible itself. So I'm wondering whether the problem of having headings is real.
John Boyer: It doesn't seem real right now to me, because we create an output as the column header and separately we create an XForms repeat/input/label. Stylistically we say to suppress the presentation. So the problem goes away. The screenreader gets the same.
Leigh Klotz: If you do it by convention then people will leave the input/label blank and put text elsewhere and you lose A11Y.
John Boyer: It's easy to use CSS to suppress it.
Leigh Klotz: But it's easier not to put it in, and you do it because you have to abide by A11Y guidelines but most don't.
Kurt Cagle: I concur.
Erik Bruchez: I understand what you're saying and we don't enforce labels. Realistically we allow blank label. If your implementation blows up you go crazy. You put it in the control because it makes sense. If it makes sense it makes sense.
Leigh Klotz: I am saying I don't think status quo is a solution.
Erik Bruchez: Clearly, label/@for is stronger and clearer.
Leigh Klotz: I don't care about which direction the arrow goes as they both preserve the aspect that a side effect of authoring the form makes it accessible.
Steven Pemberton: And that's important.

Kurt Cagle: With submission/@resource and switch/case, does the context matter? In the proposal I made, I introduced a label/for child element with a value. The analog is the same situation with case in XForms 1.1, with toggle and dynamic cases. Is that something that needs to be considered as well?
Erik Bruchez: That comes down to use cases. In script you can do that; you can change the label/@for attribute. Certainly that's the case in HTML. In XForms for dynamic values we use child elements, or AVT which is what I prefer. So the mechanism can make sense. But as far as mandating it, I'm not convinced it's needed.
Steven Pemberton: I can't think of a case where you want a label to be for different controls at different times.
Kurt Cagle: I have some tentative use cases; let me play with it.

Leigh Klotz: I'd like to get back to Steven's proposal: why not just say label/@for is empty.
Steven Pemberton: Sure. You could suppress it automatically.
Leigh Klotz: I'd prefer label/@for not suppressing it and have input/label/@appearance. It's fairly lightweight. It works for XFDL.

    <label for="foo" />
    <input ref="abc" id="foo">
    <label appearance="none">
    This is a test

Steven Pemberton: I could live with it.
Erik Bruchez: I think this isn't a common use case. Is it empty?
Leigh Klotz: It's a combination.
Erik Bruchez: It's a lot of mechanism.
John Boyer: It's a lot of work. We could have this syntax work, but <label for="foo">>xyz</label> would work.
Nick van: I find the syntax hard to understand.
Leigh Klotz: But I thought we were avoiding the context node.
John Boyer: No it's the same as always.
Leigh Klotz: So you can do both?
John Boyer: Yes. But the common use case is <label for="foo">abc</label>
Erik Bruchez: This is the best proposal that covers the use cases.
Erik Bruchez: I don't like label/@appearance="none" but it's bit of a drag to type.
Steven Pemberton: Do you really dislike the magic?
Leigh Klotz: I would say no but Alain and I have a done a project with label/help and the help/@href we use @appearance="minimal".
Erik Bruchez: The appearance might not be useful.
Steven Pemberton: I'd like to forbid label/@for inside a control.
Nick van: Excep for group/label/@for.

Kurt Cagle: So are there any action items on <xf:for> at this stage?
Steven Pemberton: No actions, but we're agreed on the label/@for and the magic appearance="none" suppression. We have to work out control/label/@for.
John Boyer: It maybe output/@for.
Steven Pemberton: We're pretty close.

* IRC Minutes


* Meeting Ends