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

[Ian Hickson]

On Sun, 7 Apr 2013, Boris Zbarsky wrote:
> 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.

If a browser can cache the data for a frame based on which frame it is 
rather than just its URL, then I don't see why it couldn't do that for a 
srcdoc="" frame as well. Really there's no difference between srcdoc="" 
and an HTTP URL that happens to return unique data each time.

   http://damowmow.com/playground/demos/ui/001.html


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

If it can be made to work for POST, I don't see why srcdoc="" would be any 
harder. Just treat it the same way.


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

I don't think those are the only options.


> > This is obviously non-trivial
> 
> And hence won't happen for what some will argue is a niche feature in 
> the first place.

Well, as Rob said, arguably the mentioned UIs don't really apply here 
anyway, so maybe they should just not be shown.

Note that nothing in the spec mentions these UI features at all, as far 
as I'm aware. UAs are welcome to show all kinds of features like this, and 
how well they work is a quality of implementation issue.


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

I'm a fan of building things to handle all the known cases, not just most 
of them and "oh well if they break in those edge cases sorry". These 
features are easy to demonstrate as being broken, and they're broken in 
way that affect me regularly (especially when doing Web development work). 
I don't think it's unreasonable to make them work, and I don't see why 
it'd be any harder to make them work for srcdoc="" than anything else 
(such as the case shown in the URL at the top of this e-mail). 
Fundamentally, these features should have nothing to do with URLs.

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