W3C home > Mailing lists > Public > www-forms@w3.org > June 2000

RE: XForms not enough

From: Joe Hewitt <joe@joehewitt.com>
Date: Sat, 10 Jun 2000 11:11:38 -0400
To: <www-forms@w3.org>
Message-ID: <NDBBJPCODLDHLAGMEIADAENLCJAA.joe@joehewitt.com>
> Whatever happened to Microsoft's HTML Component's and
> Netscape's XBL proposal?

The W3C seems to have lost interest in the nearly one-year-old BECSS module
of CSS3.  Anyway, it seems to me that CSS is not the right place to put an
"HTML Components" specification.  The CSS connection is really limited to
the "behavior" CSS property.

I've worked with Netscape's XBL and Microsoft's Behaviors and I definitely
like both.  They are functionally quite similar, but syntactically very
different.  I'm sure that if the W3C managed to come up with a single HTML
Components standard, both Netscape and Microsoft would do their best to
ignore it (esp. MS).  Perhaps that's why it is lingering.

Anyway, as I have said, HTML Components is very important but first there
should be a set of built-in components that every browser ships with.  Look
at XUL for ideas of what is most important.

The problem with applying the title "forms" to a UI XML language is that UIs
are not really limited to the forms paradigm.  So, to me it would make sense
for the XForms spec to not require or specify any particular type of user
interface controls. They should leave the specific UI stuff to a separate
set of XHTML modules.

With that in mind, here's my view of how it should be broken up:

XForms modules
1. data model (XSchema compatible)
   a. data types
   b. validation rules
2. binding to presentation markup
   a. XPath-like binding syntax
   b. attribute containing binding
      1. (I personally would rather use something like
          "xfm:binding" instead of just "name")
3. validation presentation rules
   a. something like this:
      1. <input
             xfm:binding="order.contact.fname"
             xfm:title="First Name"
             xfm:invalid="#TITLE# is invalid because #REASON#."/>
4. HTTP post format
5. DOM interfaces
   a. manipulate data model
   b. get/post instance data
   c. explicit validation
   d. attach/detach/alter bindings

XHTML modules
1. User Interface markup language
   a. spring-flex box model
   b. library of common controls
2. XHTML Components markup language

Is this remotely near what the XForms working group has in mind?

- Joe
Received on Saturday, 10 June 2000 11:12:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:48 GMT