- 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