Visual part of XForms controls are implemented by using XBL. The more I look on implementation then more I doubt XBL is aimed to creating custom controls. For sure, we have xf:output, xf:label, xf:input and e.t.c. and they are works fine. But at the same time we have controls like xf:select, xf:select1, xf:input[type="xsd:date"] that have problems. And I can't see any way to fix them by using XBL only. I guess visual part of thouse controls should be implemented as bundle of c++ and XBL. But here we get questions I can't see how they can be settled right now. Some xforms controls can be implemented by using Web Forms (xhtml context, Alex Vincent begun the work and I belive WF2 will be usefull for XForms thing in future) and by XUL improving (xul context). But I can't see what we can do with the rest of controls especially xf:select and xf:select1. The list covered problems below. xf:select/xf:select1 have top binding that contain underlying control (some widget from hosted document's namespace) in anonymous content. We just copy nodes into underlying widgets. The related bugs are bug 332081, bug 332932, bug 336725, bug 343443. The problems related with that hosted document hasn't properly widgets needed by XForms are bug 332928, bug 332930, bug 333529, bug 303351. The bugs I can't see right way for they fix from XBL: bug 332217.

That's a question. Can we create layouts for xforms controls in c++? Note, xforms controls should be depended on host document.

(In reply to comment #1) > That's a question. Can we create layouts for xforms controls in c++? Note, > xforms controls should be depended on host document. > we had ALL kinds of problems using XTF for our c++ layout

Since layout and content are different objects then we can move focus on layout objects only. Here we don't need in xtf or xbl. If I get right then layout object is created by using tagname (we cannot use them while we depend on host document) and by using css styles. Probably it is what we should use.

RIP xforms