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
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
