Hi Karl,

Maybe I do not exactly understand by constructing
the page using DOM primatives, but have built
a test2.html -
http://geoffair.org/tmp/test2.html

There the links are built using the javascript -
 var menu = document.body.appendChild( document.createElement( 'div' ) );
 var menu2 = menu.appendChild( document.createElement( 'div' ) );

And then the html is created using menu.innerHTML =, and likewise
for menu2. menu is a h2 with a link, and menu2 is a table with
4 links...

And as stated using my special DEBUG libtidy, when I browse
test2.html I see three libtidy outputs -

First
  StartTag body   onload="init();"
   StartTag h1
    Text   (5) 'test2'

Second
  StartTag body
   StartTag h2
    StartTag a   href="http://edbrowse.org/usersguide.html#guide";
     Text   (8) 'edbrowse'

Third
  StartTag body
   StartTag table
    StartTag tr
     StartTag td
      StartTag a   href="http://google.com";
       Text   (6) 'google'
     StartTag td
      StartTag a   href="http://yahoo.com";
       Text   (5) 'yahoo'
     StartTag td
      StartTag a   href="http://microsoft.com";
       Text   (9) 'microsoft'
     StartTag td
      StartTag a   href="http://edbrowse.org/usersguide.html#guide";
       Text   (8) 'edbrowse'

In browse mode, the last line is indeed those 4 links,
and the command 1,p shows me - extra blank lines removed -

test2
{edbrowse}
{google}|{yahoo}|{microsoft}|{edbrowse}

I can use g1-4 and the link is fetched... beautiful...
great... working well, I think...

And if I set db5 and redirect the output to say tempdb5.txt,
I can see similar stuff in the tempdb5.txt file, but as
you point out it is mixed with a lot of other debug
output...

What I am saying is that I do not see that in browsing
nasa... There are some 14 callbacks with html that is
passed to libtidy... there are some partial links, and
other stuff passed back... but when it is all done, I
have nothing...

Now as stated, maybe I do not quite understand
"using DOM primatives", but I think that's what my
javascript does in this test2.html, and it succeeds
in creating html fragments that are passed back to
the browser to display...

And for instance, I can read in the nasa.js, for
creating the 'footer' links - uses -
buildFragment:function(e){ ... part of which is -

var r=e.createElement("li"),l=e.createElement("a");
e.setAttribute(l,"href","http://www.nasa.gov/about/contact/index.html";);
var i=e.createTextNode("Contact NASA");
e.appendChild(l,i),e.appendChild(r,l),e.appendChild(a,r);

So I come back to why do I not see these created "li", "a"
with href shown, with text "Contact NASA", all appended...

This is certainly building the bottom 'footer' line
from the ground up... in fact ALL elements of the page
are built like this... header, content, footer...

There is no doubt the main contents of that page changes
regularly - what I see today is different to what I saw
yesterday...

So, I am still puzzled why more of the generated stuff
is not available in edbrowse...

Ok, to make sure I am not completely crazy, I constucted
a test3.html -
http://geoffair.org/tmp/test3.html
using as close as possible the javascript from nasa.js

In my chrome browser this correctly displays a
"Contact NASA" link, and it works fine... on clicking
the link shown I am taken to the desired page...

*** BUT IT TOO FAILS IN EDBROWSE!!! ***

This tends to indicate that duktape FAILS when the
var t = document.createDocumentFragment();
API is used, and that 'fragment', which has the
said link appended to it, is then appended to the
'footer' tag... or something...

So my test3 js code works in Chrome, AND Microsoft Edge,
BUT **not** in Edbrowse/duktape...

Is this it? Am I just seeing a limit in what
the chosen duktape library can do...

It should be noted I am still linking with
duktape 2.1.0, from a zip source, while it
seems the github git source indicates 2.2, or
higher -
https://github.com/svaarala/duktape/releases/tag/v2.2.0
I must get around to updating this...

That may make a difference... will do this
soonest... and I now have a very minimal test3.html
sample... but now sort of feel this is all 'outside'
edbrowse's direct control...

Regard,
Geoff.
_______________________________________________
Edbrowse-dev mailing list
Edbrowse-dev@lists.the-brannons.com
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

Reply via email to