W3C Forms teleconference February 3, 2010

* Present

Steven Pemberton, CWI/W3C (chair)
Uli Lissé, Dreamlabs
Nick van den Bleeken, Inventive Designers
Leigh Klotz, Xerox (minutes)
John Boyer, IBM
Erik Bruchez, Orbeon

* Agenda

http://lists.w3.org/Archives/Public/public-forms/2010Feb/0004.html

* Previous Minutes

* Rechartering

Steven Pemberton: I haven't heard any news. They are meeting now.

* The Forms Newsletter/News items

http://lists.w3.org/Archives/Public/www-forms/2010Jan/0006.html http://lists.w3.org/Archives/Public/www-forms/2010Feb/0000.html

Leigh Klotz: Should we just put them on the news page at the same time as posting them on the list?

Action 2010-02-3.1: Steven Pemberton to publish news items such as new implementations or users of XForms both as mailing list notes and home-page "news" entries on an ongoing basis.

* XForms and Deprecating DOM* Events in DOM3 Events

http://lists.w3.org/Archives/Public/public-forms/2010Feb/0000.html http://lists.w3.org/Archives/Public/www-dom/2010JanMar/0017.html

Steven Pemberton: This got discussed at the most recent HCG. The discussion would have gone on longer, but we ran out of time. There were no conclusions, and that's why we have this message minuting some of the dicsussion. The next HCG meeting is on a special topic, so I hope it will be raised at the next after that.

Erik Bruchez: I'm not sure I understand; the email says that it's been deprecated in the current draft, but you're saying that's not final?
Steven Pemberton: Yes, it's not even last call yet; this is a heads-up. It's WebApps. Before DOM, "click" was the event used for activation, but the name was misleading and browsers implemented it non-interoperably, so you couldn't distinguish between "enter in input." So now they claim that "click" is interoperable and is as if it were DOMActivate, so return gives you a click.
Erik Bruchez: They say they're not equivalent.

"While DOMActivate and click are not completely equivalent, implemented behavior for the clickevent type has developed to encompass the most critical accessibility aspects for which the DOMActivateevent type was designed, and is more widely implemented. Authors are encouraged to use the clickevent type rather than the related mousedown or mouseupevent type to ensure maximum accessibility."

