Re: [selectors] What is the order of evaluation of :matches() and :not()?

On 8/28/14, 6:08 PM, Benjamin Poulain wrote:
> It would be a bit long to explain the details here, the best is probably for you to read a bit the styling code of an opensource web engine like Gecko, Webkit, blink, etc to learn more.

Thank you.  I needed the laugh.  ;)

> I could find a little introductory article here, that may help:

Sounds pretty familiar, yes.  In fact, come to think of it, according to 
I reviewed that change to Gecko.

> <style>
> :matches(:visited, a) {
>      display:block;
>      width: 100px;
>      height: 100px;
>      background-color: red
> }
> </style>
> <a href=“”>link</a>
> If only the first one is match, we are in the “visited” case, and none of the properties apply.

If a UA does that, it's broken and needs to be fixed.  In particular, if 
it short-circuits like that, then you get different performance between 
the visited and unvisited cases so you open yourself up to timing 
attacks.  I filed 
on this timing issue in Gecko.

To your main point, in Gecko, with :-moz-any (which is our current 
prefixed implementation of :matches) the rendering problem you describe 
does not occur.  David's article actually explains why it does not 
occur, but I'll summarize:

In Gecko, for every link, we compute its style as if it were visited and 
also its style as if it were not visited.  Then at rendering time, for a 
short list of properties, we consult the as-if-visited style if the link 
is in fact visited, and the as-if-unvisited style otherwise.  The 
restriction of which properties can be set via :visited is effectively 
implemented in the "short list of properties" part of this setup.

In your testcase, the two computed styles end up identical, so it 
doesn't matter which style is consulted for a given property, since both 
return the same values.


Received on Thursday, 28 August 2014 23:56:11 UTC