I've implemented OXF's XHTML serializer successfully. However, the HTML that the XForms processor produces is not valid XHTML (version 1.1, in my case, but it also fails version 1.0). The two problems I have found are:
(1) The children of XHTML <form> elements must be block-level. By default, the XForms output processor generates something like: <form name="xforms"> <input type="hidden" name="submitted" value="true" /> <!-- etc. --> </form> Even though it's of type hidden, the <input> element is still inline and thus not a valid child of <form>. The addition of a div (XHTML's generic block-level element) would solve the problem without any rendering differences given that <form> is also a block-level element. <form name="xforms"> <div> <input type="hidden" name="submitted" value="true" /> <!-- etc. --> </div> </form> will come closer to validating as XHTML (see below). (2) The name attribute of the <form> element has been deprecated in XHTML in favor of the id attribute (name is still valid for <input> elements, though). However, by filtering out the name attribute from the XFroms output in the epilogue, one breaks the inline JavaScript that underlies the xxforms:set element. For example, the inline JavaScript for a xxforms:set element referencing an XForm instance whose id is xforms begins like this: var f=document.forms['xforms']; where 'xforms' refers to a named form. A cumbersome, temporary solution would be to replace name attribute with an id attribute, look out for and modify the inline JavaScript, and add a div as the form's first child in the epilogue. However, this is unintuitive and would make more sense built into the XForms processor. Has anyone else worked around this? Am I crazy for requiring valid XHTML? (Hopefully, not.) Any assistance would be much appreciated. - Justin Makeig -- Center for Document Engineering University of California, Berkeley _______________________________________________ oxf-users mailing list [EMAIL PROTECTED] http://mail.orbeon.com/mailman/listinfo/oxf-users
