W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: HTML forms, XForms, Web Forms - which and how much?

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Mon, 30 Apr 2007 13:29:28 +0100
Message-ID: <640dd5060704300529u70a16269xec412a16436f3e2b@mail.gmail.com>
To: public-html@w3.org

Hi Simon,

> Not that it does the same thing, but my point is that an author who knows
> HTML4 can understand how the WF2 markup works without even reading the
> spec. I think this is important, since most authors won't read the spec.

If your argument was correct, then everyone would learn about mark-up
simply by reading other people's mark-up, which is obviously not what
happens. Most authors will read _articles_ by other authors, so I
think this really is a red herring.

However, when designing languages it is certainly a good idea to
follow the 'principle of least surprise'. For example, if we called
the XForms attribute 'onvalue' or 'oncalculate', but made it so that
the contents of the attribute were not an action handler, then that
would be confusing. But hopefully that hasn't been done in XForms.


> [...]
> calculate="": Hmm... what's put inside looks like it could be JS, but the
> attribute doesn't look like an event handler attribute. Is it? Which
> events does it listen to? When do they fire? Can any JS be inserted here?
> Is it JS to begin with?
>
> There's nothing in HTML4 that is similar to this.

I agree with that. It certainly means that clear explanation is
necessary, but it doesn't mean we should limit functionality to only
those things that can be created using existing concepts. Anyway, not
every attribute in HTML is an event handler, so why would one assume
that @calculate is?


> Even I, who have read the XFT document, can't tell how calculate="" really
> works or what can be put inside. How should we expect authors who won't
> read the spec to understand it?

See the first point, above; it's true that authors may not read the
spec, but they will need to read _something_. It's simply not true
that authors read mark-up and nothing else.


> Shorter markup does not imply greater understanding among authors. I think
> it is a mistake to introduce non-event-handler-but-still-JS-attributes to
> HTML.

I definitely agree, but I don't think we were discussing
_abbreviation_ of mark-up, so much as how easy it was to mark-up some
given behaviour. I picked a simple example that showed some output
that was based on the values of some other data, which I felt was a
common use-case. But I wasn't looking for the shortest way of writing
it--I was trying to show that XForms can convey this at least as
succinctly as any of the other proposals around, as well as providing
a much greater level of functionality when the author needs it.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.
Received on Monday, 30 April 2007 12:29:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:53 GMT