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

[Boris Zbarsky]

On 4/7/13 9:52 PM, Ian Hickson 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

No, because browsers have these things called "caches" and are known to 
use them.

> URLs of Documents that have been document.write()n or otherwise
> modified dynamically

Yes.

> URLs of Documents that have been generated by
> POST

No, see "caches" (though you do need more state than just a URI in this 
case, admittedly)..

> or that have no-cache headers after the network has been lost

See "caches"; Gecko allows the UI to do a forced load from cache, 
ignoring such headers.

> Nothing requires those features to be equivalent to window.open(location)

And yet in practice they are (not quite, but in the end similar).  So 
the question is whether we should make that work or whether we just 
break it and expect all existing UAs and UA extensions to update.

> This is obviously non-trivial

And hence won't happen for what some will argue is a niche feature in 
the first place.

Your argument seems to come down to "it's already slightly broken in 
rare cases, so it doesn't matter if we break it completely in what we 
hope will become the common case", honestly.  Maybe you even believe 
that this is a reasonable approach...

-Boris