W3C home > Mailing lists > Public > www-style@w3.org > August 2012

Re: Thinking about mixins as a new type of selector

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Mon, 13 Aug 2012 09:30:25 -0700
Message-ID: <CALRQH79zv1R2Xz2BUAVn5h5s2-HFhcyvwkCeHjwSNwQAdT5dkg@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: François REMY <fremycompany_pub@yahoo.fr>, www-style@w3.org
On Sun, Aug 12, 2012 at 5:35 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Sunday 2012-08-12 22:37 +0200, François REMY wrote:
>> The main issue is that this loop back. You have to resolve all
>> matching rules to know what the value of "matches" is, but then you
>> have to rematch again, which may changes the value of "matches"
>> again. Potentially, this can become an inifinite loop.
>
> So the 'matches' wasn't intended to be a normal property:  the idea
> was that it would be additive rather than cascading/overriding; I
> think Tab's @-rule syntax might be better.
>
> (I actually started writing the email hoping to post no syntax at
> all, but couldn't figure out an easy way to do so.)
>

Ah, ok.

We have two processing options for such features in principle:

So called @const - C pre-processor kind of parsing.
"@const name tokens;" declaration is a named sequence of parsed
tokens that gets injected at @name; location.

And run-time @var name single-value; thing. It gets parsed into the value
and used as named reference at run-time. Changing the value through
CSSOM will changed all rules where such var is used.

It appears as your $match idea is just a specialization of @const
see: http://wiki.csswg.org/ideas/constants#const-at-rule.

May be its time to return to @const ideas?


-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Monday, 13 August 2012 16:30:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:58 GMT