W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007

Re: Multipart response support

From: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
Date: Thu, 29 Mar 2007 15:35:30 +0200
Message-Id: <342E1CF3-69CC-4FA6-BE9F-374DBA5F7C57@hibo.no>
To: public-html@w3.org


On 29. mar. 2007, at 12.27, Julian Reschke wrote:

> But that's not an HTML feature, but a browser feature. IE already  
> supports it, and the spec is at <http://tools.ietf.org/html/ 
> rfc2387>. You may want to lobby for an update of that spec, and for  
> support in Mozilla, but that really isn't something for the HTML WG  
> (imho).

That RFC just describes the multipart/related MIME content type. What  
feature are you referring to?

What *is* something for the HTML WG, however, is to decide wether or  
not we should extend the syntax of some href and src attributes to  
accept references to attachments. Who else should make that kind of  
decisions?

Pre-loading:
> You can already do that with "data" URIs

I realize that everything that can be done with multipart responses  
can also be done with data URI's - at least in principle. The only  
problem is the size limitation and the reduced readability of the  
HTML document.

Generated content in server side applications:
> Can you explain how you need "separate applications" for that?

If you want to ouput a image that is generated on the fly, say a  
clock or map something, you have to create a separate application  
that outputs that image. You then refer to the URL of that  
application in the src attribute of the img element.

Alternatively you may include the image by means of a data URI. What  
I suggest is to provide an opportunity to include it in an attachment  
and refer to that attachment in the src attribute.

--
Henrik
Received on Thursday, 29 March 2007 13:35:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 March 2007 13:35:44 GMT