Re: WebKit now supports CSS Variables

On Mon, Jun 30, 2008 at 1:16 AM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> In CSS you can overwrite everything. Already.
> @const gives CSS new feature - ability to define
> things that cannot be overwritten. So you have
> more choices: you can use constness and/or you can use variability.
> That in principle creates more design possibilities including
> modularity through parametrization.

Well, okay.  That's not what the variables proposal is getting at,
obviously, so maybe they shouldn't be viewed as alternatives but
complements.  Personally I don't see the use for setting something
that no one can ever change, but clearly there are those who feel
otherwise, and far be it from me to object.  I'm not going to argue
further on this point.

The point that they can't really be constant is a fairly good one,
though.  JavaScript can be used to dynamically disable a stylesheet
and add a new one.  In that case, implementations will have to handle
changes in constants anyway, so there's not necessarily a save in
implementation complexity.  Moreover, it negates any assurance of
constancy, which apparently is the point of the proposal: if I control
JavaScript (or the page source) I can override your un-overridable
constants by just adding a new <style> tag before they're defined.
Nothing is really constant to someone who can change the page source.

> And by the way you should refresh your Python knowledge.
> You can define immutable class attribute that is exactly 'const'
> or 'final' if you know Java.

How, by overriding __setattr__?  I stand by my statement that there's
no concept of constants in the language, that's a hack.

On Mon, Jun 30, 2008 at 9:02 AM, Dave Singer <singer@apple.com> 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.

Up until the present, syntax errors in CSS have always resulted in
well-defined behavior: the appropriate declaration or whatever is
ignored.  Are you suggesting that redefining a constant, or activating
and deactivating different stylesheets containing different constant
declarations, should result in undefined behavior?  Surely this is
undesirable.

Received on Monday, 30 June 2008 13:40:22 UTC