- From: Joe D Williams <joedwil@earthlink.net>
- Date: Mon, 18 Jan 2010 07:09:51 -0800
- To: "Henri Sivonen" <hsivonen@iki.fi>, <public-html@w3.org>
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