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
http://lists.w3.org/Archives/Public/public-forms/2008May/att-0069/2008-05-28.html
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.
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.
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.