[PATCH] various nodeAtPoint() fixes
Germain Garand
germain at ebooksfrance.com
Mon Jul 15 07:04:53 BST 2002
Le Samedi 13 Juillet 2002 19:19, Dirk Mueller a écrit :
[..]
> > - 1°: relative coordinates change don't propagate recursively to
> > childrens. (I posted this last week on kfm-devel but noone replied so
> > it's still pending)
>
> Yes, this was partly intended. I think I remember an interaction with
> absolute positioned containers in relative positioned parents.
I've tried to do something like that here :
http://www.phoenix-library.org/germain/testcases/bug_khtml_abs_child_in_rel_parent.html
Oddly enough, in such a case, the absolute translation is not rendered, but
nodeAtPoint() still think the link is were it should be : in the small golden
box.
>
> Personally i think khtml is behaving correct in this case, although it is
> very annoying for the example page you mentioned (I've spend some hours on
> that page already)
>
Frankly I think not... I've been haunted all the WE by that...
I'll elaborate, still on the http://www.w3.org/Style/CSS/ example :
When you hover the invisibly covered part of "What's New ?", the innermost
node is indeed, formally, <P>.
But how is it that the tree walking continues and finally elects "What's New"
as a good candidate for the hand cursor ?
From the formal point of view, the search should stop at <P>...
A striking illustration of that is when you hover "nearby" in the fixed menu.
Should we really get "What's New"'s hand cursor ?
What I want to advocate here is : there is a need to distinguish between two
kind of inner nodes :
- formal ones ("P" is indeed the innermost node, may it be invisible or
opaque) [owner: innerNode]
- visual ones ( for human sight, the innermost node is the "A" tag. If "P" was
overriding something on "A", it would be "P") [owner: visualNode]
In fact, khtml already does this distinction with URLElement, since it can be
different from the innerNode (too bad it's only for URLs).
I've implemented roughly such a mechanism in the attached patch,
and it looks promizing...
For instance, try comparing the behaviour on this slightly modified version :
http://www.phoenix-library.org/germain/testcases/www.w3.org/Style/CSS/
Anyway, feel free to have a look or simply throw it to the overcrowded Hell of
Lame ! ;-)
Germain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_object.patch
Type: text/x-diff
Size: 5065 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20020715/f0a5c19c/attachment.patch>
More information about the kfm-devel
mailing list