Kenneth Sklander, PicoForms
Steven Pemberton, CWI/W3C
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Uli Lissé (DreamLabs)
Nick van den Bleeken, Inventive Designers
Charlie Wiecha, IBM [joined late]
http://lists.w3.org/Archives/Public/public-forms/2009Sep/0020.html
Steven Pemberton: PicoForms
implemented InputMode.
Nick van den Bleeken: [irc] and about JSON
submission.
Steven Pemberton: The new widget
screenshots.
Kenneth Sklander: http://picoforms.com/picowidgetsolution/screenshots
John Boyer: Are you using
inputMode?
Kenneth Sklander: We had it but
changed to match the XHTML spec
Steven Pemberton: [irc] XHTML Basic
1.1
John Boyer: We have no conformance
tests defined. If we had some tests we could make this an optional
feature.
Kenneth Sklander: OK
Action 2009-09-23.1: Kenneth Sklander to send to list suggestions for inputMode tests.
Steven Pemberton: We'd like to use
your experience, Kenneth.
Kenneth Sklander: When we receive JSON
data we transform it to JSON. It is transformed back to submit.
There are some issues in the mapping (arrays, etc.).
John Boyer: Are there issues from XML
to JSON?
Kenneth Sklander: Most JSON to XML
converters are object/name/value. The XML data is then
inconvenient. We map to a tree structure, but 90%. The
fully-addressable version isn't very convenient or useful because
the XPath is awkward: object[1]/object[name="test"][1] but the
convenient method is test[1]
Leigh Klotz: It sounds like it's like
using a DOM API and losing the power of XPath.
John Boyer: Do you have a document
about the translation?
Kenneth Sklander: Yes. You get the
same data but not the same representation.
John Boyer: Do you have
documentation?
Kenneth Sklander: Yes.
John Boyer: Charlie is going to write
something up. Can you provide some information?
Kenneth Sklander: Yes, I can paste it
in from our internal site.
Action 2009-09-23.2: Kenneth Sklander to send to list information about lossy-but-convenient JSON-to-XML transformation.
Steven Pemberton: We have to say
what we're doing by the next AC meeting. The required points that
published a new recommendation and are rechartering.
John Boyer: Here's the statement for
the last one: http://www.w3.org/2002/Forms/Activity.html
Steven Pemberton: And we should say
that we are making XForms 1.1 Basic a profile of XForms 1.1.
Leigh Klotz: Do we need to issue
XForms 1.0 Basic as a Note before the AC meeting?
Steven Pemberton: No.
John Boyer: And FPWD of XForms for
HTML.
Steven Pemberton: Is that 1.2?
John Boyer: It's half of 1.2. We are
continuing on the other half.
Charlie Wiecha: [joins]
John Boyer: And FPWD of XForms
1.2.
Steven Pemberton: We missed a
message from Doug Scheppers, about deprecating some of the events
we use in XForms. Mark Birbeck replied saying it was a bad
idea.
Charlie Wiecha: I thought we discussed
this.
Steven Pemberton: Namespaces last
week, but not the deprecation.
Nick van den Bleeken: We discussed it in July but
I can't see who got the action item to reply. It's not in the
list.
Nick van den Bleeken:
http://lists.w3.org/Archives/Public/public-forms/2009Jul/att-0045/2009-07-29.html#topic5
John Boyer: So we may have to
fabricate these events, as we do now.
Nick van den Bleeken: That's a performance
issue.
John Boyer: What's the
question?
Steven Pemberton: As I understand it,
they're deprecating these because the mainline browsers don't
implement them.
John Boyer: Is the deprecation because
HTML5 has new events?
Steven Pemberton: Doug Scheppers said
they wanted a documented that listed only what all five big web
browsers use.
Charlie Wiecha: The DOM is also used
server side. XML Pipeline may want focus, but not click.
Steven Pemberton: It's mostly focus in
and focus out, not activate.
Charlie Wiecha: Aren't there
differences in timing and bubble behaviors?
Nick van den Bleeken: They aren't the same. Some
don't implement bubble.
Steven Pemberton: Anne von Kesteren
said that all events should be application-specific. That then
gives you three different submit events, which is a problem in a
mixed-namespace document.
Nick van den Bleeken: I responded in July to
this email.
John Boyer: What's the next step? I
hear the issue is a duplication.
Steven Pemberton: focus, blur; they
have a different order.
Nick van den Bleeken: focusin doesn't bubble.
DOMFocusIn bubbles.
John Boyer: full capture/bubble?
Nick van den Bleeken: Yes.
Leigh Klotz: It looks like
DOMFocusIn applies to any target but focus applies only to HTML
forms elements: http://en.wikipedia.org/wiki/DOM_Events#Common.2FW3C_events
and http://en.wikipedia.org/wiki/DOM_Events#Common.2FW3C_events
Kenneth Sklander: That is
correct.
Steven Pemberton: So they might ask us
to to add the event to our spec.
Charlie Wiecha: But DOM is a core
technology, server-side as well.
Steven Pemberton: Good point.
John Boyer: So we care about the
general applicability of the event.
Nick van den Bleeken: But focus can be sent to all
elements, if I read the spec. All UI elements. There is text in
DOMFocusIn saying the event is deprecated, and changes between
DOMLevel2 and DOMLevel3 say focus and blur are now added to the UI
module. So it's not just the form elements.
John Boyer: So if we base a new XML
Events on a new DOM Level 3 events, that would be a new version of
XForms. So some translation may be necessary. Is that a problem for
other than just the name change?
Steven Pemberton: There's backward
compatibility. The backplane approach would provide common events.
The "wheel" and "click" events are hardware-specific; it binds you
to a specific hardware. So DOM 3 Events would make the DI problem
worse.
Steven Pemberton: So should these be
centralized or done by each application? We'd prefer to see
centralized so that things can be combined, but HTML5 is a
monolith.
Nick van den Bleeken: [irc] I personally think the
UI events should be defined in a separate UI spec, because the UI
events won't occur on my data DOM, but they shouldn't be defined in
HTML5, then I prefer DOM Level 3 events
Charlie Wiecha: That's the point about
DOM being more generic, as there is server-side technology.
Leigh Klotz: So we should follow Anne
von Kesteren's suggestion and ask that all UI events be removed
from DOM Level 3 and they publish a separate HTML5 events?
Nick van den Bleeken: Except for mutation
events.
John Boyer: How about DOMFocusIn and
DOMFocusIn then?
Charlie Wiecha: It could be a cursor
processing with no UI. There could be listeners processing it, in a
server-side data-oriented event as you process each pipeline stage.
The listeners make a view.
Leigh Klotz: Why would you use
DOMFocusIn instead of DOMActivate?
Charlie Wiecha: For a different stage
in the processing; it's attention rather than operation. I can see
the need for both events.
Leigh Klotz: So we can agree with Anne
von Kesteren's point that suggest that only events independent of
application (mutation events, DOMActivate, DOMFocusIn/DomFocusOut)
be removed from DOM Level 3 and put into an HTML5 spec.
Charlie Wiecha: Alternatively, can
we live with the name change or is it a semantic change?
John Boyer: There's a time when
there's no focus.
Charlie Wiecha: We should respond
with both points, suggesting that it be rational to refactor the
spec, but respond with the first point because we need to respond.
But I'm not sure if we have decided whether when can live with the
focus events.
Nick van den Bleeken: [irc] focusin vs DOMFocusIn
e-mail we also discussed in July:
http://lists.w3.org/Archives/Public/public-forms/2009Jul/0017.html
Charlie Wiecha: Focus still doesn't
bubble, even in DOM Level 3.
Nick van den Bleeken: It's the timing.
John Boyer: focus gives you event
before the focus; DOMFocusIn gives it to you after the focus. The
same for focusOut.
Charlie Wiecha: So the IE events are
now in DOM Level 3?
John Boyer: What does not cancellable
mean? One use case is to catch the event, run a test, and cancel
the event if the test fails, thus preventing focus change. Can you
do this?
Charlie Wiecha: We use activate more
than the focus events.
John Boyer: I've seen focusin used:
when you arrive at the control, the user has already filled out
other information, so you can retrieve and fill out info.
Leigh Klotz: And would that still be
possible?
John Boyer: Either way. And the web
service retrieval would be asynchronous anyway.
John Boyer: Whereas, with focusout,
the use case is on testing and validation and the app author wants
the focus to go back. What is the state of the focus if you change
focus back in the event handler? With focusout it happens before it
loses focus, so it's not possible.
Kenneth Sklander: The focus is taken
from the element before the dispatch of this event type. From the
lvl 3 spec.
Steven Pemberton:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
John Boyer: As of yesterday, on
focusout is says "about to lose focus" and "before".
Nick van den Bleeken:
http://www.w3.org/TR/2009/WD-DOM-Level-3-Events-20090908/Overview.html
Kenneth Sklander: I'm reading
DOMFocusOut.
John Boyer: Yes, they're asking to
remove DOMFocusOut.
Kenneth Sklander: In XForms only
DOMFocusOut can be used to check the data.
John Boyer: Yes, in the focsuout case,
there is a difference. And blur?
Kenneth Sklander: blur happens after
focus.
John Boyer: Except it doesn't
bubble.
Kenneth Sklander: blur doesn't
bubble.
Steven Pemberton:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-uievent-event-order
John Boyer: focus or DOMFocusIn is
OK. And blur can be used for the exit test. Does the absence of
bubble on blur cause problems?
Kenneth Sklander: Yes, if you use it
on a group.
John Boyer: focusin bubbles.
Kenneth Sklander: If you have setvalue
on a group.
John Boyer: You'll get a focusin and
that will bubble and you can run pre-processing for the
group.
John Boyer: focus doesn't
bubble.
Charlie Wiecha: What's the
rationale?
Nick van den Bleeken: IE
John Boyer: So the feedback could be
to make them bubble.
Nick van den Bleeken: So keep focusin and
focusout, remove focus, blur, and DOMFocusIn and DOMFocusOut?
Steven Pemberton: Why don't we ask
Doug Scheppers to join our call next week? We've got an uneasy
feeling but no resolution. So he can talk to us about it.
Charlie Wiecha: We could live wit it
if focus bubbled.
Steven Pemberton: But it won't.
Nick van den Bleeken: They added it because IE has
it. They won't change it.
John Boyer: DOMFocusIn and DOMFocusOut
are added.
Steven Pemberton: I'm sure there are
A11Y issues.
John Boyer: We've identified the use cases and there seem to be problems with the elimination fo the events. I'll invite Doug Scheppers next week. s/
John Boyer: Voting closed
yesterday.
Steven Pemberton: There are some
comments from Mohamed Zergaoui.
John Boyer: It looks like some updates
to references. He also says we should clarify the relationship to
XPath 2.0 Functions and Operators.
Leigh Klotz: It's based on XPath
1.0.
Nick van den Bleeken: So can we say XPath 2.0 is
for XForms 1.2?
Steven Pemberton: A future
version.
John Boyer: Where do we contact him
back and see if we satisfy him for these member-only
comments?
Steven Pemberton: w3c-archive
John Boyer: Then what do we have to
say? We have an XPath 2.0 implementor.
Nick van den Bleeken: Chiba also uses XPath
2.0.
John Boyer: We deprecated the if()
function for anticipated future implementations, but we didn't
explain the full relationship.
John Boyer: Why was if deprecated if
it's in the xforms namespace?
Nick van den Bleeken: The XPath 2.0 parser fails
even if prefixed. You can use uppercase.
John Boyer: Really?
Nick van den Bleeken: I'm quit sure but I can look
it up.
John Boyer: Maybe because it might be
the default namespace.
John Boyer: Where do we put the
note?
Leigh Klotz: Maybe where we deprecated
if().
John Boyer: Or more globally, in the
introduction to XPath expressions: "future versions may incorporate
XPath 2.0."
Steven Pemberton: And certain aspects
for XForms 1.1 may be seen as preparation for that change. But run
it by Mohamed.
Leigh Klotz: John, is the Schema in
place for XForms 1.1?
John Boyer: Yes, it's in TR space but
the link is not yet in the document.
Leigh Klotz: I've been asked to
provide review copies. Can you paste in the link?
John Boyer: Kenneth, if you happen to want to produce a testimonial supporting XForms 1.1 that would be nice. See the XForms 1.0 ones for reference.
John Boyer: The votes are in and I
think we will be closing in the next few weeks. Charlie; What about
inputMode?
John Boyer: The latest email said it
would have been preferreable if we were to list the attribute names
but say you could be conformant without using them, but that's not
the W3C process for conformance. We can say that the commenter
would prefer a normative-but-optional feature but we don't have
test suite entries or conforming implementations, on entry to CR,
so it's not an appropriate PR process.
Charlie Wiecha: OK.