Re: Device upload for all platforms -- the official HTML WG position

On Thu, 2 Mar 2000, James P. Salsman wrote:

> Walter,
> 
> Thanks for your message:
> 
> >... How about ACCEPT="audio/aifc; device=microphone" ?
> 
> Those parameters following the semicolon modify the type, so for 
> example, you might have "audio/l8;rate=8000;channels=1" for 
> low-quality 8-bit monophonic audio, of "audio/l16;rate=48000;channels=2"
> for DAT-quality stereo.  If you were to use that form, then 
> you might have to regester a "device" parameter for each MIME 
> type, and code it in for each type alternative that you ACCEPT.

I agree with this; content type parameters aren't the right place to
indicate a source for the content.

> But I do agree with everyone who says that RFC-1867-style file 
> uploads could be device uploads using the ACCEPT attribute, if 
> you're willing to give up a default device selection.

I think default device selection should be the domain of the user, not the
author. So I am more than willing to give this up.

>  And indeed
> this wouldn't involve changing anything in the specs.  But if it 
> were such a good idea, wouldn't it have been done?

The same might be asked of robust LINK element implementation, and quite
a few other standardized techniques. Apparently the the commercial
browsers don't perceive consumer demand for it.

>  The problem is, 
> there are no browsers that do anything like that -- the big-two 
> wintel browsers interpret ACCEPT as a filename pattern!

So we have an existing spec that would suit your end to at least some
extent, and it isn't being implemented. So the solution is to throw
another spec at the problem?

> The only 
> way to obtain device upload does not even involve the INPUT tag 
> (on Windows' MSIE, the OBJECT tag is used with an insecure 
> "ActiveX" binary; on Netscape Navigator under Windows, the EMBED 
> tag is used with a similarly insecure arrangement where the user 
> must "Grant All" system privleges to the EMBEDed binary code.)  

Yes, well, one could probably use OBJECT/EMBED to make pigs fly if one
were so inclined and prepared to waive the relevant security precautions.
Such implementations are interesting in that they demonstrate the
availability of the technology, but the applicability of their syntax to a
general purpose mechanism for a specific need is low to nil. This
situation is by no means unique to device upload, nor is it a particularly
surprising outcome.

> This complex state of affairs need not be so.
> 
> If the W3C would just take a stand, and tell the browser vendors 
> that in order to be compliant with the W3C Recommendations, if 
> device upload is implemented then it should be available in a 
> certain way, then they would probably conform to stay compliant.

The W3C has defined conformance terms for HTML 4, CSS1, CSS2... And how
many browsers conform to date? I'm a little bit skeptical that having the
W3C stomp its feet would do a bit of good.

-- 
Braden N. McDaniel
braden@endoframe.com
<URL:http://www.endoframe.com>

Received on Thursday, 2 March 2000 04:15:45 UTC