W3C Forms teleconference February 9, 2011

* Present

John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers [irc only]
Steven Pemberton, CWI/W3C (chair)
Kurt Cagle, Invited Expert
Erik Bruchez, Orbeon

* Agenda


* Previous Minutes

* W3C HTML/XML Task Force

http://lists.w3.org/Archives/Public/public-forms/2010Dec/0034.html Report from Kurt Cagle http://lists.w3.org/Archives/Public/public-forms/2011Feb/0009.html

Kurt Cagle: There was an announcement saying that the policy was no change to existing, which was no extensions or elements.
Steven Pemberton: But if it's in the DOM it's there but doesn't validate.
Kurt Cagle: Right
Steven Pemberton: OK, so it's in the DOM.
Kurt Cagle: As far as I could tell. The only question I could see is DOM interpretation. They will be picked up by CSS, bindings, etc. They're just not "legitimate" namespaces.
Nick van: There's one slight difference. They changed the parsing a bit and now it will be more difficult to get some constructs into the DOM. They are taking stuff out of more elements. If you have HTML.
Steven Pemberton: One of the really bad decisions of HTML5 is that it doesn't allow closing slash in elements. If an element is empty, it has to be hard-coded into the parser, which is as far as I'm concerned a real mistake, because it messes up forward-compatibility.
Steven Pemberton: If they actually remove elements or move them around, that's a problem.
Nick van: They do in some cases.
Steven Pemberton: For example?
Nick van: We discussed it a month ago; elements of the same name in the HTML namespace that are block-level elements in a non-block-level container will be moved out. There are other parsing rules.
Steven Pemberton: So if you depend on namespacing rules and change the default namespace.
Leigh Klotz: I think Norm Walsh's comments are worth reading: http://norman.walsh.name/2011/02/08/html-xml

John Boyer: One of the big headaches is that we can't put XForms markup in teh page and have a validating document. There are a lot of government agencies looking to W3C validation as a broad-sword effect on A11Y. That alone limits us in a lot of accounts.
Steven Pemberton: I'm not pessimistic. We can still specify that a valid document using XML rules. If you give it to the HTML5 document it will still be consumed and validates. I still think you can argue about validation and serving.
Kurt Cagle: It gives more push to saying that text/xhtml+xml is going to have to be the default for validation for XForms, but with IE9 now supporting that MIME type, it makes it a bigger case to say we can support it, which wasn't true.
Steven Pemberton: So use the XML mediatype and you're good to go.
Kurt Cagle: Yes. The interpretation of XHTML5 isn't affected by this, as far as I understand, but it comes down to the degree that implementors work with it.
John Boyer: There's a huge shift to mobile devices, so IE9-only isn't good.
Steven Pemberton: Mobile devices are XML friendly, including using an XML MIME type.
John Boyer: The second comment is ok that IE9 now does it but that's not the majority.
Kurt Cagle: The one advantage of HTML5 effort is that it will produce significant market push to upgrade browsers to a certain level of contemporary standards. Government organizations will look seriously at current deployment.
Erik Bruchez: Can someone summarize?
John Boyer: So is there a way to inject XML?
Erik Bruchez: Is it limited to the mechanism of embedding in XML?
Kurt Cagle: There are two big problems: embedding, and the bigger one, PIs and XML Stylesheets. I'm not sure where that stands right now. Is it there? Can we count on it? Or is it being pushed away because it doesn't fit in someone's ideas of use case?
Erik Bruchez: Does it work today?
Kurt Cagle: More to the point, does it work tomorrow/
Erik Bruchez: I thought the task force was supposed to ask that.
Kurt Cagle: It's one of the use cases that's being looked at and I don't think there's been any major resolution.
Erik Bruchez: What about past approaches we looked at? We've seen two approaches: the Ubiquity approach (no XSLT) and the XSLT approach. If the XSLT approach turns out not to work in ten years, is the other approach satisfying? Are there specific problems there?
Kurt Cagle: Ubiquity sits on top of the Yahoo UI JavaScript classes, so I don't think there's an issue there.
John Boyer: The problem is that it does pattern-matching with CSS-like patterns, looking for XForms-based markup and attaches behavioral components. So the point is that we deliver to the desktop a document that contains XForms markup and those documents will never validate in HTML5.
Erik Bruchez: That's fine if it doesn't validate.
John Boyer: No, there are places where validation is required for A11Y.
Steven Pemberton: The browser doesn't validate. So you'd never notice. All we need is an XForms validator that says it's correct.
John Boyer: (A) we have to create such a validator and (B) we have to get people to allow XHTML+XForms document validation. A validator from W3C makes it at least feasible.
Erik Bruchez: I thought we were talking about HTML, not XHTML.
John Boyer: We can't be guaranteed an XHTML parse in an HTML5 document. Even if we could the document doesn't validate.
Erik Bruchez: It's not going to validate. How long until all the browsers support the HTML5 rules? 5-10 years? IE6 is still around. It's our experience too. Inevitably people will have to migrate. But it may be in a long time. Whatever HTML5 does, you still have IE6, IE7, IE8. The deployed browsers won't support officially any type of valid HTML+XForms combination.
Steven Pemberton: John, I think you're being too pessimistic. You can deliver HTML+XForms as HTML and as long as it's well-formed it will come out in the parse and the JavaScript or whatever does its work. So we just describe the validation rules. The HTML5 people don't really believe in validation.
John Boyer: If the W3C came out with a validation profile that says how to use HTML+XForms that's ok.
Leigh Klotz: We're chartered to do that.
Erik Bruchez: Nobody else would do it, just us. I have no expectation that non-SVG,HTML,MathML would be looked at by the HTML5 WG.
John Boyer: It would be better if they had a decision for an extension mechanism.
Erik Bruchez: There's exciting stuff that's going to happen. There's genuine interest in the successor of XBL2, and that's an extension mechanism. You can say I want an xforms:foobar control, but I can't call it xforms:foobar, and I can implement something that looks like a native control. And that's separate from the markup sent to the browser. There are people who believe a component model for the web is necessary. That kind of activity is going to help whoever wants to implement custom controls and extensions in the browser. It might not help the specific task of embedding an XML island into HTML but it is going to help. But again, maybe in five years. If we can rely on it as a WG, it will be maybe ten years.
Kurt Cagle: I'm not sure. There is an XBL2 out now. It's JavaScript based, but there is one working. There's Mozilla XBL1-esque. But those pieces are out there. The real question I see is where the TAG was looking for XBL, and where it's going. Is Ian going to change the rules?
Steven Pemberton: This is a good segue.

