Re: WebKit now supports CSS Variables

Simetrical wrote:
> On Fri, Jun 27, 2008 at 12:39 PM, Brad Kemper <brkemper@comcast.net> wrote:
>   
>> Andrew was commenting specifically on the fact that in the spec, as it is
>> now, the values of the variables remain mutable, instead of just resolving
>> them at loading. Is the Web designer community really singling that out as
>> something they like?
>>     
>
> Well, as a web programmer who does some web design, I can envision
> that it would simplify things considerably, just as cascading does.
> For instance, say I have a rule in my site-wide stylesheet like
>
> @variables {
>   PrimaryColor: blue;
>   SecondaryColor: green; /* I'm a programmer, not a designer */
>   LinkColor: purple;
> }
>
> This would be followed, in the site-wide stylesheet, with many rules
> using these variables.  But then say that for some specific page I
> want to restyle it for some reason.  For instance, maybe my website is
> a store website, and I have a page for holiday items.  I might want to
> leave the style for that page basically the same, but change the
> coloring to red and green.  If I had variables, I could do that by
> just redeclaring the appropriate @variables block.
>
> If I had only constants, how would I do that?  I could make sure I
> provided a different @const block for every page, i.e., not define
> them in the main site stylesheet at all.  This wouldn't necessarily be
> so annoying to manage if variables had to all be in one block, as the
> proposal from the first post has it.  But this probably requires
> either an extra HTTP request, or extra bytes on every page for <style>
> tags, if the large majority of my site uses the same values.
>   
Here is what people are doing in this case:

--- site-a.css ---
@const PrimaryColor: blue;
@const SecondaryColor: green;
@const LinkColor: purple;
@const PanelBackground: maroon url(purple-circle.png) repeat;

@import url(../common.css); /* styles that use parameters above */
--- EOF ---

--- site-b.css ---
@const PrimaryColor: green;
@const SecondaryColor: purple;
@const LinkColor: red;
@const PanelBackground: green url(lemon-circle.png) repeat;

@import url(../common.css);
--- EOF ---

--- common.css ---
/* fallback contants definitions: */
@const PrimaryColor: black;
@const SecondaryColor: silver;
@const LinkColor: blue;
....

div.panel { background: @PanelBackground; }
a:link { color: @LinkColor; }

--- EOF ---

As you see common.css contains so called fallback set
of constants. These values are used as defaults when master/host 
stylesheet does
not contain some or all definitions.

Such way of value inheritance (first-defined-first-used) is made 
intentionally.
Pretty much the same can be achieved with !important modifier but there
are cases when !important is not acceptable as it is too strong.

> Moreover, it's perfectly possible that I don't have control over the
> main style sheet.  Generally speaking, in CSS, *anything* specified in
> one stylesheet can be overruled in a subsequent one.  Therefore,
> typical web software will have some core stylesheets, and then have
> additional stylesheets loaded after that which the site admin (or
> owner of the page, viewers, etc.) can alter.  This relies on the
> assumption that the admin can thereby easily change any rule they
> want.  While allowing constants doesn't strictly break that rule (you
> could manually re-specify every rule that used the constants), it sure
> makes things a lot more difficult in this scenario for the site admin
> than they have to be.
>   
As I have shown above @const will allow you to do this.

@const give you two options:

1) You can parametrize (a.k.a. pass parameters) slave style sheets in 
master CSS and
2) You can redefine/overwrite rules if it is needed in slave CSS.

In case of @variables parametrization is doubtful.
Say some style sheet on 3rd level and under some condition (MQ, hello!)
of inclusion will accidentally redefine some of variable(s). That will 
break the whole
system you originally crafted. To find such redefinition is difficult 
usually.

> Similarly, user stylesheets would benefit from being able to override
> variables on a site-by-site basis.  This brings up another issue,
> though.  Are user stylesheets loaded before or after site stylesheets?
>  I'm not aware that the spec says; it's not currently relevant,
> because the priorities of rules will never have to be resolved through
> document order, and I don't know of any other case where document
> order matters.  This case could be resolved explicitly in the spec,
> though, even if constants are used, by saying that constants in user
> stylesheets are read first.
>
> Overall, I do think there are good use cases for actual variables.  It
> seems to me like constants really don't make the most of the
> usefulness of cascading.
>
>   
Consider this:

Say you have company "A" that is designing web application/component 
"www.AA.com".
Another company "B" is willing to use that application with styles 
tweaked for their own
case (that is known as [re-]branding in real world).
@const allow you to do such thing naturally but @variables will not help 
you here.
So @const better suit modularity which is really a super goal of the 
whole @const/@vars feature.

And yet @const are 1) significantly easier to implement 2) allow to 
define aggregates so expect
them to be implement uniformly across all UAs.

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 27 June 2008 19:16:44 UTC