W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: [css-variables] Another use case for "cascade"

From: François REMY <francois.remy.dev@outlook.com>
Date: Thu, 17 Apr 2014 18:34:35 +0200
Message-ID: <DUB130-DS247777726DE4EA2F0D0EE2A5520@phx.gbl>
To: "Ron van den Boogaard" <ron@ronvdb.com>
Cc: "CSS WG" <www-style@w3.org>
> Can you remind us what the "cascade" keyword is meant to do? I don’t
> understand the example by itself.
>
> Simon Sapin

Sure. It is replaced at cascade time by the value the property would have if 
the current declaration was deemed invalid (or didn't exist).

    .ZoomOnHover { transform: scale(1.1) cascade; } // will not affect other 
transforms
    .UpsideDown { transform: rotate(180deg) cascade; } // idem

    <span class="UpsideDown ZoomedIn"> // transform: rotate(180deg) 
scale(1.1) none;

In fact, "* { property: cascade }" is equivalent to nothing being done, 
because the declaration is simply ignored. Also, see [1].



> As an author, to me this feels more like a hack than a solution.
> Using !important is considered bad practice where I am living anyway.
>
> Ron van den Boogaard

It's the traditional usage of !important that's an issue, not the feature 
per se. In this case, I'm implementing the Decorator pattern [0] in CSS, 
where the final value of the property walks through a set of "filters" 
(those have to be executed as last instruction, and therefore are !important 
to be prioritized against normal declarations). I don't say declaration 
should ever be !important, because *that* would be bad practice, but I don't 
see why we couldn't use !important to apply filter and value-transform 
functions on otherwise classically set values.




[0] http://en.wikipedia.org/wiki/Decorator_pattern
[1] http://lists.w3.org/Archives/Public/www-style/2014Apr/0013.html 
Received on Thursday, 17 April 2014 16:34:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC