* [Edbrowse-dev] hover
@ 2018-02-22 18:54 Karl Dahlke
2018-02-23 5:47 ` [Edbrowse-dev] return value from removeChild Kevin Carhart
0 siblings, 1 reply; 4+ messages in thread
From: Karl Dahlke @ 2018-02-22 18:54 UTC (permalink / raw)
To: Edbrowse-dev
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Edbrowse-dev] return value from removeChild
2018-02-22 18:54 [Edbrowse-dev] hover Karl Dahlke
@ 2018-02-23 5:47 ` Kevin Carhart
2018-02-23 6:05 ` Karl Dahlke
0 siblings, 1 reply; 4+ messages in thread
From: Kevin Carhart @ 2018-02-23 5:47 UTC (permalink / raw)
To: Edbrowse-dev
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-02-23 6:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-22 18:54 [Edbrowse-dev] hover Karl Dahlke
2018-02-23 5:47 ` [Edbrowse-dev] return value from removeChild Kevin Carhart
2018-02-23 6:05 ` Karl Dahlke
2018-02-23 6:17 ` Kevin Carhart
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).