- From: Doug Schepers <doug.schepers@vectoreal.com>
- Date: Sun, 29 Apr 2007 13:46:53 -0400
- To: public-html@w3.org
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