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]
Steven Pemberton: The paper
deadline has passed.
Kurt Cagle: Dan MacCreary is putting
together a NO-SQL conference.
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.
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.
http://lists.w3.org/Archives/Public/public-forms/2011Jan/0020.html
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
</label>
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.