W3C home > Mailing lists > Public > www-style@w3.org > January 2010

Re: Proposal: @property(value) Selector

From: L. David Baron <dbaron@dbaron.org>
Date: Sun, 24 Jan 2010 21:14:39 -0800
To: www-style@w3.org
Message-ID: <20100125051439.GA21414@pickering.dbaron.org>
On Sunday 2010-01-24 19:54 -0800, Alex Mitchell wrote:
> If the property used in the @property(value) is defined inside of the
> rule, it would give a parse error and drop the rule, just as if you were
> to put an invalid value for margin or another property.

That's not sufficient, since you can have arbitrary cycles.

It's also not clear to me if you're matching on computed values or
specified values.  Both have sigificant disadvantages:

 * matching on specified values would mean that implementations
   would have to compute all specified values before computing any
   computed values; this likely has significant memory and time

 * matching on computed values would mean you'd also need to beware
   of all the computed value dependencies between properties (e.g.,
   anything taking length units depends on 'font-size', 'display'
   depends on 'float' and 'position', 'vertical-align' depends
   on 'line-height', etc.)

Either one means that the process of selector matching is no longer
a single pass, which I think has *huge* performance implications,
since selector matching is one of the most processor-intensive parts
of CSS.

I think you'd need to present strong use cases for such a selector
for it to be adopted.


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Monday, 25 January 2010 05:15:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:31 UTC