Re: About the Web Forms 2 proposal

Maciej Stachowiak wrote:
> 
> 
> On Apr 28, 2007, at 9:03 PM, Doug Schepers wrote:
> 
>> John Boyer wrote:
>>> And the use cases you listed here (
>>> http://esw.w3.org/topic/HTML/FormsUseCases) are pretty trivial.
>>
>> On the one hand, I agree that this list isn't really comprehensive. 
>> When you consider some many Web applications use hoop-jumping 
>> libraries to supply multiple dialogs and numerous inputs, there is 
>> clearly a desire to have more complex forms than are addressed by this 
>> list of use cases.
> 
> I'd love to hear examples, especially if you can cite multiple sites 
> doing the same sort of thing.

Well, I didn't keep notes on where I've seen such things, but I suspect 
that a survey of sites using dojo and Prototype would turn up quite a few.


> That's a good point. Tax forms are pretty complex. But even here, I'm 
> not sure declarative client-side features would help much. 

I think that in the problem case I mentioned, with the "worksheet", had 
they had a simple way to set up a calculation and dependency matrix 
(which is where a declarative solution shines), it would have worked out 
better.  We could ensure that by taking such use cases into account when 
designing the language.


> For security 
> and data integrity reasons, you really need to checkpoint the data to 
> the server often, time out the login session after some period of 
> inactivity, and verify all the important calculations server-side.

They could have done that with existing technologies, and no doubt they 
tried, but it still came up short.  It would be interesting to talk to 
them (and other large site that use complex forms) to see what 
challenges they faced and how we could have improved their development 
experience (whether declaratively or not).


> Maybe we can think of features to improve tax forms. But let's keep in 
> mind that this is a form most people fill in once a year, as opposed to 
> the kind they fill in multiple times a day. I do realize there are 
> exceptions for specific business domains, but I think specialized 
 > problems can be solved by specialized solutions.

The tax form was just one example.  There are lots of similar things 
that could be brought online, especially for government services or 
regulated industries (construction, contract bidding, legal disclosures, 
etc.).  Like I said, PDF has quite a niche there, and I'm personally 
uncomfortable with government documents being in a proprietary format.

I'm not sure if you consider intranets as a target audience, but you 
should, and these large forms that see frequent repetitive use are more 
common there.

I don't think PDF is a specialized solution (I think it's very general, 
in fact), nor do I think these are specialized problems.  I'm not 
proposing that HTML become a PDF-killer, but there is a demonstrated 
need that goes beyond the simplest use cases.  Maybe it should be solved 
by some other language than HTML.  I don't know.  But unless it's 
implemented natively in browsers, I don't think it has much chance to be 
adopted.

Flash and PDF only win out as plugins because of huge marketing dollars 
and concerted effort by a single vendor who *needs* that buy-in. 
Open-standards browsers don't really have the same type of pressures, 
nor are they selling the same products.  I can't think of a single 
open-standard technology implemented only as a plugin (SVG included) 
that could be said to be an unqualified success.  Thus, I don't think 
your demand-reflects-desire stance is entirely accurate.  Large 
companies are typically conservative in the technologies they will use 
(even if they are interested); if it's not native in the major browsers, 
they are very reluctant to use it (unless they have a stake in it). 
This applies to SVG, and I'm sure it applies to these more advanced 
forms features.

Regards-
-Doug

Received on Sunday, 29 April 2007 17:46:59 UTC