Re: iframe@srcdoc

Here I am again. I tested how browsers treat iframes and I noticed that the
src attribute is not updated when the iframe itself is navigated. So
there's no real need of a specific src value as keyword. It would end up
being a useless complication, also because it should be evaluated with
regard to the base URI of the document, and invoking it during navigation
is not reflected by the attribute.
If you follow me, what is needed is an attribute which remains there
(unless removed via script, but in that case it should not change the
behaviour of the iframe unless it is navigated, the same that happens with
sandbox attribute). It should be a boolean attribute, which, once present,
allows the iframe element to behave as a transparent container element (it
must be considered whether dimensiona attributes should affect it in this
case or not, but I think so). The content inside, both in form of
hyperlink, or form, or script, must be run inside the context created by
the parent iframe element, but the content elements themselves should
belong to the current document. Even if it is an extra-ordinary way to
execute script and determine the target for hyperlinks, I think it can be
done by a user agent without great effort. This kind of document would be
part of the nested browsing context history, so it could be retrieved by
going back to the first history entry for the context. And the presence of
the attribute itself should take precedence over the src attribute, as
defined now for srcdoc.
A final consideration about eventual backward compatibility: such a feature
would be a security problem (if any) in XHTML user agents only, because
HTML parser currently ignores the content of iframe elements. So authors
wishing to exploit this possibility should work out a script solution which
I don't think is too difficult. All the problem would come from script
elements executed as content of iframe elements in XHTML user agents (as
XHTML ignores special behaviours for HTML elements, scripts are run
nonetheless). But authors who exploit this will surely find an alternative,
because it's a matter of security for their users in case of protecting
user-submitted content (if it were THEIR content, a malicious author can
insert script elements inside iframes already now, and they would be
interpreted although invalid). I don't think that the content should be
different in HTML and XHTML documents, on the contrary these two languages
should converge as far as possible.
Please consider this proposal seriously.


2014-04-05 21:48 GMT+02:00 Andry Rendy <master.skywalker.88@gmail.com>:

> 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
>>
>
>