- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Mon, 06 Oct 2008 11:16:20 -0700
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- CC: Mike Wilson <mikewse@hotmail.com>, Chris Miller <chris@blinkbox.com>, www-style@w3.org
Garrett Smith wrote:
> 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;
> }
>
>
@const FORM-BG: #f3f3f3;
@const FORM-COLOR: #333;
@import rest.css
where the rest.css has following:
.form-bg {
background: @FORM-BG;
}
.form-color {
color: @FORM-COLOR;
}
That is typical case of parametrization by constant.
See: http://wiki.csswg.org/ideas/constants
So is the question: do you need constants or variables?
>>> 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 [?]
>
Do you mean something like following (jQuery):
$(".foo").background("#334455");
?
--
Andrew Fedoniouk.
http://terrainformatica.com
Received on Monday, 6 October 2008 18:17:19 UTC