- From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
- Date: Fri, 25 May 2012 19:08:02 +0400
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: "www-style@w3.org" <www-style@w3.org>
Thanks, Boris, I understand this. It's just a side note about the existing vendors' efforts that make long selectors fast enough to not consider them as _blocker_ for positive changes in CSS in whole. 25.05.2012, 18:57, "Boris Zbarsky" <bzbarsky@MIT.EDU>: > On 5/25/12 10:25 AM, Marat Tanalin | tanalin.com wrote: > >> šBTW, browser vendors (WebKit [2], Mozilla [3]) already take steps to make selectors much faster and, in most cases, independent from how long selector is. > > There's no free lunch. > > The optimizations you link to have a nontrivial memory cost, and worse > yet make it much harder to perform selector matching in a parallelizable > manner (because it becomes stateful). > > UAs are sort of forced to do them because sites are using descendant > combinators willy nilly (not least because CSS preprocessors output them > all over the place)... > > Long selector chains can still cause performance issues when trying to > handle dynamic changes, by the way, where the optimizations you link to > don't apply right now. > > -Boris
Received on Friday, 25 May 2012 15:10:38 UTC