Re: <iframe doc="">

On Fri, 15 Jan 2010, Leif Halvard Silli wrote:
> 
> I checked (earlier today) and did not find anything under <iframe>, so I 
> think Ian is discussing the issue before adding anything - as he 
> indicated in his first message. ;-)

Indeed. (Well, there's the comment in the source that's been there for a 
few months, but it doesn't really give much in the way of details.)


> I don't know. It may be useful to be able to have a text/html section 
> inside a XHTML document - is that what you mean? But I suppose one would 
> also expect to be able to have a XHTML document in a XHTML document? 
> Though, of course, the XHTML doc could be interpreted as text/html ...

As I see it, the options are:

* Have doc="" in XML documents (and DOM-created documents that aren't 
flagged as an "HTML document") be parsed as XML. This has the advantage of 
being unsurprising.

* Have doc="" in all documents always be parsed as text/html. This would 
mean that you couldn't implement an XML-only HTML UA, which I think would 
be unfortunate.

* Have some sort of selector, so you could embed HTML in XML and XML in 
HTML. It's not clear what the use case for this is, and it has the same 
disadvantage as the previous one -- it would mean that implementations 
would always be required to implement both text/html and XML, which we've 
so far avoided.

There are other options, but these seem like the most obvious ones. I 
think I would probably lean towards the first one.

(I don't think there's any value in support polyglot <iframe sandbox="">es 
-- both security and polyglot markup are complicated enough to get right 
on their own; combining them is just asking for trouble.)


> As for <iframe> in a text/html document, would the code inside @doc have 
> to be a full HTML document, with DOCTYPE and everything, or could it be 
> a code fragment (for which the UA would generate the full DOM - 
> presumably)?

That's one of the open issues, but so far I'm leaning towards making the 
DOCTYPE be always implied and making the <title> optional, at least for 
text/html.

I'm not sure what to do for the XML variant; requiring the namespace each 
time seems a bit extreme. The simplest solution is to imply the <html 
xmlns="http://www.w3.org/1999/html"> ... </html> around the contents of 
the attribute, but then that would still require an explicit <head> and 
<body>, which is rather verbose.

I suppose we could look at what the root element is and then simply imply 
whatever parents it needs -- if it is an <html>, imply nothing, if it's a 
<body>, imply <html>, and otherwise, imply <html>, <head>, and <body>. But 
it would be very awkward to do that if there were scripts running in this 
document, which is one of the goals here.

I briefly considered saying we should imply the prefixes and default 
namespace that are in scope on the <iframe>, but then you run into all the 
dynamic QNames-in-attribute issues, so that's more-or-less a non-starter.

If anyone has any good ideas on how to make this work in XML without being 
so verbose, please do speak up.


> Would the code iniside @doc be validated?

By browsers? Or validators? Or...? There should certainly be authoring 
conformance criteria, as with anything else, IMHO.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 15 January 2010 02:27:18 UTC