* XBL2

http://lists.w3.org/Archives/Public/public-forms/2011Jan/0030.html http://lists.w3.org/Archives/Public/public-forms/2011Jan/0031.html

Steven Pemberton: I haven't confirmed yet, but I believe this Friday's HCG call will be on XBL.
Leigh Klotz: I believe that we can use XBL as Erik says to define XForms macros that expand into three inputs and a setvalue, and also as Erik says in the browser (as in Mozilla) to define components that implement XForms controls. The form author can use namespaced bindings, and the XForms implementors can use the in-browser implementation (which is namespace blind). They can have namespaces as an optional feature in XBL and the XForms implementors can deal with the namespaces implement the namespace part at their layer.
Erik Bruchez: We do need to decide if that's important; how can they remove namespaces? Perhaps they can't remove namespaces?
Steven Pemberton: I think you should read Ian's document and see what his proposal is.
Erik Bruchez: I don't know the original Firefox XBL. It was an attempt to clean that up. It is supposed to clean that up. The recent Google guy publication seemed to be the usual use cases: custom controls, etc. As far as I know that's what Chrome does. Complex behavior, but looks like an element with attributes. Events, CSS, JavaScript. It seems to be straightforward. Specifically with XForms, it's because we have things you don't have in HTML, namely an XPath context (current evaluation context): so how does that work crossing the component boundary? With JavaScript? We just implemented an ad hoc solution for that problem. It seems that the basic ideas, components with private shadow DOM, seems to be quite sound.
Steven Pemberton: We're trying to chivvy them on to do that. At one point we offered to take it on. So Kurt?
Kurt Cagle: I have been working with XBL for a long time now. It was one of the issues with SVG I worked with DOM featuers. One of the biggest is the selection mechanism in XBL. Hixie had pushed it to be only CSS. I pushed, succesfully, to get that changed to the selector model be either CSS or XPath. At that point Hixie quit the SVG working group.
Erik Bruchez: I agree about the selection, at least partly. It's clear that using CSS to create a destination tree is weaker than XPath. One reasons it that the level of CSS supported (assume CSS3+). The main problem is that you don't have a way to select attributes, such as @ref. There's no way to copy the ref inside the result tree with CSS.
Kurt Cagle: That was one of my big objections on the SVG side.
Erik Bruchez: So for template, they chose CSS selectors and a couple of CSS and link/copy operations. A more powerful transformation language, such as the XSLT extension we support, is better. I see no way in browsers that they would accept XPath 2.0 or XSLT. I'm pessimistic. The set of technologies for those new features isn't going to be XPath/XSLT. If that happens it will be done in libraries.
Steven Pemberton: To follow up on one of the problems using CSS (and I was part of the group that designed CSS selectors), CSS selectors are designed for streaming. One reason they're bad for DOM is that you can only select left-to-right, or following siblings but not preceeding-siblings. It's ill-suited for the task. I think it's a mistake of CSS in the first place that they made their decision. It should have been people's choice to use that optimization or not, but then to carry that mistake through to future technologies. Either CSS selectors need to be fixed, or they should not be used.
Kurt Cagle: Can we write those comments into the record?
Steven Pemberton: Yes, I've long had in my head a paper that CSS has reached its sell-by date. A lot of XForms decisions are driven by CSS problems. We should be designing for the future.

