- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 05 Apr 2014 12:31:24 -0400
- To: Andry Rendy <master.skywalker.88@gmail.com>
- CC: public-html@w3.org
On 4/5/14 5:56 AM, Andry Rendy wrote:
> This indeed doesn't change my consideration about the relationship
> between src attribute and content. My proposal is to give visibility to
> the content as far as no src attribute is set. Of course if scripts
> modify the element by setting a src attribute, the content will be
> hidden as per precedence rule.
Yes, but it will show until the src is set, which is a
backwards-incompatible change from current behavior.
> IDK about document.write() and how it can
> be used in order to change the embedded content (I think that you
> referred to that when you say "get content inserted into them").
Like this:
<iframe id="x">Fallback content</iframe>
<script>
document.getElementById("x").contentDocument.open();
document.getElementById("x").contentDocument.write("Hey");
document.getElementById("x").contentDocument.close();
</script>
> It wouldn't, actually. Suppose that the content of the iframe element is
> actually shown only when a src is not set (this means that when a src is
> set either via script or via a hyperlink targeting the current frame,
> this document "hides" the content).
That's a backwards-incompatible change, as I said above.
> All novelties require changes in the specifications.
While true, the question is how extensive the changes are and how much
they affect the behavior of existing content.
> As of october 2013 no pages in a statistically significant cross-section provided by
> WebDevData used @srcdoc, maybe the reason is that such attribute is
> highly impractical
That's possible.
An alternative explanation is that the first version of Firefox to
support @srcdoc was Firefox 25, which shipped on October 29, 2013, and
that there is no shipping version of IE that supports @srcdoc.
This is not to say that @srcdoc is not a pain to use. I agree that it is.
-Boris
Received on Saturday, 5 April 2014 16:31:54 UTC