Re: WebKit now supports CSS Variables

OK, I am not a CSS expert, and I have not sync'd up with my 
colleagues, so my remark was somewhat off the cuff, and should be 
taken in that light.

I was just reacting the odd-ness of declaring a constant twice (or 
more) with different values.  In general in programming languages, 
you get (at most) the ability to re-affirm a constant as having the 
same value.  Any attempt to change or re-define the value of 
constants gets treated variously as an immediate error, or as 
producing (that immortal phrase) 'undefined results'.  Then questions 
of enable/disable, load order etc., do not arise...


At 17:07  +0200 30/06/08, Francois Remy wrote:
>>Surely the error is here;  bgColor has already been declared as a 
>>const with a different value.  You have a syntax violation (attempt 
>>to re-define a constant).  If you declare something 'const' in the 
>>context of a set of pages, it's your job to make sure it is, in 
>>fact, constant.  Whether the language processor enforces this, or 
>>whether you get 'undefined results' is a matter for debate.
>
>If we accept that JS can change the value of the constant, we should 
>not call them "constant".
>If we refuse to update a constant value after this constant is 
>defined (then, it's a true constant),
>we are getting a non-standard situation because a disabled/deleted 
>stylesheet can still have some effect in the document.
>
>I've found another problem, too.
>The value of a constant is defined the first time this constant 
>appear in the document's stylesheet (following your spec).
>
>If we got the following situation :
>
><head>
>    <link ... style1.css ... />
>    <link ... style2.css ... />
>    <link ... style3.css ... />
>    <script>
>        document.querySelector('html head').insertBefore(<link ... 
>style0.css ... />, document.querySelector("html head 
>link[href='style1.css']"));
>    </script>
></head>
>
>What's the stylesheet that define the value of the constant (I 
>suppose that all these stylesheets define a new one) ?
>
>The stylesheets are loaded asynchronously. So, when they are loaded, 
>the DOM has already changed and style0.css is became the "first" 
>stylesheet of the document. If we follow your spec, the constant's 
>value is gift by the first stylesheet that define it. But then, the 
>constant has been overwrotten by JS and it's not sure for the admin 
>that it's not possible to override its constants. Yes, it's now a 
>constant (style1>3 has no more effect on the constant value), but 
>the value of the constant can be decided by JS.
>
>If we want to continue to have style1.css has defining stylesheet, 
>how can this be done ?
>(=How can the UA know it's the first stylesheet that defined the constant)
>>>The DOM doesn't reflect the "primary" position of the stylesheet 
>>>(style0 can be inserted before style1)
>>>The load time is not a revelant information because stylesheet are 
>>>loaded asynchronously. (style2 can load before style1)
>
>Should the UA "keep" the order the stylesheet should be loaded ? 
>(style1, 2, 3, then style0)
>>>We must take count of @import declaration.
>>>We can load stylesheet in result with DOM-events, setTimeout, 
>>>setInterval, etc. too.
>>>If we add @import statment in a stylesheet, how will the UA define 
>>>the "priority" order of the sub-stylesheet ?
>
>Or have you another solution ?
>
>Regards,
>Fremy
>
>        PS : Some "readonly" variable can exists, but then it should 
>be UA-defined consts.


-- 
David Singer
Apple/QuickTime

Received on Monday, 30 June 2008 15:14:03 UTC