Erik Bruchez: It won't help to say it's no good.
Steven Pemberton: Right, I mean what the future should hold for it.

ACTION-1777 Steven Pemberton to write paper on CSS futures.

Erik Bruchez: If XPath can be used for free, maybe, but as you can see it's not really "trendy" right now to push XML in the browser. We have to pick battles. If some people in the WG have the bandwidth to work on XBL, there are clear points: the transformation languge needs to be fixed, and here are examples. That might help. But just asking to use XPath 2.0 isn't going to fly.

Kurt Cagle: There's a case to look at XBL beyond browser implementations. Look at Open Office, Libre Office. There's a core specification and we need a framework that says how you define it, integrate it with XML, mechanisms for HTML integration. So we have a formal XBL2 (or XBL3!) mechanism, not necessarily in the browser, but with library support. We have to prove use cases in the browser to get it in the browser, but we have use cases outside the browser and we have to show that those use cases are important.
Erik Bruchez: It's all about spending a lot of time and energy implementing and pushing stuff. Let's say WebBL is done by Google and Mozilla with a few dedicated engineers agreeing among themselves in some kind of forum. If anybody else comes with a hypothetical use case, it's not going to make anything change. It has to be pushed by someone implementing the use cases. The point of view from Norm Walsh that it has to be fixed is unrealistic. It doesn't work to say it has to be fixed because it should be fixed. Clearly there are XBL use cases outside the browser, but if there are no use case implementations it won't happen.

Steven Pemberton: We need to wrap. Kurt and Leigh, I'll invite you if it's on this topic.
Leigh Klotz: And it's an hour earlier than this meeting on Friday?
Steven Pemberton: Yes.

Steven Pemberton: Do we need to write something for HCG?
Leigh Klotz: I'd like to nominate Kurt.
Kurt Cagle: Do we feel comfortable as a WG taking on XBL?
Steven Pemberton: Not chartered, but we could offer people to coordinate with the chartered group, I believe WebApps, but I'm not sure now.
Leigh Klotz: I think there's two levels: lower-level in browser non namespace aware, used for implementing XForms. Upper-level in JavaScript libraries or server-side, that macroexpands XForms namespace or other namespace items into the lower-level markup.
Erik Bruchez: Unless we get fresh faces in the group, it's OK to participate but we can't take it on.

* XForms 1.1 load erratum

* XForms 1.1 typo Awaiting move to XForms 1.1 wikispec erratum

http://lists.w3.org/Archives/Public/www-forms-editor/2010Nov/0001.html http://lists.w3.org/Archives/Public/www-forms-editor/2010Nov/0000.html

John Boyer: As we discussed two weeks ago, these are done.

* IRC Minutes


* Meeting Ends