edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [Edbrowse-dev] $kids$
@ 2015-01-13 12:33 Karl Dahlke
  0 siblings, 0 replies; only message in thread
From: Karl Dahlke @ 2015-01-13 12:33 UTC (permalink / raw)
  To: Edbrowse-dev

As you know, an html tag like <form> generates a corresponding object
in the js world, but for the most part,
these were disconnected and isolated objects.
In reality, the tags between <form> and </form>, and not between other nested
tags, are the children of <form>,
and their objects should be children of the form object.
I've taken a step towards this.
Many html tags, not all of them, maybe should be all of them,
or maybe not, like <br> which has no closing </br>,
anyways, many of the tags now generate a js object and an array
beneath called $kids$.
This array holds the objects for the tags between <foo> and </foo>.
Finally we begin to build the js tree corresponding to the html.
And functions like appendchild and insertBefore make sense,
since there is a tree for them to work within.

There was a choice in implementing appendChild.
I could write the function once and then add it to every node object created,
write it natively in C as a method to each of the dozen classes
of html tags, or make it a prototype for each of the html tag classes.
The first seems error prone, trying to remember to add that function
to each instantiated object after the fact,
and the second is truly ugly because it lives in the js world,
which will depend on the js library we are using,
or even the version of that library.
I'm trying to keep jseng.cpp as small as possible.
It shouldn't have dom stuff in it.
So I chose the third, prototypes in startwindow.js.
And it's realy easy!
form.prototype.appendChild just pushes its object onto this.$kids$.
It's maybe one or two lines of code.

Now I'm hoping more websites will work, sort of.
That is, they won't error out.
But if js really starts creating new html objects,
new tables and paragraphs and anchors and sections,
we won't see them because the modified js tree is not rerendered.
This is something I probably can't do in increments.
"Gee, we added a button to the form, let's see where I need
to paste that into the existing edbrowse buffer."
I'm already doing too much of that.
No - this will have to wait until we, as a matter of course,
rerender the tree after each js operation and compare the new
text buffer with the old to see what has changed.
But anyways, $kids$ is a start.

Karl Dahlke

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

only message in thread, other threads:[~2015-01-13 12:36 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-13 12:33 [Edbrowse-dev] $kids$ 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).