Steven Pemberton: The irony is that XForms adopted DOMActivate because DOM said to use click instead, and now we have content, and the DOM people are saying they want to standardize on click.
John Boyer: Didn't they say we could implement our own DOMActivate now?
Steven Pemberton: But we're not a monolithic host language; we're not necessarily producign the events. It's a lot of extra work that in some implementations we need to look for clicks.
Erik Bruchez: Isn't that what they have to do already in JavaScript? I would imagine that not all the browsers implement DOMActivate, but maybe I'm wrong. In our case, we implement the whole stack on the server. We generate the events ourselves and control the whole DOM event implementation.
Steven Pemberton: John or Uli?
Leigh Klotz: I just looked in XSLTForms and saw that it catches click and dispatches DOMActivate, but it's not clear that it gets the capture/bubble semantics right.
Uli Lissé: I think it's a host-language integration. If the host language is HTML or XHTML then you map click to DOMActivate. But I don't know if VoiceXML defines its own special events.
John Boyer: Ubiquity Backplane issues its own DOMActivate, and will ignore Webkit's DOMActivate. So we have taken over DOMActivate.
Nick van: I think it's not a big problem for the implementor to hack in the transformation, but as for a standard, it's a bit awkward that we're going to map click to DOMActivate in HTML, which is the primary host language for the W3C.
John Boyer: The new behavior is being defined for DOM3. We don't use DOM3. We'll rev our own language and in the next rev if we adopt DOM3 we'll be responsive, assuming it's farther along the rec track than we are.
Leigh Klotz: I'd expect browser implementors to react faster since they seem to be doing features piecemeal now.
Erik Bruchez: It's deprecated, not removed. Only WebKit will have it. So do we tell people not to use it and use click, and switch to click (whatever that means) or do we translate it?
Steven Pemberton: It would make our existing content not work.
Nick van: A deprecation doesn't make it not work.
Steven Pemberton: Deprecation as I understand it is the first stage toward removal.
Nick van: If we keep our own DOMActivate forever, then there is a spec disconnect; one spec says use click and the other says DOMActivate.
John Boyer: I think we need to adapt to the changing landscape; our content will continue to work, but when we rev the language for DOM Level 3, new content should migrate to the new name.
Steven Pemberton: The old name. It was click, then DOMActivate, and now click again.
Erik Bruchez: It sounds like there was an attempt at standardizing something better than click and they gave up and now click is back in fashion. For a form author, click is more intuitive in HTML.
John Boyer: It's called DOMActivate because if you hit enter...
Erik Bruchez: ...
Steven Pemberton: People thought click was a mouse click; mouseup and mousedown are events for mouse operations. Click isn't just about click. It's two or three other events, for instance space bar on a button.
John Boyer: For almost every other event, we have xforms-*. We could have xforms-activate. The host language integration document for HTML should say to map "click" to xforms-activate.
Erik Bruchez: There's something to be said against long names like xforms-model-construct-done. I think it would be better to use click. I guess xforms-activate would be OK.
Nick van: Is click sent in a text field with enter?
Steven Pemberton: It is. But the original argument was that they wanted something more generic than being called click.
Nick van: I don't want to use our own xforms-activate or our own DOMActivate. Maybe we should respond back.
John Boyer: We have longer event names than xforms-activate.
Erik Bruchez: DOMActivate is used all the time; click would be used all the time.
John Boyer: We have three events DOMActivate, DOMFocusIn, and DOMFocusOut. Why do we inherit these events from DOM? In HTML we get them from DOM. In ODF they might not.
Steven Pemberton: So we should be mapping to our own anyway?
Uli Lissé: DOM is just an object model for XML. There are others.
Erik Bruchez: I don't think there would be anything wrong with XForms to embrace click, focusin, focusout, blur. When you move from HTML to XForms there is value to keep those events. You can activate a button with the space bar and the browser dispatches a click event.
Leigh Klotz: Why not put those events into the XHTML+XForms recommendation? They ODF and XFDL don't need to implement them.
Erik Bruchez: From a perspective of re-use it would make sense to point to those definitions.
Nick van: If you use XML Events 2, that adds a script element. My custom components use HTML and JavaScript for XForms. So I can re-use JavaScript implementations from others that use "click."
John Boyer: I hope they don't change it again on us.
Leigh Klotz: I think we're seeing the events are not preserved across host languages.
Erik Bruchez: No, they're in DOM Level 3.
John Boyer: If we change DOM Level 4 again what do we do?
Nick van: If there is a standard event name for XML (not DOM) then we should re-use the names if possible, and not invent our own different names.
Erik Bruchez: I agree. I also wonder what luck we would have changing the decision. Presumably they see no future in events.
John Boyer: There is a larger content base for the existing events and they don't want to double them.
Erik Bruchez: So the same for us. We should embrace the decision. In XForms 1.1 we clarified text field and enter and DOMActivate. The other uses are mostly uses that match the click event.
Nick van: That also matches the click event.
Steven Pemberton: As I understand it that is claimed to generate click.
Nick van: I think the click event is what DOMActivate is; the name DOMActivate is better, but if everyone uses it, it is better.
Steven Pemberton: I wonder what the option is of giving the event two names?
Erik Bruchez: [leaves]
Nick van: That implies sending two events.
Steven Pemberton: Could it be the same event with two names.
Uli Lissé: In voice browser there would be no click.
Nick van: They said click is like activate.
Uli Lissé: I don't like the name.
Steven Pemberton: I know the WAI groups are upset.

Steven Pemberton: A good discussion. From what I understand, I think we don't object to this change, even if we don't like it.
John Boyer: Sounds good.

* Teleconference Calls

John Boyer: Lately we have been ending at the top of the our. Should we do that?
Steven Pemberton: Yes. It's hard for me anyway.
John Boyer: That's an agenda change.

Resolution 2010-02-3.1: We change our call ending time to 1700z.

Leigh Klotz: By the way, I won't be here next week.

* XBL2 implementation reports sought

http://lists.w3.org/Archives/Public/public-forms/2010Feb/0001.html

