- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 29 Mar 2007 15:48:54 +0200
- To: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
- CC: public-html@w3.org
Henrik Dvergsdal schrieb: > > > 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? Sorry, you also need <http://tools.ietf.org/html/rfc2557>, which defines "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)" on top of multipart/related. > 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? As far as I can tell, the HTML WG doesn't need to define this as long as it doesn't appear in documents of type text/html. Thus the usage of multipart/related in the MTHML format. > 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. AFAIK, the size of encoding in data URIs will be the same as with multipart/related; both require some kind of escaping. I'm not sure about the readability requirement - didn't you want to make this harder to read for the recipient anyway? :-) > 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. Understood, but it's a mystery to me how these choices affect the number of applications involved to do that... Best regards, Julian
Received on Thursday, 29 March 2007 13:49:05 UTC