[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