Re: [Edbrowse-dev] thoughts on frames

[Kevin Carhart <kevin@carhart.net>]

Hi Karl

One observation I have is that I think find & fix and the spec-based 
approach have converged.  The javascript in the acidtests.org page is a 
long series of scenarios to work on and fix.  And this is a good thing, I 
think, because (a) you know that there will be bang for the buck in the 
time you spend on something, since they have hand-designed the scenarios 
based on what they exemplify.  And (b) the writing style of this code is 
very human.  It's indented, it's commented, the variable naming has a 
cleanness to it and doesn't have variables like 'a', 'b', 'c'.  So I think 
acid3 and find&fix are basically the same thing, even if the scenarios we 
wanted to investigate are not the ones about frames.

On frames in particular, if there's an impasse, there's an impasse.. if 
you don't know how to write it, I seriously doubt that I do.

But, do you think there is any subset of these situations which might only 
live on the JS side and then be discarded?  For instance, suppose a frame 
is used as temporary storage, or in order to do a Towers of Hammurabi 
manuever and put your interconnected nodes down in a frame, to rearrange 
them and put them back in the main document.

Is this worth pursuing?  I can't quite tell what the example in acid3 is 
trying to exemplify, but I think 'doc', the side document that is defined 
as

var doc = iframe.contentDocument;

is only intratest.  It produces a pass/fail result and so doc doesn't have 
to create side effects.  Maybe later in another scenario it does, but we 
can try to deal with this test and then take it from there.

Kevin




On Mon, 27 Feb 2017, Karl Dahlke wrote:

> This is way to long for the irc.
>
> I am both optimistic and pessimistic about frames.
>
> Version 1 allows you to expand a frame inline, instead of the g command that expands it in a new buffer.
> It works, pretty much. Browse jsrt and look at line 4.
> Expand it with the exp command.
> (Contract not yet implemented.)
> So far so good.
>
> Still problems though, a frame in space.com causes a seg fault when I expand it.
> So still bugs to fix.
>
> When finished, version 1 will allow expand and contract of frames inside a window, which is neat,
> and worth doing I suppose, but it will not make a single website accessible to us that is not already accessible.
> No progress there.
>
> Version 2 might let the js worlds interact.
> The window can see the js objects in the frames etc.
> I have no clue, no flippin clue, how to do that.
> I'm sure it's a lota lota work, and I believe it would gain us almost nothing.
> One more acid3 test would pass, but I think very few websites do that, or need that functionality.
> Frames tend to be independent ads, or videos, and that's it.
> Rather, the vast majority of inaccessible websites will be brought into the fold by Kevin's find&fix work.
> That's where the real world problems are.
> That's where the rubber meets the road.
> That's what I believe anyways.
> So I will get frames version 1 working, but not sure if or when I will get round to frames version 2.
> I don't think it's a lot of bang for the buck.
> As always, I welcome opposing points of view.
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists