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

On Mon, 30 Apr 2007 14:29:28 +0200, Mark Birbeck <mark.birbeck@x-port.net>  
wrote:

>> 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.

Wow. I really did assume that most authors learn by looking at (and  
copying) other people's source code. It's what I did, at least, and what  
people I've talked to did. (I didn't say everyone, and I didn't say that  
they do so exclusively.)

But for the sake of argument, let's assume that an author who already  
knows about HTML4+JS (doesn't matter how he learnt it) was reading an  
article about new forms stuff. The article contains markup examples. With  
WF2, by just looking at the markup examples, he can understand what the  
markup does, without reading the rest of the article. With the XFT example  
this is not the case because HTML4 doesn't have similar constructs.

> 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.

Indeed.

>> [...]
>> 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.

Sure, but when something can be done with either an existing concept or  
with a new concept, then using the existing concept seems preferable to me.

> Anyway, not
> every attribute in HTML is an event handler, so why would one assume
> that @calculate is?

Every attribute that takes JS as value is an event handler attribute in  
HTML4, AFAICT.

>> 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.

Authors do what's simplest. If they can look at or copy someone else's  
markup and also understand what it does, then why would they need or want  
to read articles or specs?

>> 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.

Ok.

-- 
Simon Pieters

Received on Monday, 30 April 2007 15:09:49 UTC