Re: WebKit now supports CSS Variables

On Sun, Jun 29, 2008 at 3:48 PM, Brad Kemper <brkemper@comcast.net> wrote:
> To my mind this allows more flexibility. You can continue to have additional
> style sheets overriding each other, when it is most useful to do it that way,
> but you can also have some global constants declared up front that are
> guaranteed to remain exactly as you declared them there, regardless of
> additional rules.

How is this useful, assuming that subsequent stylesheets are
maintained by increasingly more specific people?  E.g., if admin-set
CSS comes after software default CSS, section-specific CSS after
global CSS, and so on.  In that case, you're reducing the possibility
of the level closest to the needs of the specific page to control
layout.  There *should be* nothing in software default CSS that admins
of a specific installation can't change.  Likewise, there *should be*
nothing in a site-wide stylesheet that a particular section can't
change.  Constants give flexibility where you *don't* need or want it,
in the highest and most general layers, and take it away where you do,
at the most specific level.

> I would say that if you want that variety of theming, in which subsequent
> rules make changes to previous rules, then you already have it. For that
> sort of theme support, @var does not really add that much.

It makes maintenance by hand much easier, of theme supports and
anything else that reuses the same parameters often (especially
colors).  Manually adding a new rule for every rule you want to
override when the values are repeated everywhere is tedious and
error-prone.

It doesn't open up any fundamentally new territory, I agree.  It's not
really intended to, I don't think.  The constants proposal doesn't,
either.  Anyone who can change a page's CSS can de facto override
constants by overriding every rule that uses them, so it really
guarantees nothing.

> For @conts, there is a big benefit of NOT
> allowing any stop along the line to change the values. It is the same reason
> programmers sometimes use constants instead of variables, and why they are
> usually at the beginning of the program code.

I know of multiple programming languages (Python, bash) with no
concept of constants at all.  I know of none with no concept of
variables.  Language-enforced constants are totally unnecessary for
programming, and probably they only exist because in compiled
languages they can be more easily optimized than variables which
happen not to change.  None of the scenarios you've given have shown
any benefit that I can see from unchangeable constants -- assuming
that local stylesheets come after more global ones, which they
generally do because of how CSS has worked to date.

Received on Sunday, 29 June 2008 20:14:40 UTC