- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 29 Apr 2007 16:18:16 -0700
- To: Doug Schepers <doug.schepers@vectoreal.com>
- Cc: public-html@w3.org
On Apr 29, 2007, at 10:46 AM, Doug Schepers wrote: > > 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. I've looked at a lot of sites using dojo and prototype. In my experience, their complexity rarely lies in form logic. Mostly it is in fancy dynamic layouts and general application logic. >> 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. That doesn't seem obvious to me, but I don't know the details of the scenario. >> 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. They do use existing technologies -- in what way do you think they came up short? I used turbotax online to do my taxes this year and it seemed like a pretty good experience, at least as much as doing your taxes can be. I think they do all the things I mentioned above. Your worksheet problem sounds like just a case they didn't think of. > 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). I'd like to talk to the sites with the everyday sorts of forms first, since those appear to be far more common. >> 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. My understanding is that PDF forms use JavaScript, not declarative constructs, for all their logic. Furthermore, I'm told PDF forms are used instead of HTML because they give better formatting control, and for government use especially there are often specific requirements on how the form should look. To aim for this niche we would need better control over printed output. > 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 think intranet use is an interesting secondary use case, but any feature that is only interesting for internal business use is dubious. Because these are controlled envioronments, interoperability is less important, and use of specialized technologies is acceptable. > 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. I don't think we can address the precise printed output of PDF by adding declarative expression features that PDF lacks. > 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. There aren't that many technologies implemented only as a plugin that are an unqualified success, open standard or not. But I'm also not sure what you count as an open standard. PDF (implemented via the Acrobat plugin) and MPEG-4 (implemented via the QuickTime plugin) are both pretty successful and are open standards, although not W3C standards. Furthermore, many script libraries see huge success (such as the dojo and prototype you mentioned). > 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. In my experience, intranet sites are much more willing than public web sites to use specialized plugins, advanced features only in the newest versions of browsers or only in a single browser, and even quite complex JavaScript application frameworks. For middleware applications catering to such uses, the burden is much more on Apple as a browser vendor to support the features they demand in order to be supported than for public web sites. Regards, Maciej
Received on Sunday, 29 April 2007 23:18:26 UTC