W3C home > Mailing lists > Public > www-forms@w3.org > November 2001

Re: Non-browser compliance

From: Berin Loritsch <bloritsch@apache.org>
Date: Thu, 08 Nov 2001 10:40:07 -0500
Message-ID: <3BEAA757.35888A23@apache.org>
To: "David E. Cleary" <davec@progress.com>
CC: Jim Wissner <jim@jbrix.org>, www-forms@w3.org
"David E. Cleary" wrote:
> > So you can see how two applications (Xybrix and a web browser) could
> > potentially both be 100% xforms compliant, and yet be unable to read and
> > render the same documents.
> XForms can easily be split into two parts, the form purpose and the form
> presentation. The presentation side of the equation isn't tied to any
> particular vocabulary. You can bind a form to XForms widgets, XHTML widgets,
> WAP widgets, or a proprietary vocabulary. Obviously, the presentation
> vocabulary you choose is dependent on the client being able to render it.
> However, the pupose of the form does not change at all.

Here are some issues with XForms that poke holes in your statement above:

* XForms UI is a combination of markup (easily transformable) and CSS statements
  (which if they are kept in a separate file are almost impossible to easily
  transform).  This is IMO a case where the spec does not go far enough.
  I prefer CSS to *only* control color, spacing, text style, and other non-
  essential styling that can easily be applied to whatever markup you use.
  Things so essential to the presentation of the widget like is the selectOne
  element a group of radio buttons, check-boxes, or regular buttons should
  not IMHO be a CSS property.  It should be a "type" attribute or something

* XForms layout is inextricably tied to the container markup.  This means that
  unless you use your own application markup (something ExFormula will specify
  RSN) you are tied to one presentation.  This is not a happy situation.  The
  point that Jim Wissner made is very true--a development team does not want
  to maintain several versions of the same form.  They want one form, that can
  be displayed in several ways.  For instance, I want to be able to use the
  same form in XHTML and WML--currently impossible.

> If Xybrix doesn't support (X)HTML, then, people shouldn't expect it to
> render it. Same goes in the other direction. But this is be design.

And that's the problem.  The design is flawed in this respect.


"Those who would trade liberty for
 temporary security deserve neither"
                - Benjamin Franklin
Received on Thursday, 8 November 2001 10:38:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:05 UTC