- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 20 Jul 2015 16:13:12 -0700
- To: Marat Tanalin <mtanalin@yandex.ru>
- Cc: Benjamin Poulain <benjamin@webkit.org>, Ms2ger <ms2ger@gmail.com>, Aaron Reisman <aaron@hired.com>, "www-style@w3.org" <www-style@w3.org>
On Mon, Jul 20, 2015 at 4:07 PM, Marat Tanalin <mtanalin@yandex.ru> wrote: > 21.07.2015, 00:23, "Benjamin Poulain" <benjamin@webkit.org>: >> On 7/20/15 11:38 AM, Marat Tanalin wrote: >>> 20.07.2015, 21:03, "Tab Atkins Jr." <jackalmage@gmail.com>: >>>> Such a thing would tank performance *so bad* and >>>> there's no real way to engineer around that. >>> >>> Are there test implementations and results of performance testing of such implementations? Otherwise that's just guessing. >> >> What Tab said is reasonable. Given the current implementation, there is >> no easy way out. >> >> If you come up with an algorithm that solves the problem in low-order >> polynomial time, share it with us and we can discuss implementation. > > There is the `element()` CSS function defined in the css-images-4 draft (with Tab and Elika as editors) [1] and implemented as `-moz-element()` in Firefox/Gecko [2]. The element() function is not handled in the middle of style resolution, nor does it involve looping back and forth between selector application and style resolution. The set of things it has to check for cycles are also very small (the set of element() calls), rather than every single style rule in the page. ~TJ
Received on Monday, 20 July 2015 23:13:58 UTC