- From: Jeff Schiller <codedread@gmail.com>
- Date: Thu, 24 Jul 2008 16:44:11 -0500
- To: public-exi@w3.org
- Message-ID: <da131fde0807241444me31a4e4x83f7af0b7c3ac57c@mail.gmail.com>
Reading a little more in HTML5 [1] and RFC2046 [2], it seems I would supply a parameter in the MIME type to specify the encoding? Would the following be technically correct? <object type="image/svg+xml; Content-transfer-encoding=x-exi" data="foo.svge"> <object type="image/svg+xml; Content-transfer-encoding=x-gzip" data="foo.svgz"> <object type="image/svg+xml" data="foo.svg"> <p>Fallback content</p> </object> </object> </object> Thanks, Jeff [1] http://www.whatwg.org/specs/web-apps/current-work/#type6 [2] http://www.faqs.org/rfcs/rfc2046.html On 7/24/08, Jeff Schiller <codedread@gmail.com> wrote: > > Hello, > > I still haven't gone through much of the documentation but I was hoping for > some quick answers first: > > 1) Will there be a encoding type that one can use on web servers (for > instance in Apache's .htaccess)? For instance: > > AddType image/svg+xml .svge > AddEncoding exi .svge > > 2) I serve a lot of gzip-encoded SVG on my site using html:object like > this: > > <object type="image/svg+xml" data="foo.svgz"><p>Fallback</p></object> > > Would there be a way to wrap another <object> around this to offer the > EXI-encoded version to browsers that support it? How could one achieve > this? > > In other words, what sort of mechanisms can be put in place between client > and server such that those browsers that might adopt EXI earlier can benefit > but non-adopters can still cope? > > Thanks! > Jeff Schiller > http://blog.codedread.com/ > > >
Received on Thursday, 24 July 2008 21:44:48 UTC