Rule matching oddness with new CSS parser

[David Hyatt]

I found it.  tagHistory/relation weren't getting set up in a proper 
right-to-left chain... here are the relevant altered productions:

selector combinator simple_selector {
     	$$ = $3;
         CSSSelector *end = $3;
         while( end->tagHistory )
             end = end->tagHistory;
	end->relation = $2;
	end->tagHistory = $1;
     }

*and*

specifier_list specifier {
	$$ = $2;
	$$->nonCSSHint = static_cast<CSSParser *>(parser)->nonCSSHint;
	$$->relation = CSSSelector::SubSelector;
	$$->tagHistory = $1;
     }

I made the specifier_list production return the rightmost selector.  
This made right to left chaining easy for the simple selectors and 
causes the tag to be set on the rightmost selector, which should make 
rule matching more efficient, since the tag will be checked at the 
first sub-selector you encounter (instead of the last).

For the production with the combinator, I walk up the tag history of 
the simple selector to get to the leftmost portion of the simple 
selector and then I chain it to the rightmost end of the selector.

This fixes all the bugs on meyerweb.

dave
(hyatt@apple.com)

On Friday, February 21, 2003, at 07:23 AM, Lars Knoll wrote:

>
>>> On Fre, 21 Feb 2003, David Hyatt wrote:
>>>> In Safari with the new parser, the following rule matches the <a> 
>>>> even
>>>> when :hover is not set.  Can someone confirm if this happens on the
>>>> KHTML HEAD?
>>>
>>> Yes, a very bad time to check out the new parser. Its completely 
>>> busted
>>> today. Use yesterdays version, this one works fine. Todays doesn't 
>>> even
>>> render www.google.com anymore.
>>
>> Working on it right now.
>
> Ok, I think (hope) I fixed all issues. The parser should now work as 
> before
> for non namespaced CSS.
>
> Lars
>
> _______________________________________________
> Khtml-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/khtml-devel