- From: James P. Salsman <bovik@best.com>
- Date: Sat, 1 Apr 2000 16:30:23 -0800 (PST)
- To: stephanos@webreference.com
- Cc: ietf@ietf.org, www-forms@w3.org, www-html@w3.org
Stephanos, Thanks for your message: >... You need detailed definitions, changes to DTDs, and more. > If you have these details, it would be nice to point us all to a > proposal so we know how "DEVICE" and "MAXTIME" would work. Sorry about not pointing to this document: http://www.bovik.org/device-upload.html in every message. It started out as an Internet Draft in late 1997. > WHAT CONCERNS [from Norman Solomon's article in FAIR's _Extra!_], > and HOW DO THEY RELATE TO THIS DISCUSSION? The same concerns I had after participating in the W3C's extended forms working group for most of last year -- that they care far more about e-commerce that they should (to the point of wanting to completely overhaul perfectly serviceable HTML forms as the are) and at the same time are seriously neglecting educational needs. >... We've HAD this technical discussion here AGES ago. Create a form, > give it an accept type of audio/whatever and let the user agent > bother about how to get it. If that's too primitive for your needs, > go and create a separate protocol.... Not only does the chair of the HTML Working Group and everyone else in the W3C who has spoken out on the topic, including Tim Berners-Lee, agree with these sentiments, SO DO I!!! In a perfect world, all of the browser authors would implement device upload using the ACCEPT attribute within INPUT TYPE=FILE. However, in the world we live in, NONE of them have done that. The only reason why that I've been able to find, after years of communication with them and studying their code, when it has been available, is that many major releases of the big-two browsers have interpreted the ACCEPT attribute as a filename pattern. The underlying reason is that at for a long while, the official HTML 3.2 specification suggested ACCEPT was supposed to be a filename pattern, so that was the correct behavior as interpreted by the browser developers, and it has probably become part of some legacy application somewhere. So people have a choice, between idealism, where everybody faithfully implements the specs exactly as they are handed down (even if they don't remain consistent between revisions of the same version number), and pragmatism, where the introduction of an extra attribute (such as DEVICE) would allow the browser authors to rest easy that they aren't breaking anyone's legacy implementations of a ACCEPT, while at the same time providing a way to specify a default device selection. Setting aside the fact that the HTML Working Group claims it would be bad user interface design to allow for the selection of a default (a position I find untenable), which is the practical choice? Which is better for spoken language instruction? Which makes it more likely that mass-market portable wireless boxes will implement high-quality asynchronous voice messaging even under very-low-bandwidth conditions? Cheers, James P.S. sorry about the echoed message sans my reply
Received on Saturday, 1 April 2000 19:30:55 UTC