[whatwg] The <iframe> element and sandboxing ideas

Wed May 21 19:41:22 PDT 2008

On Wed, May 21, 2008 at 5:30 PM, Ian Hickson <ian at hixie.ch> wrote:

> I'm thinking of introducing a
> new attribute. I haven't worked out what to call it yet, but definitely
> not "src", "source", "src2", "content", "value", or "data" -- maybe
> "html" or "doc", though neither of those are great. This attribute would
> take a string which would then be interpreted as the source document
> markup of an HTML document, much like the above; it would override src=""
> if it was present, allowing src="" to be used for legacy UAs:
>
>   <iframe seamless sandbox="allow-scripts allow-forms" doc="
>     <!DOCTYPE HTML>
>     <title></title>
>     Welcome to my blog!
>     </sandbox>
>     <a href='#' onclick='alert(document.cookie)'>Click here</a>
>   "></iframe>
>
> (There are things we can do to make this better, e.g. make the <!DOCTYPE
> HMTL> and <title></title> bits implicit, maybe introducing type="" to say
> whether it's HTML or XML instead of only supporting HTML, maybe saying
> that if src="" and doc="" are both specified they must have identical
> data, etc.)
>
> Comments and suggestions on this are welcome. I haven't added it to the
> spec yet. I do agree that without this or something equivalent that we
> don't have a solution for sandboxing embedded blog comments yet.
>
I'm trying to find the part of the spec where this is stated explicitly, but
aren't attributes limited to ascii text?  If this is intended (among other
things) to embed blog comments, this is no good - more than just us
English-speakers write comments.  Assuming I'm not remembering this whole
thing wrong, we either need to require an encoding that can preserve
non-ascii text without breaking (essentially, the data URI route), or go
another way entirely.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080521/bdee78ec/attachment-0001.htm>