Re: <iframe doc="">

> any markup-in-attribute proposal,

Hey, don't do this! Sorry for the extreme, but my nice message got 
lost by my error. The lost message was several great reasons why to 
reject this idea of allowing doc="[html5 user code]" where optional 
html5 user code represents an actual or miminal html5 document encoded 
as escaped html5 syntax intended to be renderable content by its 
parent element.

There are a bunch of good reasons to reject this, I think, but one is 
that xml parsers are not wired that way. As usual, I would ask for 
other examples of this in html5. Essentially, in this, the browser 
gets to grab that attribute value string and do a document.write 
except the root of that document must be the parent iframe.

> > Given the fact that introducing new attributes to HTML is very 
> > expensive

Anyway, I appreciate the idea of being able to import user code easily 
but this is a far stretch from being easy and as to the expense, I 
don't see any comparison between implementing a new attribute that 
acts like an attribute, with implementing this attribute that acts 
sort of like an element and demands special attention for authors and 
validators as well as the host browser. This will not produce a useful 
shortcut cowpath. It is just too far off the track.

Besides, why should the first time we see proposed spec text for this 
or any be in the spec? Why not show the text for new IDL and propsed 
defintions here first. To get this New idea in the spec, a couple of 
browsers should first be showing this as workable and usable, not the 
other way around where the standard is defining somethng that has 
never? actually worked for anyone but seems at first sight like it may 
be novel and might even be userful.

Thanks and Best Regards,
Joe



- Original Message ----- 
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Philip Taylor" <pjt47@cam.ac.uk>
Cc: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>; "Ian Hickson" 
<ian@hixie.ch>; <public-html@w3.org>
Sent: Sunday, January 17, 2010 5:09 AM
Subject: Re: <iframe doc="">


> Philip Taylor wrote:
>> ...
>> Why "especially for the doc proposal"? The ampersand problem seems 
>> the same for any markup-in-attribute proposal, and doc has far 
>> fewer escaping problems than the data: alternative.
>> ...
>
> Hmmm... Really?
>
>> Presumably almost nobody is ever going to write the markup by hand, 
>> since the point is to embed untrusted content in a sandbox, and if 
>> you're embedding it by hand you can verify the content visually and 
>> don't need to sandbox it. So the important thing is how server-side 
>> code will do the escaping.
>
> +1
>
> To get these things right (as in "working" and "valid"), it's almost 
> certain you won't be hand-authoring this.
>
>> If you have a (Perl) script which does something like
>>
>>   print "<iframe sandbox doc=\"$doc\">";
>>
>> you'll have to escape with something like
>>
>>   s/"/&quot;/g;
>>
>> in order to avoid security vulnerabilities, and also with
>>
>>   s/&/&amp;/g;
>>
>> in order to get correct processing. If you instead had
>
> And also "<" when using XHTML.
>
>>   print "<iframe sandbox 
>> src=\"data:text/html;charset=utf-8,$doc\">";
>>
>> you'd still just have to escape " for safety; but for correct 
>> processing in current browsers you'd have to at least escape & and 
>> do
>>
>>   s/%/%25/g;
>>   s/#/%23/g;
>>
>> (are there any others you need?) and for validity I think you'd 
>> have to instead do
>>
>>   s/([^;\/?:@&=+$,a-zA-Z0-9-_.!~*'()])/join "", map { sprintf 
>> "%%%02x", $_ } unpack "C*", encode("utf-8", $1)/eg;
>>
>> (if I interpret RFC2397's reference to RFC2396's "urlchar" as 
>> actually meaning "uric", and if I haven't made stupid mistakes).
>
> Or you might already have a library that encodes URIs/IRIs.
>
>> Your server-side script probably already has access to an HTML 
>> escape function that will do what's needed for <iframe doc>, and if 
>> you have a decent templating system it'll do it automatically. It's 
>> no different to any other form of embedding content from the user, 
>> so it doesn't seem an unreasonable burden. (Escaping data: 
>> correctly is a lot more complex and a lot less likely to be 
>> provided as a function in your server environment.)
>
> Even if this is true that should be relatively simple to fix.
>
> Given the fact that introducing new attributes to HTML is very 
> expensive ([1]), making "data:" work for this should really be 
> considered.
>
> BR, Julian
>
> [1] <http://krijnhoetmer.nl/irc-logs/whatwg/20081120#l-184>
>
>

Received on Sunday, 17 January 2010 16:51:28 UTC