[PATCH] various nodeAtPoint() fixes

[Dirk Mueller]

On Mon, 15 Jul 2002, Germain Garand wrote:


> 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.

Its the other way around. the rendering is right. I seem to have found a fix 
which doesn't break any of my testcases and makes sense and even fixes this 
one :-)

> 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).

well, the way IE solves it is by respecting only A elements in HTML. I don't 
consider that right either. 

> 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 ! ;-)

I'll test your patch. 



-- 
Dirk (received 1969 mails today)