Re: <iframe doc="">

On Jan 16, 2010, at 11:39, Julian Reschke wrote:

Julian >> I thought markup in attributes was a super-anti-pattern.

Henri > It is, but it seems it's the safest way to hack in-file 
sandboxes into HTML. :-(

from another thread on this Adam >> Keep in mind that you most often 
want to use this feature without the allow-origin directive, which 
means you won't be able to reach into the frame to call document.write 
or set innerHTML.

So that is a big part of  the opportunity. The author wishes to import 
some html5 into a docmument and requires some level of security in 
terms of allowed interactions with the host document. Of course there 
are ore specific ways to acheve this using <embed> or <object>, but 
for conveneince and ease of use we choose to develop <iframe> because 
with some simple considerations we can produce the desired leels of 
security. Again, for convenience, we are calling an instance of an 
<iframe> a nested context. This means the effect we wish to produce is 
as if the host DOM and the imported DOM are isolated, as demanded in 
<embed> and <object>, but instead by a flexible set of limitations and 
permissions.

These range from allowing complete access to imported content by the 
host DOM - as if the content were an inline part of the host 
document - to the imported content access to the the 'host' DOM and 
vice-versa complete access to the   , we call thisn <iframe> and 
maintrain cotrol of the in/out. The html5 I import also wants to 
control to access its in/outs.


outsthe problem


----- Original Message ----- 
From: "Henri Sivonen" <hsivonen@iki.fi>
To: <public-html@w3.org>
Sent: Monday, January 18, 2010 2:36 AM
Subject: Re: <iframe doc="">


On Jan 15, 2010, at 04:26, Ian Hickson wrote:

> * 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.

Is it really unsurprising? I'd extrapolate from innerHTML that it's 
bad for stuff you can script via the DOM to change behavior depending 
on the HTMLness bit of the Document object. It's bad that you have to 
revise innerHTML access in the bowels of a JS library if you want to 
use the library with XHTML.

As a general principle, I think new stuff that depends on the HTMLness 
bit shouldn't be introduced.

> * 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.

Shouldn't XML-only UAs fall into the theoretical purity bucket for the 
purposes of the Design Principles?

> * 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.

If you have html='...' and xml='...' attributes, you could say that an 
HTML-only UA isn't required to implement xml='...' and an XHTML-only 
UA isn't required to implement html='...'. Such non-requirements would 
be equally impractical as loading HTML in an iframe in an XHTML-only 
UA or vice versa with the spec as it stands today.

On Jan 16, 2010, at 11:39, Julian Reschke wrote:

> I thought markup in attributes was a super-anti-pattern.


It is, but it seems it's the safest way to hack in-file sandboxes into 
HTML. :-(

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 18 January 2010 15:10:29 UTC