W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: [selectors4] no way to select visible children

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 21 Jul 2015 12:10:02 -0700
Message-ID: <CAAWBYDB1Vf4EAu_WriuMavYx+E+6ZWXXCMhsKX4iuRVrR2+fwg@mail.gmail.com>
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 Tue, Jul 21, 2015 at 8:33 AM, Marat Tanalin <mtanalin@yandex.ru> wrote:
> 21.07.2015, 02:13, "Tab Atkins Jr." <jackalmage@gmail.com>:
>> On Mon, Jul 20, 2015 at 4:07 PM, Marat Tanalin <mtanalin@yandex.ru> wrote:
>>>  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.
>
> At least this is something that has an existing native implementation that really works with acceptable performance and proves that CSS-loop prevention is viable.
>
> On the contrary, statements that CSS-loop detection is slow are purely theoretical and do not have native implementations proving it so far.
>
> And, as usual, you've skipped some important parts of my message (in particular, the idea of tracking overall time of CSS processing).

I'm sorry that you feel the need to distrust statements from me
(proxying for Blink devs working on the selector engine) and Benjamin
(works on WebKit's selector engine), but I'm not going to further
engage you in this topic.  It's clear that we can't convince you
without putting in far more work than the topic deserves.

~TJ
Received on Tuesday, 21 July 2015 19:10:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC