Rule matching oddness with new CSS parser

[David Hyatt]

Yes.  You need the hover/active changes from Safari for them to work 
(changes to recalcStyle and to how hover/active are matched).  I also 
added an optimization for detecting descendant rules so that 
recalcStyle can stay fast.  That involved touching the parser though, 
but I have moved those changes over to the new CSS parser.

dave

On Sunday, February 23, 2003, at 11:19 PM, Lars Knoll wrote:

> You're right. Thanks for catching this one. I submitted it now to our 
> CVS
> aswell. I do however still see some problems with the CSS menues on 
> meyerwebs
> CSS/edge sites. Do they work correctly for you?
>
> Lars
>
>
>> Ok, this behavior exactly matches the old parser (and all my test 
>> cases
>> finally pass, yay!).
>>
>> The old parser chains the sub-selectors inside simple selectors from
>> left to right.  It then hands back the leftmost subselector.  This
>> production matches that behavior:
>>
>> specifier_list specifier {
>> 	$$ = $1;
>>          CSSSelector *end = $1;
>>          while( end->tagHistory )
>>              end = end->tagHistory;
>>          end->relation = CSSSelector::SubSelector;
>>          end->tagHistory = $2;
>>      }
>>
>> For complex selectors the old parser chained the simple selectors from
>> right to left.  The rightmost link in a simple selector would point to
>> the leftmost link in the next simple selector.  This production 
>> matches
>> that behavior.
>>
>> selector combinator simple_selector {
>>      	$$ = $3;
>>          CSSSelector *end = $3;
>>          while( end->tagHistory )
>>              end = end->tagHistory;
>> 	end->relation = $2;
>> 	end->tagHistory = $1;
>>      }
>>
>> dave
>> (hyatt@apple.com)
>>
>> _______________________________________________
>> Khtml-devel@mail.kde.org
>> http://mail.kde.org/mailman/listinfo/khtml-devel
>
> _______________________________________________
> Khtml-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/khtml-devel