Re: iframe@srcdoc

> there are pages with content inside <iframe> and that if we started using
it that would change the behavior
> there are <iframe> elements with no src initially and child content that
get content inserted into them by later seetting @src or by using
document.write()

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. 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"). AND if you mean so, then of course the
content becomes a fallback too, as it allows to show part of the intended
content even when the user agent does not support, or fails to run, the
script which changes the content of the element.

> > or when it maps to a specific value (e.g. a document fragment matching
the ID of the current iframe
> That would work better, yes.  That's starting to make the feature a lot
more annoying to use, though, not to mention requiring a lot more changes
to specifications

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).
This means that an author wishing to show the initial content for an
iframe, builds a page, e.g. "www.example.com/forum.html" which is served
with an iframe devoid of embedded document, like this (example taken from
the spec):
<iframe sandbox="" id="report-01" name="report-01">
<p>Yeah, you can see it <a href="/gallery?mode=cover&amp;page=1">in my
gallery</a>.
</iframe>.

Now, the iframe can be navigated through the hyperlink which is part of the
content. The document found at the URL above can have a "Back" button, but
it can also simply have a link to the URL "
www.example.com/forum.html#report-01". Having a src attribute matches the
fragment identifier for the iframe itself, all it does is actually
embedding a version of the document where the src is not set (which makes
sense, as it is an initial content and we suppose that it is set because
the author wants so), and therefore which shows the content of the element.
User agents could go further and directly show the content, i.e. going
"out" of the embedded resource, but it can be resolved later or even not
resolved at all, as this mechanism works. I tried to figure out it only
because I thought that a way to recall the content in a further moment of
the life of the page could be useful, while I really believe that the
primary way to show the content of the element is when no embedded document
is set at all.
All novelties require changes in the specifications. Changes were required
to implement @srcdoc too. I think that having an initial content is useful,
yet it should also be author-friendly. 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,
more so than using the content in a wiser way.


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

> On 4/4/14 6:06 PM, Andry Rendy wrote:
>
>> I thought that someone would have answered like that, but currently
>> there are no user agents which fail to support user agents and those
>> which do, lack the support willingly
>>
>
> That doesn't matter.  What matters is that there are pages with content
> inside <iframe> and that if we started using it that would change the
> behavior of those pages in user agents that DO support iframes.
>
>
>    - the question could be resolved changing the absurd rule that initial
>> content takes precedence over embedded content: an iframe having both
>> content and a src attribute could display the embedded resource
>>
>
> I'm willing to bet money that there are <iframe> elements with no src
> initially and child content that get content inserted into them by later
> seetting @src or by using document.write()...
>
>
> > or when it maps to a specific value (e.g. a document fragment
> > matching the ID of the current iframe
>
> That would work better, yes.  That's starting to make the feature a lot
> more annoying to use, though, not to mention requiring a lot more changes
> to specifications (parsing, scripting, etc) to implement.
>
> -Boris
>
>