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 
    .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.4.0 : Monday, 23 January 2023 02:14:39 UTC