[whatwg] <iframe srcdoc> definition not compatible with existing user-agent user interfaces

[Ian Hickson]

On Thu, 4 Apr 2013, Boris Zbarsky wrote:
>
> The way <iframe srcdoc> is defined, the document URI does not in any way 
> encode the document contents.

This is the same as HTTP URLs where the server returns different content 
each time, URLs of Documents that have been document.write()n or otherwise 
modified dynamically, URLs of Documents that have been generated by 
POSTs or that have no-cache headers after the network has been lost, etc.


> Unfortunately, that breaks user-agent and extension features like "open 
> frame in new window", "show only this frame", "open frame in new tab", 
> etc.

No, those features are broken because they're poorly implemented, IMHO.

Nothing requires those features to be equivalent to window.open(location), 
which is more or less how they are implemented today. Such an 
implementation would fail with all the cases I listed above, just like 
"View Source" used to fail for those cases in many browsers back when it 
was implemented more or less as window.open("view-source:"+location).

"Show only this frame" can be implemented by "just" adjusting the 
presentation so that the selected frame fills the top-level viewport; this 
will also ensure that the page itself can't detect the situation (or to 
put it another way, to ensure that pages that don't check for this, which 
is basically all of them, keep working as if the subframe was still a 
subframe). This is obviously non-trivial, requiring such things as 
handling session history navigation when the user then navigates the frame 
as if it was a top-level navigation rather than navigating the promoted 
subframe, and handling going back to the promoted subframe or to the state 
before it was promoted (a presentation change), etc.

The "Open frame in new..." options are more complicated, because you can't 
use the same Document since it has to remain in the old presentation as 
well at the same time. But a solution like cloning the DOM would be a 
start, possibly, for cases where the original source can't be obtained 
(e.g. a POST result); for cases where the original data can still be 
obtained (as is the case for anything where "view source" works), the page 
can maybe be reconstructed from source.

In any case, the URL isn't the issue here. Reopening the page from its URL 
isn't a correct implementation of these features.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'