Charlie Wiecha, IBM
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Birbeck, x-port
Nick van den Bleeken, Inventive Designers
Rafael Benito, SATEC
Roger Perez, SATEC
Steven Pemberton, CWI/W3C (chair)
Keith Wells, IBM
Mark Seaborne, DreamLabs
http://lists.w3.org/Archives/Public/public-forms/2007Aug/att-0048/20070815
Attendance Questionnaire: http://www.w3.org/2002/09/wbs/34637/ftfsept2007/
Steven Pemberton: We have just enough
to go ahead with it, as of today, but it will be a small
turnout.
Steven Pemberton: John wants us to
look at this. A few had sent comments.
Leigh Klotz: My comment was about
input vs. textarea. We may not be buying ourselves any favors by
trying to specify this. Also, polymorphic type binding, input vs.
secret, accessibility, etc.
Steven Pemberton: Good point. What is
the essential difference? textarea is always bound to string
whereas input isn't?
Mark Birbeck: We've discussed this
before. It's not clear there's very much you can say about controls
because of various widgets, device independence. Can you say you
must make it bigger? Do Kenneth and David make it bigger? Can I
render select1 with two choices as a checkbox? There are so many
things to account for.
Steven Pemberton: There is an
essential difference between an input and textarea; when the
control has focus, how does hitting return get interpreted. When a
textarea has focus, return gets you a newline.
Mark Birbeck: I've been on lots of
sites where control-enter or alt-enter is required. And what does
that mean in a voice system?
Charlie Wiecha: Yes.
Leigh Klotz: Steven, maybe we need to
say more about textarea instead of input, since textarea is the odd
one. It must be bound to some text type.
Steven Pemberton: If we need to say
anything it is more vague.
Mark Birbeck: I'm not sure we need to
say more; it's like a hint. I see it as the same as input
appearance=full if you want to get geeky.
Steven Pemberton: If I could
summarize, it is the opinion of this working group that we don't
want to say anything about how the controls work, but let the names
suggest what they might be for.
Leigh Klotz: I think we say already
stuff about textarea. It's just I don't think we need to add
this.
Nick van: On the readonly property, we
discussed this last call.
Steven Pemberton: Let wrap up input
textarea. So we are of the opinion that this text shouldn't be
there? Anybody object?
Resolution 2007-08-22.1: We do not accept the "return" change to input.
Nick van: If the model says the
item is readonly, I don't think an action can change it. We said it
was clear that it can be done and now we're changing it. If the
model says it's readonly, as Mark Seaborne says, then the model
designer says it is readonly then it's the responsibility of the
model, and not the view.
Leigh Klotz: You're talking about
setvalue?
Nick van: And insertions in readonly
subtrees, and maybe submission that places its results inside a
readonly subtree.The previous wording said that if a tree is
readonly, no changes are allowed. The submission and insert aren't
said explicitly.
Leigh Klotz: I just meant we can't
replace subtrees in submission.
Nick van: We can in 1.1.
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0057.html
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0057.html
Steven Pemberton: You've convinced me?
Mark Seaborne?
Mark Seaborne: It worries me that we
say that some MIPs apply only to the UI, whereas other MIPs don't.
We aren't saying you can override calculate. I think it raises the
question that Nick said that lets you make a form control readonly
without saying the model is readonly, but Mark Birbeck showed there
seemed to be different views. It seems like you need a standalone
model and a model for the UI.
Mark Birbeck: I agree. It's the
logical level and the ability level to give someone a model. Maybe
we have a MIP in the backplane model to enforce model-level
readonly.
Nick van: If it's UI then it should
live in the UI. You could have readonly vs. read-write with
different controls.
Charlie Wiecha: You'd have to address
that in the split; events that came off setvalue, etc.
Mark Birbeck: We discussed this in the
transitional work, readonly attribute on input. Does it move to the
model or only affect that control? It sounds like we've got the
model MIP.
Steven Pemberton: The fact that they
are called MIPs makes me think it affects the model. A change like
this would take us back to last call.
Nick van: I think we need to wait for
John and Erik.
Steven Pemberton: OK.
Charlie Wiecha: I'm more on the side
of letting the actions change it because of the work to get there;
I agree with it philosophically, though.
Nick van: [reads]
Charlie Wiecha: I think that's in the
context of a control.
Steven Pemberton: That's in the model
section.
Mark Seaborne: All the implementations
I have tried don't allow setvalue.
Mark Birbeck: I would expect most
implementations would have done it along those lines, via the
accessor. Of course not on the DOM, you don't have that.
Steven Pemberton: OK.
Nick van: On the next, the repeat
object, what does "confined" mean with regard to capture and
bubble.
Steven Pemberton: One is not empowered
to prevent them from starting at the root.
Nick van: He creates a lot of small
DOMs for each repeated item, in a separate DOM. I don't like that.
Chiba has only one DOM.
Leigh Klotz: Chiba has two DOMs; many
implementations have that. Browser vendors have for a long time had
a "shadow" or presentation DOM.
Joern Turner: [IRC] yes
Nick van: Chiba unrolls the repeat in
both.
Leigh Klotz: Yes, but that's a choice;
it still has two DOMs. I don't know if we want to specify that
here, but it's not true that Chiba has one DOM.
Mark Birbeck: This extends that shadow
to repeat. It's supposing a certain style, an XBL style, which I
like, but it's supposing it.
Charlie Wiecha: ...
Nick van: ...
Steven Pemberton: I'm not sure I like
the wording.
Leigh Klotz: We've had a thorn in our
side about repeat, not mixing well with the schema of host
languages (tables, li, etc). It may be that when we decide to
specify this better, we should do it in a way (perhaps more
XSLT-like) that plays better with host languages. That would be
post 1.1.
Mark Birbeck: Many of the AJAX
frameworks have templating structures that work in a more
procedural way.
Leigh Klotz: When it's time to specify
repeat at this level, we might want to specify it in a way that
works better.
Steven Pemberton: Next.
Nick van: I don't think it's necessary
to have separate DOMs for repeat.
Nick van: Next, John changed core
form controls. Now he says in xforms-readonly and xforms-read-write
that group isn't a target. Is that correct?
Steven Pemberton: Do you know why he
makes that change?
Nick van: He made a distinction
between core form controls and form controls terminology. I always
though that the events went to group.
Joern Turner: I'm not sure that's the
case.
Charlie Wiecha: Is that only for
readonly?
Nick van: Yes, but I'm most concerned
about readonly.
Leigh Klotz: There are use cases for
xforms-enabled and xforms-disabled for group but as Joern pointed
out it wasn't clear.
Charlie Wiecha: We discussed those in
Raleigh and there's an erratum.
Steven Pemberton: Then this change is
wrong.
Nick van: This is for readonly
though.
Steven Pemberton: We think this text
needs to be changed. If we have use cases for these events, they
should go to the elements.
Joern Turner: I would also say we have
important use cases in more complex forms; you often need to use
relevance for groups. I'm not so sure about required. That feels to
me to be more useful for simple controls to have on each item one
by one; it might be a convenience for authors to say that the whole
group contains required controls; I'm undecided. Relevance is an
important use case.
Nick van: Relevance is corrected; it's
readonly and required. I think the readonly one is useful. Required
I'm not sure.
Steven Pemberton: Let's wait for John
to come back.
Steven Pemberton: We have three
members here, Nick, Mark and Sebastian.
Nick van: I haven't done anything yet;
I'm not sure if we're supposed to.
Mark Birbeck: I haven't heard anything
yet; I think they needed 3 names but I haven't heard back.
Steven Pemberton: It has been created
and it has an email list; the next step is to create a charter. I'd
understood that a draft charter had been sent. The members are not
aware of it.
Nick van: Do you know what's in the
charter?
Steven Pemberton: I thought it was the
HTML and Forms WG charters that refer to this. I'll look for Dan
Connolly's email.
Steven Pemberton: This was raised
for XHTML Basic 1.1. inputmode has modifier, such as digits. Does
the modifier need something to modify, or do we assume a default.
If I say inputmode=digits do I need to say
latin-digits or whatever? Does anybody implement
inputmode in this group? I take that to mean no. I'm hoping
everybody here is happy that we say that
inputmode=digits it means the default script for the
user agent. Does anybody object to that? I propose this as an
erratum for XForms 1.0 and following languages.
Resolution 2007-08-22.2: We issue an
erratum for XForms 1.0 and later editions that there is a default
script for inputmode and that modifiers such as digits
apply to the default.
Action 2007-08-22.1: Steven Pemberton to
propose text for an erratum for XForms 1.0 and text for XForms 1.1
that there is a default script for inputmode and that modifiers
such as digits apply to the default.
Steven Pemberton: My gut feeling is
that it should be the bind, and not the outer ref. I see the bind
as replacing the ref. The origin is talking about what the bind is
talking about and not what the ref is talking about. Does anybody
have an opinion on this. Both Orbeon and Sidewinder
say...Mark?
Mark Birbeck: I will check on my
implementation and find out why.
Steven Pemberton: And we should wait
for Erik as well. But what do you expect?
Mark Birbeck: What's the behavior if
ref is there?
Steven Pemberton: You can have a ref
on the insert. Surely it would work according to the ref.
Mark Birbeck: This makes my point that
it's too complicated.
Steven Pemberton: I don't hear any
discussion.
Action 2007-08-22.2: Mark Birbeck to report his position on http://lists.w3.org/Archives/Public/www-forms/2007Aug/0001.html