Re: WebKit now supports CSS Variables

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.

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.

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.

Received on Friday, 27 June 2008 17:50:47 UTC