- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 14 Jan 2010 21:43:05 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Doug Schepers <schepers@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org" <public-html@w3.org>
Maciej Stachowiak, Wed, 13 Jan 2010 12:52:20 -0800: > > On Jan 13, 2010, at 12:50 PM, Doug Schepers wrote: > >> Hi, folks- >> >> Tab Atkins Jr. wrote (on 1/13/10 10:23 AM): >>> On Wed, Jan 13, 2010 at 8:42 AM, Leonard >>> Rosenthol<lrosenth@adobe.com> wrote: >>>> I don't understand how you can assume that the destination of the >>>> doc URL is going to be text/HTML? Why couldn't the iFrame be >>>> pointing to an SVG image, for example, or a PDF? Those are also >>>> valid (and in the latter case of PDF, quite common) things one >>>> would put in an iFrame and wish to refer to... >>> >>> @doc doesn't take a url, it takes literal html code (with quotes >>> escaped). It is intended to help with the use of multiple<iframe>s >>> on a page, especially @sandbox'd ones, so that you don't incur >>> multiple network requests but still get the security benefits of >>> framing the content such as blog comments. >> >> The question still remains... would @doc allow SVG code, for example? > > Using SVG-in-HTML, yes (since it assumes a text/html MIME type). > Using the traditional XML serialization of SVG, no. And if I serve the HTML5 document as application/xhtml+xml, then what? Would @doc then still expect text/html - only? -- leif halvard silli
Received on Thursday, 14 January 2010 20:43:43 UTC