W3C home > Mailing lists > Public > www-style@w3.org > October 2008

Re: [Css Variables] Variable Declaration Blocks

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, 6 Oct 2008 10:24:22 -0700
Message-ID: <c9e12660810061024v2ef390d1jb1fd28afdc685df8@mail.gmail.com>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "Mike Wilson" <mikewse@hotmail.com>, "Chris Miller" <chris@blinkbox.com>, www-style@w3.org

On Mon, Oct 6, 2008 at 9:29 AM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
>
> Mike Wilson wrote:
>>
>> I agree with you Chris and I'll add a few bits to (2):
>>
>>> Andrew Fedoniouk wrote:
>>>>
>>>> 2) Why they are variables and not constants?
>>
>> I'll reverse the question and ask why shouldn't everything in CSS be
>> constants then? The same reasoning could be applied to the current CSS rule
>> scheme and we could have "first rule wins"
>> for everything, and no CSSOM modification after loading. We
>> could even lock down script modification of HtmlElement.class
>> and HtmlElement.style so all style and layout could be settled
>> once and for all during load-time.
>
> Sorry but this "why not?" of yours is not an answer on the first one:
> "Why they are variables and not constants?"
>
>> Personally I wouldn't want it to function this way, maybe some
>> would, and I'd like to see variables use the same scheme as the
>> rest already do.
>>
>> Talking about "run-time" modification of styles we already have
>> f ex the following support in current implementations that will
>> all lead to dynamic update of style/layout on elements:
>>
>> - change class on an HTML element through DOM
>> - change properties on rule through CSSOM
>> - add/remove rules through CSSOM
>> - load a new style sheet through CSSOM
>> - element style inheritance of changes by above operations
>
> So why do you need more here?
> What *practical* task of yours does require variables to be in the
> list?
>

I've worked on two applications that require cobranding.

One used a strategy for that. One principle of patterns is
"encapsulate the parts that vary," right?

One part that varied was the colors.

.form-bg {
  background-color: #f3f3f3;
}

.form-color {
  color: #333;
}

>>
>> Not offering run-time updates for variables would feel poor considering
>> the above list, especially since composite/complex variables have the
>> potential to become a main design element in future CSS.
>

Would "run-time updates" would seem like a big overhead.

The CSSOM is less than ideal for a few reasons:
 * not cross-browser (one needs an adapter to traverse, read, and modify).
 * long, like NS4 API document.styleSheets[0].imports[0]..., there's
no way to simply:
 * find Rule by selectorText:  e.g. - DIV.big,*>span - is a valid
selector, that might exist in a stylesheet. trying to search for
div.big is not so simple.

Mike Wilson stated a problem:
[How to] change the background color on a number of (different kinds
of) elements [?]

If it can be known ahead of time that such change might occur (and it
usually can), we can solve the problem by adding a selector to a
container. For example:-

<!DOCTYPE HTML>
<html lang="en">
<head>
<title/>
<style>
.foo{
  color: red;
}
body.bla > .foo {
  background-color: #CfC;
  color: #000;
}

body.bla p.big {
  background-color: #ffC;
}
</style>
</head>

<body>
  <div class="foo">The element <code>div.foo</code></div>
  <div>
    <p class="big">the element <code>p.big</code></p>
  </div>
<script type="text/javascript">
function change() {
  document.body.className = "bla";
}
</script>
<button onclick="change()">change()</button>
</body>
</html>

The change to the body className would result in the more specific
selector being applied to both div.foo and p.big elements, thereby
changing their background-colors to pastel green and yellow,
respectively, and also allowing the modification of other styles as
well.

Garrett

>
> --
> Andrew Fedoniouk.
Received on Monday, 6 October 2008 17:25:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:15 GMT