[Edbrowse-dev] hover

[Edbrowse-dev] hover

[Karl Dahlke]

This from Geoff.

==============================

Well here the concept of 'hovering' is a bit misleading. Such dropdown
menu lists are really always there in html, they are just marked
visually 'hidden'...
That is `display: none;` in css terms. Then when you hover that is
changed to 'display: block;`...

Try browsing my example http://geoffair.org/tmp/test4.html... visually
I only 'see' Dropdown' in a browser, until I hover the mouse
over it...

And in EB I correctly see the three links... virtually ignoring
the `display: none;`, which is fine...

==============================

His little test program, derived from nasa, is important for all of us to digest and understand.

It was asked long ago if edbrowse should scan through all the css and "hide" those things with display none.
This example suggests we should not, for such things only come to light if you hover over something,
and you can't hover in edbrowse, you wouldn't even know that was a possibility, so those links would be forever lost.
This moves us towards the thing I was worried about 20 years ago when I started this;
some websites are so dog gone visual that edbrowse just won't be able to simulate them in a textual manner.
I hope I'm wrong, and we can shoehorn most websites into our model.

Karl Dahlke

[Edbrowse-dev] return value from removeChild

[Kevin Carhart]

I found some evidence that our removeChild function should return the 
removed node to javascript, instead of returning undefined

A prominent library file includes this line:

a.removeChild(b).style.display = 'none';

So it's expecting something to be there.

And MDN talks about removeChild being called in two possible ways, one of 
which returns the removed node:

var oldChild = node.removeChild(child);

"The removed child node still exists in memory, but is no longer part of 
the DOM.  With the first syntax-form shown, you may reuse the removed node 
later in your code, via the oldChild object reference."

Could this be done by renaming removeChild to eb$rmcd in jseng-duk.c, and 
then in startwindow maybe this?

mw0.removeChild = function(c) {
this.eb$rmcd(c);
return c;
}

The side effects are all nice and stable already, so leave them alone and 
just deal with the change in what is returned to JS using a JS wrapper.
If this sounds OK, I'll turn this in.

thanks
Kevin

[Edbrowse-dev] return value from removeChild

[Karl Dahlke]

> our removeChild function should return the removed node to javascript,

No need for wrappers etc, just a 2 line change in the native method.
I use to specifically pop the argument and return 0, so don't pop it and return 1.

Karl Dahlke

Re: [Edbrowse-dev] return value from removeChild

[Kevin Carhart]

rad!
thank you!



On Fri, 23 Feb 2018, Karl Dahlke wrote:

>> our removeChild function should return the removed node to javascript,
>
> No need for wrappers etc, just a 2 line change in the native method.
> I use to specifically pop the argument and return 0, so don't pop it and return 1.
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

---