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

On Mon, 8 Apr 2013, Boris Zbarsky wrote:
> On 4/8/13 1:20 AM, Ian Hickson wrote:
> > If a browser can cache the data for a frame based on which frame it is 
> > rather than just its URL
> 
> In Gecko's case, say, it's cached based on URL and a sequence number (to 
> handle POST).

Why does the test I posted fail, then?

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

Right-click either frame, and make it display the frame elsewhere (new 
tab, only-this-frame, even view-source is broken on this test in Gecko). 
The new page that's shown is different than the one the user interacted 
with.

This isn't academic, it breaks any case where a frame's contents are 
dynamically generated. For example, an ad system that just uses an iframe 
and generates an appropriate ad each time would open a different ad if you 
were to right-click on it and open the iframe in a new tab.


> > > 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.
> 
> Sure, but the spec currently picks the second one of those two options, 
> fwiw.

No. The current spec doesn't even mention these features. It doesn't pick 
anything. Implementing them based on URLs doesn't work in all cases, even 
before srcdoc="" was introduced.

If you were to implement a "multiply by two" feature by simply shifting 
the input's first byte left by one bit, then it would work great for 
numbers up to 128. It would fail for numbers greater than that. The 
solution is not "well, we should make sure all numbers are less than 128", 
or "this solution works fine for most numbers that people actually come 
across". The solution is to use an algorithm that works all the time.

This is a quality-of-implementation issue. There's nothing in the spec 
that means that these features have to use URLs; using URLs is ok for a 
first approximation but it doesn't handle all the cases (even ignoring 
srcdoc). The better implementations would work in all cases (including 
the example above and srcdoc). The less good implementations would not 
work in all cases, or maybe won't offer the feature at all (e.g. Chrome, 
as far as I can tell).

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

Received on Monday, 8 April 2013 22:57:30 UTC