Steven Pemberton: Erik has stepped out. John, is there a partial XBL2 implementation in Ubiquity?
John Boyer: It may be in the WebKit implementation, but I don't know for sure.
Steven Pemberton: We should ask Mark Birbeck.
Leigh Klotz: http://xtech06.usefulinc.com/schedule/paper/137 is Mark's XTech paper on using XForms, SVG and XBL2.
Leigh Klotz: http://code.google.com/p/xbl/ is a JavaScript implementation of XBL2.
Nick van: The Mozilla note said it was slow.
Erik Bruchez: [returns]
Leigh Klotz: Erik, are you using XBL2 with XForms now?
Erik Bruchez: As far as spec compliance, it's another question. We try to implement whatever we find useful for our purpose. It's too early to call it an XBL2 implementation. We might be able to say we implement a subset.
Leigh Klotz: I think we need to move something forward.
Erik Bruchez: It might not be perfect, but it has even more value if implemented in browsers. If nobody is implementing XBL2 for the purpose of components in XForms, then it means we have an opportunity to do something better and steer it better in a direction.
Leigh Klotz: For XForms components would you start with XBL2 as a base or start with a blank document?
Erik Bruchez: Good question. I think resource binding to elements, resources, registering handlers, etc. is all good. While implementing our components, we found this was all on the right track in XBL2. That's a large part of XBL2. The templating part as well; it's a mini-XSLT underneath, though I don't know how I feel about the pseudo/limited aspect. I think the idea is a good one. I think some thinking is needed on our side, having implemented components, on XPath-specific features. For example single-node binding controls and XPath context, itemset, etc. XBL2 doesn't help with that. So one question is whether we would need modify XBL2 to have hooks, or can it be in XForms. Something has to address it.
Leigh Klotz: Should we attempt to move it on to the next stage?
Erik Bruchez: Of course, we'd need an editor. But then do we want to base things on XBL2?
Leigh Klotz: It would be good to be thinking about it now.
John Boyer: Why do we need it?
Leigh Klotz: We need to decide for XForms 2.0 whether to use XBL2 or not. If we use XBL2 then we need to get it to move forward; if not, we need to start afresh.
Erik Bruchez: http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components-guide#TOC-Level-of-support
Erik Bruchez: It might be too early to say we don't want it. We maybe can't focus on it now with limited resources. It's a lot of work though. It would require F2F, several interested people, etc. We can provide some input to a discussion.
Leigh Klotz: Do you think you could identify other communities or WGs that use XBL and might be interested in moving forward?
Erik Bruchez: XBL is very XML oriented. It has an XML transformation language, etc. I would imagine it would appeal to XML technology rather than HTML5 people. I don't think it solves any problem for the Transformations group.
Steven Pemberton: In your XBL, are the selectors XPath or CSS?
Erik Bruchez: We implement a subset of CSS, but underlying that is an XPath expression and you can put in an XPath expression; we do translate simple CSS expressions. XPath does more than CSS. Whichever way you go, you can achieve your goal of identifying elements to which bindings apply. The template language is weak; they use CSS to determine elements to copy from source to shadow; but it's a limited language because they use CSS. CSS doesn't allow you to select attributes; they invented a syntax for accessing attributes of bound nodes. We had to work around that and provide extensions. The use cases were not sufficient.

Steven Pemberton: Here is another Javascript XBL2: http://www.amplesdk.com/about/technologies/

Steven Pemberton: For technical talk, I have some opinions. I was one of the co-designers for CSS1 and it was a different set of requirements that XBL. I think, for that reason, you are bound to come across such problems. The CSS selectors just don't do the job.
Erik Bruchez: As far as XBL2 is concerned, it similar to mapping bindings to node. If you give that CSS is OK for identifying elements for styling, it's OK for binding XBL. But where it doesn't work well is in the template language; it's a stretch there. That's a weakness of the design; it works in a number of use cases, but you quickly reach limits. So you would have CSS for binding and XPath for transformation.
Steven Pemberton: CSS was designed left-to-right; you can't select a preceding element.
Erik Bruchez: If you are a browser vendor you are going to use CSS as it's already there. For a server-side implementation that you control entirely, you can use XPath.
Steven Pemberton: We've reached the top of the hour. So let's wrap this up. I thin Leigh is saying that we should keep ourselves open on this because it's a co-technology to XForms; we've used it quite a lot and it would be useful to have as a standard, but Erik is saying we don't have the cycles. Is that a good summary?
Erik Bruchez: With my record for action items, it's hard to say I can spend a lot of time on it. As for implementation, we have tremendous interest, but it's another question to say we are going to take over XBL2 and coordinate with third parties. But clearly if the group is going to be serious about components, we need to look at it and think about our components. The question is can we do it now?
Leigh Klotz: I can see a future in which everything that Erik says about XBL2 and XForms gets fixed, a spec magically gets published, and others use it. I can also see a future in which nothing gets done, and nobody uses XBL. So I think we should continue to discuss.
Steven Pemberton: So resolved.

Resolution 2010-02-3.2: We continue to discuss XBL2 and XForms.

* Next Week

Steven Pemberton: We will ask Charlie Wiecha to take minutes next week, in Leigh's absence.

* IRC Minutes

http://www.w3.org/2010/02/03-forms-minutes.html

* Meeting Ends