- From: Shelley Powers <shelley.just@gmail.com>
- Date: Sun, 24 Jan 2010 08:56:14 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
Oh, no. I just looked at the example in the iframe section. Repeated below for your edification: Here a blog uses the srcdoc attribute in conjunction with the sandbox and seamless attributes described below to provide users of user agents that support this feature with an extra layer of protection from script injection in the blog post comments: <article> <h1>I got my own magazine!</h1> <p>After much effort, I've finally found a publisher, and so now I have my own magazine! Isn't that awesome?! The first issue will come out in September, and we have articles about getting food, and about getting in boxes, it's going to be great!</p> <footer> <p>Written by <a href="/users/cap">cap</a>. <time pubdate>2009-08-21T23:32Z</time></p> </footer> <article> <footer> At <time pubdate>2009-08-21T23:35Z</time>, <a href="/users/ch">ch</a> writes: </footer> <iframe seamless sandbox="allow-same-origin" srcdoc="<p>did you get a cover picture yet?"></iframe> </article> <article> <footer> At <time pubdate>2009-08-21T23:44Z</time>, <a href="/users/cap">cap</a> writes: </footer> <iframe seamless sandbox="allow-same-origin" srcdoc="<p>Yeah, you can see it <a href="/gallery/cover/1">in my gallery</a>."></iframe> </article> <article> <footer> At <time pubdate>2009-08-21T23:58Z</time>, <a href="/users/ch">ch</a> writes: </footer> <iframe seamless sandbox="allow-same-origin" srcdoc="<p>hey that's earl's table. <p>you should get earl&amp;me on the next cover."></iframe> </article> Do not expect me to be anything but absolutely appalled that something like that would exist in an HTML document. I have never seen anything so awful, and so guaranteed to cause problems for authors as that. Frankly, I know of few authors that wouldn't look at that and not be very unhappy. Sorry if I'm offending or hurting feelings, but there was no consensus on this. How could there be consensus on this? And now, the only way to reverse this unilateral decision is _we_ have to now go through the Decision process. Shelley On Sun, Jan 24, 2010 at 7:57 AM, Shelley Powers <shelley.just@gmail.com> wrote: > Was there a consensus of this group to add this? > > > > On Sun, Jan 24, 2010 at 5:43 AM, Ian Hickson <ian@hixie.ch> wrote: >> >> I've now added <iframe srcdoc=""> to the spec. >> >> On Wed, 13 Jan 2010, Leonard Rosenthol wrote: >>> >>> I don't understand how you can assume that the destination of the doc >>> URL is going to be text/HTML? >> >> It's not a URL, it is just embedded content. >> >> >>> Why couldn't the iFrame be pointing to an SVG image, for example, or a >>> PDF? Those are also valid (and in the latter case of PDF, quite common) >>> things one would put in an iFrame and wish to refer to... >> >> Sure. That is possible, and supported by the src="" attribute. >> >> >> On Wed, 13 Jan 2010, Doug Schepers wrote: >>> >>> The question still remains... would @doc allow SVG code, for example? >> >> Insofar as text/html allows SVG, yes. >> >> The main use case here is blog comments; people don't generally support >> SVG in blog comments anyway, and I'm not aware of any requests to support >> this, so I don't think we need to support XML-based SVG (or MathML, or >> XForms, or XBL2, or anything else really) explicitly. However, it's >> obviously something we could extend in a future verison, e.g. by adding a >> "srcdoctype" attribute, if people really wanted this. >> >> >> On Fri, 15 Jan 2010, Leif Halvard Silli wrote: >>> > >>> > I'm not sure what to do for the XML variant; >>> >>> May be Kornel had a solution to several problems at once: replace @doc >>> with @body? >> >> I wrestled with this for several days, but in the end I decided that the >> proposal I put into the spec should start with no XML magic, so in XHTML, >> the attribute takes an XML string, with no implied elements or namespace >> prefixes. This was mostly predicated on the following reasoning: >> >> * XML people tend to not like magic, so if you're using XML, you're >> likely to want to see everything explicitly anyway, so saving a few >> bytes by removing the boilerplate doesn't win over many authors, >> unlike in the text/html case. >> >> * You don't really save that many bytes anyway after compression, since >> the repeated boilerplate would compress really well. >> >> * Not implying anything means that CMSes don't have to cut things out, >> with the various dangers that that implies -- they can just embed the >> content directly in. It is presumed that anyone using XML as an output >> format that contains user-generated content is almost certainly using >> lots an lots of support tools, such that they wouldn't see the >> verbosity anyway. >> >> * Not having magic going on means that there's no artificial barrier to >> using non-XHTML vocabularies like SVG. >> >> Given this, I decided to stick with "doc" in the proposal, rather than use >> "body", since in XML it wouldn't be body-specific. (I then added the "src" >> prefix to make it clearer that it was related to "src".) >> >> >>> >> Would the code iniside @doc be validated? >>> >>> I meant by validators. >> >> Yes, at least in theory. >> >> >>> And in that regard: You and Boris discussed the similarity with data >>> URIs. And it was said that quotes inside @doc would have to be escaped. >>> But what kind of escaping? >> >> " >> >> >> On Mon, 18 Jan 2010, Henri Sivonen wrote: >>> 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. >> >> I agree that it makes the transition worse, but one supposed that if >> someone is trying to transition from HTML to XHTML, they would want to do >> so wherever they use HTML. Otherwise, what's the point? >> >> >>> 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. >> >> It's bad that you have to revise your markup throughout the document, >> everywhere in your CMS, in your template files, and in any content encoded >> in your database, too, but that's what transitioning to a different markup >> language _means_. I don't really understand why you would use XHTML if you >> didn't want to use it everywhere. >> >> >>> As a general principle, I think new stuff that depends on the HTMLness >>> bit shouldn't be introduced. >> >> In general I agree, but when the "new stuff" is whether something is >> parsed as HTML or not, it seems to be a valid exception. >> >> >>> > * 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? >> >> Pretty much everything to do with XML in HTML5 falls into the "theoretical >> purity bucket". However, since people are going to walk down that path >> with or without us, it seems best for us to at least contain the possible >> damage by making it all self-contained. >> >> >>> > * 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='...'. >> >> As theoretical as the problem is, we should still do things the right way. >> It would be bad to allow a situation in which you can have a conforming >> XHTML document that cannot be rendered by a conforming XHTML processor. >> >> >>> 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. >> >> The difference is that loading HTML into an XHTML page in an XHTML-only UA >> is the same as loading DocBook into an HTML page in an HTML-only UA. (Or >> indeed, as loading XHTML into an HTML-only UA.) It's a situation the user >> understands: there's content that the UA doesn't support. But loading an >> XHTML page that relies on an optional-to-implement feature leads to >> content that -- to the user -- looks like it _should_ work not working. >> >> Anyway, as you say, this is all academic, so let's not spend more time on it. >> >> >> On Sun, 17 Jan 2010, Lachlan Hunt wrote: >>> >>> One big disadvantage with putting markup in attributes, especially for >>> the doc proposal, is that ampersands will often have to be double >>> escaped as &amp;, due to the content of doc effectively being parsed >>> twice - once as the content of the attribute, and then again to parse >>> the string as a document. >>> >>> e.g. >>> >>> Consider marking up a link containing this URL: >>> >>> ?name=foo&title=bar§=1 >>> >>> By only escaping the ampersands once like this, the following happens: >>> >>> <iframe doc="<a href="?name=foo&title=bar&sect=1">link</a>"> >>> >>> The & entites are decoded as they parsed the first time to obtain the >>> attribute value. This results in the following string: >>> >>> "<a href="?name=foo&title=bar§=1">link</a>" >>> >>> This is then parsed again by a new instance of the HTML parser, which results >>> in the first ampersand being flagged as a parse error, and the second being >>> interperted as §. This is then equivalent to the following: >>> >>> <a href="?name=foo&title=bar§=1">link</a> >> >> Indeed, if you forget to escape the &s in the user input you get >> weirdness. I actually forgot to escape one in the spec, since of course I >> have an example like the above in the markup of the spec, so it has to be >> escaped a third time, leading to an amusing "&amp;amp;" now that I've >> done it right (I think). >> >> >>> The parse error might be deemed acceptable in text/html because it's >>> non-fatal and ends up with the correct result, even though it would be >>> non-conforming, but the latter misinterpretation would break the link. >> >> Right. >> >> >>> But for XHTML, it gets worse, because the first ampersand would be >>> fatal. There are also other similar problems that would be caused by >>> using < isntead of double escaping it as &lt;. >> >> Yup. >> >> If the content is being generated by a CMS, then the first level of >> escaping will have to be done earlier, it's not like you escape them twice >> in a row. In fact, typically the first escapes will be done by hand (if at >> all) by the site user. The second &-escaping would be done by the same >> code as the "-escaping. >> >> >> On Mon, 18 Jan 2010, Boris Zbarsky wrote: >>> >>> For what it's worth, my personal preference is that the @doc be >>> parsed/loaded asynchronously, just like @src would be. At least in >>> Gecko's case we could actually pretty much reuse our normal pageload >>> code, with just a small shim to create a "network load" that feeds in >>> the @doc data, to implement that. I can't speak to other >>> implementations. >> >> I've specced it as a navigation, which is always async. (Except for >> about:blank, but I will probably just that in the coming week anyway.) >> >> >> On Mon, 18 Jan 2010, Boris Zbarsky wrote: >>> > >>> > This is more or less what I had in mind, except that I would blow away >>> > the old browsing context and create a new one, rather than navigating >>> > the previous one. I believe this is what happens with setting src="", >>> > too. >>> >>> I'm not sure what the distinction is here... Can you point me to the >>> relevant spec sections? >> >> Nevermind what I wrote there. I didn't do it. There's one browsing context >> and it gets navigated whenever relevant. >> >> >>> > Unless someone can indicate a reason why not to do this, I expect that >>> > I'll make about:blank asynchronous, and only make initial browsing >>> > context creation synchronous (like it already is -- this doesn't >>> > involve actually loading about:blank using the regular "navigation" >>> > steps). >>> >>> That sounds probably fine to me, depending on when loads of about:blank >>> are triggered by the UA and when they aren't. >> >> Not sure what you mean by "triggered by the UA". I'm proposing all >> about:blank loads would be async except for the very first load in a >> browsing context, which is _always_ about:blank (though that is often >> immediately replaced by another resource), and is always synchronous. But >> let's discuss this later this week in the other thread. :-) >> >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Sunday, 24 January 2010 14:56:47 UTC