W3C home > Mailing lists > Public > public-html@w3.org > April 2014

Re: iframe@srcdoc

From: Andry Rendy <master.skywalker.88@gmail.com>
Date: Sat, 5 Apr 2014 21:48:56 +0200
Message-ID: <CAGxST9k2Xv0rgr01oBjx-DwnOYi-BR8BxxL_aLxQUqdGvLK7QA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-html@w3.org
The problem with document.write() seems the most serious, as no viable way
to check whether a document has been defined via script. Just checking the
src attribute is not that difficult and I suppose that if authors use
scripts in order to change them dynamically, they will willingly accept
that some content in the form of initial (elaborated) content is shown if
the script itself fail. As of now the content is practically unused and I
think that it's a sort of a theoretical failure (an element with content,
as opposed to void elements, has one more resource to exploit).
Anyway, be it used without src attribute or not, I bet that if someone
seriously proposes this idea not only to the WHATWG but especially to the
W3 spec authors, it will be clear that authors would willingly adapt to use
this feature rather than @srcdoc. Or otherwise there could be a new boolean
attribute which instructs the browser to use the content nodes as initial
content for the embedded resource. But someone should really try, I'm not
of the idea that only one voice would be heard for a so significant yet
useful change.


2014-04-05 18:31 GMT+02:00 Boris Zbarsky <bzbarsky@mit.edu>:

> 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 19:49:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:38 UTC