edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [Edbrowse-dev] frames
@ 2014-04-16 17:01 Karl Dahlke
  0 siblings, 0 replies; only message in thread
From: Karl Dahlke @ 2014-04-16 17:01 UTC (permalink / raw)
  To: Edbrowse-dev

There is another fundamental change in our future.
The tag <frame> or <iframe> (not entirely sure of the difference)
pulls another html page into the current page,
kind of like #include.
Some ten years ago I polled my users and asked them how I should handle this.
(There weren't very many users at that time, probably less than 10.)
They all agreed; just turn each frame into a hyperlink.
If you want to see that subpage then click on it.
If you want to keep that subpage up and go back then use the M command.
You can spread out all the frames in separate buffers if you wish.
Great, that's easy!
And so it has been for a decade.
But no other browser does that.
All the frames expand and knit together into one
seamless page, and the user doesn't even know
that parts of what he is seeing come from different websites.

So what would it take for us to do that?
In the middle of browsing, I run into a <frame> tag,
and I have to suspend browsing, fetch a new web page,
browse that inline,
then return to the browsing I was doing before.
The new web page needs a new java context for its js,
but I don't have a new buffer to put it in.
Or can it use the same js context?
And I have to remember that in this buffer, lines 374 through 729
actually belong to some other web page with some other url.
And all that browsing code has to be recursive / reentrant, which it probably isn't.
We're talking about some major changes here.

The thing is, if we don't do that, and even if we do all the
other dom rewrites we're talking about, some websites still won't work.
amazon might be one of them.
They bring in all these different pages by frames, and js code reads and modifies
variables in the other windows.
In other words, all the windows have to be up and running simultaneously,
with their own js documents and variables, because js in any one of them
might depend on and interact with the js in the other windows.
This absolutely cannot be done with today's model.

So I guess I've resigned myself to someday, perhaps version 3.5.4,
frames will expand inline and knit together into one seamless page,
like every other browser does,
and the js for these windows will interact with each other,
and as we look to that day we can all think
how to best get there.
What changes need to be made to the foundation,
e.g. js contexts and buffers etc,
to make this feasible?

Karl Dahlke

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2014-04-16 21:02 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-16 17:01 [Edbrowse-dev] frames Karl Dahlke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).