Projects‎ > ‎

XForms - Noscript (JavaScript-free) Mode

This page describes extending the Orbeon Forms XForms engine to support JavaScript-free operation. In short, this is now referred to "noscript" operation, inspired by the HTML "noscript" tag.

Rationale

This is an important requirement:

  • For accessibility reasons. Some countries have laws that require that certain public sites do not require JavaScript, or do have an option for JavaScript-free operation.
  • This also allows targeting much older web browsers, and users who have decided not to enable JavaScript.

XForms being fairly high-level, the XForms engine can target both JavaScript-enabled and JavaScript-free clients. Removing JavaScript comes at a cost in usability of the form for regular users, and excludes a number of features. However the hope is that many data entry forms which do not require very high interaction can support JavaScript-less operation.

Features

  • This mode is in addition to the current JavaScript mode
  • Requires a little bit more memory on the server as the initial XHTML page is entirely kept there
  • Actions will cause an HTML form submissions and a complete redisplay of the page
  • This does not preclude the use of events and actions, but those will run only upon the user pressing buttons
  • Limitations that most likely won't be overcome:
    • No "as you type" validation
    • User-triggered refreshes are needed to update field validity and other dynamic behavior (calculations)
    • No background file uploads
    • Different appearance / behavior of help/hint (and possibly alert)
    • No text/html editor
    • etc.
  • Limitations that could be overcome (2nd phase)
    • Calendar input is disabled
    • No link appearance for triggers [NOTE: In fact, with styling, we can make HTML buttons look close enough from links.]
    • No advanced widgets (dialogs, menus, etc.) -> those could be represented as HTML but they need work
    • etc.
  • Enabling noscript mode:
    • Form author-based property
    • Option for automatic detection of JavaScript on the client [TODO]

Implementation Notes

  • Mode is enabled with xxforms:noscript="true" property, either global or per page
  • XFormsToXHTML passes the XHTML SAXStore to XFormsStaticState
  • XFormsStaticState checks a property to see if XHTML SAXStore must be kept and serialized
  • XFormsStaticState is able to serialize and restore XHTML SAXStore
  • XHTMLHeadHandler does not output any scripts
  • No event handler on xhtml:form element
  • All submit buttons have type="submit" or type="image"
  • XFormsToXHTML exposes method to output XHTML. This is reused by XFormsServer.
  • Posts to /xforms-server-submit are detected with a hidden form field called $noscript set to true
  • Event reconstruction is done in xforms-server-submit.xpl with xxforms-change-or-activate. This is then converted to a value change/DOMActivate by XFCD
  • Triggers with minimal appearance are buttons, which are styled as close as possible to HTML links
  • xforms:submission[@replace = 'all']: no two-pass submission must take place here => result is output directly from XFormsServer using ContentHandler and a binary document (same idea will apply to replace="all" during initialization)
  • Submission URL for XForms processing: we POST to current page URL; xforms-xml-submission.xpl intercepts those submissions and calls xforms-server-submit.xpl; that's because /xforms-server-submit has issues:
    • It doesn't look nice
    • Theme detection fails in the epilogue with that URL
  • property('xxforms:noscript') returns true() or false()
  • Limitation:
    • xforms:submission/@xxforms:target doesn't work as you would need to produce an HTML <form target="..."> in advance.
  • HTML select controls need a @name attribute

  • Produce accessible help section at the bottom of the form [TODO]

  • Form Runner
    • fr-noscript=true URL parameter triggers the noscript mode
    • submissions and loads forward fr-noscript=true URL parameter (non-PDF print submissions, navigation between summary/detail)
    • Refresh button added automatically at the bottom

Handing of Help

Help in noscript mode cannot benefit from JavaScript. This is the strategy used:
  • A native mechanism is provided to allow:
    • Linking to a separate help section: help images are surrounded by <a href="#control-id-help"><img.../></a>
    • Being linked back from a help section: controls that have an xforms:help element are preceded by a <a name="control-id"/>
  • Currently, the help section is not produced natively
    • Form Runner produces it in a special area of the page

Suggestions for Future Developments

In this thread, Andy suggests that it would be great to send the same HTML page to the client in noscript and JavaScript mode. It may be possible, at least mostly, and I can see how it would be very cool, but it is not done this way now.

Forms are handled a little differently in noscript mode:
  • The full XHTML+XForms content is kept on the server, which is not the case of the JavaScript mode. In case your client supports JavaScript, then you would be keeping that information for nothing.
  • Client-side repeat templates and separators are not added to the XHTML in noscript mode.
    • Note that this is desirable for accessibility reasons (screen readers)
  • Triggers as links (appearance="minimal") can't work without script, so they are output differently in the two modes ("fake" links in noscript mode).
  • Inclusion of JS files: this is not an issue for browsers that don't have JS enabled as they won't load the files
Solutions are needed for all those points. 

Need to differentiate:
  • Automatic mode for browsers that don't support JS
  • Manual mode for accessible pages with cleaned-up HTML
In the meanwhile, you can do user agent-sniffing. It is not great, but it will work in many situations.

Comments