- From: Barry van Oudtshoorn <bvanoudtshoorn@gmail.com>
- Date: Fri, 7 Oct 2011 21:21:48 +0800
- To: www-style@w3.org
- Message-ID: <CAFsVuTOdcHFScsd=fRBVbCsohig2ZhcnfDXoWpKqcmi9swaYkw@mail.gmail.com>
On Fri, Oct 7, 2011 at 9:15 PM, David Woolley <forums@david-woolley.me.uk>wrote: > Roland Steiner wrote: > > >> My main question in all of this is: has anyone thought about how to >> actually implement this without a) traversing the whole tree twice (once to >> set selected styles, once to do inheritance), or b) do a full subtree search >> every time on matching :has()? Additionally, how to handle updating of nodes >> - it seems ANY node could be affected by changes ANYWHERE in the DOM. >> > > That was essentially why this feature was rejected many years ago, and > probably has been rejected several times since. The other problem is > indefinite lookahead. You are more or less forced to render then backtrack, > because there are some pages that never actually terminate, but grow with > the addition of real time data. > > (My experience also, is that most things that keep being proposed and > rejected, eventually get accepted!) > Could this be aided by restricting the set of combinators available? For example, only allowing direct children and (in)direct siblings would probably reduce the possibilities for this to cause serious problems. This is a pattern that I've used quite a bit in selecting elements in JavaScript, so perhaps user agents could allow the full set of combinators in, for example, document.querySelectorAll, and use a restricted set for the application of CSS styles. -- Barry van Oudtshoorn http://barryvan.com.au/ bvanoudtshoorn@gmail.com
Received on Friday, 7 October 2011 13:22:27 UTC