
Let's build a browser engine, Part 4: Style - mbrubeck
http://limpet.net/mbrubeck/2014/08/25/toy-layout-engine-4-style.html
======
userbinator
CSS matching is one of the more resource-intensive parts of the computation
the browsers do; the given implementation is very instructive for
understanding the algorithm, but would be too slow for any nontrivial page.
The total possible number of comparisons is basically {number of rules} *
{number of elements}, which can be extremely high, and avoiding this is quite
important.

I am reminded of how IE uses a single integer to identify each CSS rule:
[http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164...](http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164546.aspx)

~~~
jnbiche
Interesting. So is that typically the reason why pages with large number of
elements are so slow? I had always assumed it was the HTML elements
themselves, but could the bottleneck here sometimes be the CSS matching of
those elements?

Also, if I'm not mistaken, I believe that Servo (which the author of this post
works on at Mozilla) is attempting some novel parallel CSS matching using
Rust's support for parallelism/concurrency.

