WebKit now supports CSS Variables

[Andrew Fedoniouk]

Simetrical wrote:

> On Fri, Jun 27, 2008 at 12:39 PM, Brad Kemper <brkemper@...> wrote:
>  
>> Andrew was commenting specifically on the fact that in the spec, as it is
>> now, the values of the variables remain mutable, instead of just resolving
>> them at loading. Is the Web designer community really singling that out as
>> something they like?
>>    
>
> Well, as a web programmer who does some web design, I can envision
> that it would simplify things considerably, just as cascading does.
> For instance, say I have a rule in my site-wide stylesheet like
>
> @variables {
>   PrimaryColor: blue;
>   SecondaryColor: green; /* I'm a programmer, not a designer */
>   LinkColor: purple;
> }
>
> This would be followed, in the site-wide stylesheet, with many rules
> using these variables.  But then say that for some specific page I
> want to restyle it for some reason.  For instance, maybe my website is
> a store website, and I have a page for holiday items.  I might want to
> leave the style for that page basically the same, but change the
> coloring to red and green.  If I had variables, I could do that by
> just redeclaring the appropriate @variables block.
>
> If I had only constants, how would I do that?  I could make sure I
> provided a different @const block for every page, i.e., not define
> them in the main site stylesheet at all.  This wouldn't necessarily be
> so annoying to manage if variables had to all be in one block, as the
> proposal from the first post has it.  But this probably requires
> either an extra HTTP request, or extra bytes on every page for <style>
> tags, if the large majority of my site uses the same values.
>  

Here is what people are doing in this case:

--- site-a.css ---
@const PrimaryColor: blue;
@const SecondaryColor: green;
@const LinkColor: purple;
@const PanelBackground: maroon url(purple-circle.png) repeat;

@import url(../common.css); /* styles that use parameters above */
--- EOF ---

--- site-b.css ---
@const PrimaryColor: green;
@const SecondaryColor: purple;
@const LinkColor: red;
@const PanelBackground: green url(lemon-circle.png) repeat;

@import url(../common.css);
--- EOF ---

--- common.css ---
/* fallback contants definitions: */
@const PrimaryColor: black;
@const SecondaryColor: silver;
@const LinkColor: blue;
....

div.panel { background: @PanelBackground; }
a:link { color: @LinkColor; }

--- EOF ---

As you see common.css contains so called fallback set
of constants. These values are used as defaults when master/host
stylesheet does
not contain some or all definitions.

Such way of value inheritance (first-defined-first-used) is made
intentionally.
Pretty much the same can be achieved with !important modifier but there
are cases when !important is not acceptable as it is too strong.

> Moreover, it's perfectly possible that I don't have control over the
> main style sheet.  Generally speaking, in CSS, *anything* specified in
> one stylesheet can be overruled in a subsequent one.  Therefore,
> typical web software will have some core stylesheets, and then have
> additional stylesheets loaded after that which the site admin (or
> owner of the page, viewers, etc.) can alter.  This relies on the
> assumption that the admin can thereby easily change any rule they
> want.  While allowing constants doesn't strictly break that rule (you
> could manually re-specify every rule that used the constants), it sure
> makes things a lot more difficult in this scenario for the site admin
> than they have to be.
>  

As I have shown above @const will allow you to do this.

@const give you two options:

1) You can parametrize (a.k.a. pass parameters) slave style sheets in
master CSS and
2) You can redefine/overwrite rules if it is needed in slave CSS.

In case of @variables parametrization is doubtful.
Say some style sheet on 3rd level and under some condition (MQ, hello!)
of inclusion will accidentally redefine some of variable(s). That will
break the whole
system you originally crafted. To find such redefinition is difficult
usually.

> Similarly, user stylesheets would benefit from being able to override
> variables on a site-by-site basis.  This brings up another issue,
> though.  Are user stylesheets loaded before or after site stylesheets?
>  I'm not aware that the spec says; it's not currently relevant,
> because the priorities of rules will never have to be resolved through
> document order, and I don't know of any other case where document
> order matters.  This case could be resolved explicitly in the spec,
> though, even if constants are used, by saying that constants in user
> stylesheets are read first.
>
> Overall, I do think there are good use cases for actual variables.  It
> seems to me like constants really don't make the most of the
> usefulness of cascading.
>
>  

Consider this:

Say you have company "A" that is designing web application/component
"www.AA.com".
Another company "B" is willing to use that application with styles
tweaked for their own
case (that is known as [re-]branding in real world).
@const allow you to do such thing naturally but @variables will not help
you here.
So @const better suit modularity which is really a super goal of the
whole @const/@vars feature.

And yet @const are 1) significantly easier to implement 2) allow to
define aggregates so expect
them to be implement uniformly across all UAs.

--
Andrew Fedoniouk.

http://terrainformatica.com



 

[Simetrical-3]

On Fri, Jun 27, 2008 at 3:15 PM, Andrew Fedoniouk
<news@...> wrote:

> Here is what people are doing in this case:
>
> --- site-a.css ---
> @const PrimaryColor: blue;
> @const SecondaryColor: green;
> @const LinkColor: purple;
> @const PanelBackground: maroon url(purple-circle.png) repeat;
>
> @import url(../common.css); /* styles that use parameters above */
> --- EOF ---
> . . .
> As you see common.css contains so called fallback set
> of constants. These values are used as defaults when master/host stylesheet
> does
> not contain some or all definitions.
>
> Such way of value inheritance (first-defined-first-used) is made
> intentionally.
> Pretty much the same can be achieved with !important modifier but there
> are cases when !important is not acceptable as it is too strong.

But if I'm reading this correctly, this requires local styles to be
placed *before* global styles.  This is the opposite of the way things
are normally done in CSS, where the *later* styles take precedence.  I
think this might cause quite a bit of extra clutter.  For instance,
consider the MediaWiki software.  It loads all of the following
stylesheets, in the following order (some possibly appended onto the
end of others, some loaded really as separate files):

* A hardcoded common CSS file shared among all skins, users, etc.
* A hardcoded skin-specific CSS file
* An admin-customizable common CSS file
* An admin-customizable skin-specific CSS file
* A user-specific CSS file to enforce preferences selected through the GUI
* A manually-created user-specific CSS file (that can contain
arbitrary CSS rules)

Each one of these must override the previous one, logically.
Currently this is achieved simply by loading them in that order.  To
override the previous one, you just include a rule, and it magically
works, overriding existing rules with the same specificity.

But for constants to be overridable at all levels, the stylesheets
would have to be loaded in the *opposite* order.  The manual
user-specific stylesheet's constants would need to go first, then the
automatic user-specific stylesheet, and so forth.  This reverses
current behavior and complicates it.  To get the full flexibility of
the proposal, allowing any stop along the line to change the
variables, you'd have to include twice as many stylesheets, separating
constants out from everything else.  Or at least, I can see no other
way this would work, with earlier declarations overriding later ones.

> As I have shown above @const will allow you to do this.
>
> @const give you two options:
>
> 1) You can parametrize (a.k.a. pass parameters) slave style sheets in master
> CSS and
> 2) You can redefine/overwrite rules if it is needed in slave CSS.

Only by including everything in reverse order to usual, with the most
specific coming first and the most general coming last.

> In case of @variables parametrization is doubtful.
> Say some style sheet on 3rd level and under some condition (MQ, hello!)
> of inclusion will accidentally redefine some of variable(s). That will break
> the whole
> system you originally crafted. To find such redefinition is difficult
> usually.

But exactly the same applies to constants, just in reverse.  Say some
style sheet on the *first* level and under some condition of inclusion
will accidentally redefine some *constants*.  Then all *subsequently*
loaded stylesheets will break.  (And finding such a redefinition
should just be a matter of grep, in either case; plus it shouldn't
arise to begin with, with proper naming conventions.)

I think that "constants" and "variables" are the wrong way to contrast
the two proposals.  Instead, the contrast should be "first occurrence
overrides later ones" vs. "last instance overrides earlier ones".  The
former might be somewhat easier to implement, but the latter is how
CSS rules work, and so it's more consistent with how things work now,
IMO.

> Consider this:
>
> Say you have company "A" that is designing web application/component
> "www.AA.com".
> Another company "B" is willing to use that application with styles tweaked
> for their own
> case (that is known as [re-]branding in real world).
> @const allow you to do such thing naturally but @variables will not help you
> here.

Why don't they?  Just redefine the @variable after you load the
company A stylesheet.  This will immediately change all previous uses
of the variable.

To clarify, suppose we have these three stylesheets:

a.css:
@variables { x: 10em; }
div.myclass { height: var(x); }

b.css:
@variables { x: 15em; }

c.css:
@import "a.css";
@import "b.css";

I'm imagining that this will cause div.myclass to have height 15em,
*not* 10em.  This would then be the same as

b.css:
@const x: 15em;

a.css:
@const x: 10em;
div.myclass { height: var(x); }

c.css:
@import "b.css";
@import "a.css";

So as I say, the only difference is the order of inclusion.  If you're
supposing that the variables will work like in programming languages,
and the @variables section above would give a result of 10em because
that's what x is when the .myclass rule is parsed, then I completely
agree that this would be much less useful.  I don't think that's
what's being discussed, however.  As David Hyatt clarified earlier:

On Tue, Jun 24, 2008 at 1:43 PM, David Hyatt <hyatt@...> wrote:
> On Jun 24, 2008, at 10:39 AM, Francois Remy wrote:
>> The normal way it should be, if we reuse known CSS Priority types :
>>  Each variable is globally defined and the last variable defined in the
>> normal order is used accross all stylesheets.
>
> This is how the WebKit implementation currently behaves.


> And yet @const are 1) significantly easier to implement 2) allow to define
> aggregates so expect
> them to be implement uniformly across all UAs.

I'll leave comments on ease of implementation up to the implementers,
but as a web programmer, it would be considerably more convenient to
have later declarations override earlier ones.  I don't know what you
mean by #2.

[David Woolley (E.L)]

David Hyatt wrote:

> I agree.  I think the model of just allowing variables to be defined at
> the document-level is simple and intuitive.  It allows for centralized
> variable definition and reuse.
>

I think the only way you can make this work and still retain the cascade
philosophy is if you require includes and link elements, through which
variables propagate outwards to have an explicit qualifier to request this.

That way any stylesheet can re=define a variable without caring whether
the name is already in used, and have the scope of that variable limited
to itself, or the sheets it includes, but still have the option of
defining a global set of variables.

This is not perfect, because it only really allows one set of variables
to propagate sideways at any level, e.g. you can't have a set of
corporate variables and a conflicting set of variables for one
department, contributing multiple sheets, then have another (matrix
management?) department having following style sheets, but which use the
corporate variables.


 From the comments being made about corporate rules and the involvement
of Apple, I think this is being introduced for a market that considers
the cascade a nuisance, because that market believes in central control
of presentation.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[brkemper]

On Jun 29, 2008, at 10:00 AM, Simetrical wrote:

> But if I'm reading this correctly, this requires local styles to be
> placed *before* global styles.  This is the opposite of the way things
> are normally done in CSS, where the *later* styles take precedence.  I
> think this might cause quite a bit of extra clutter.  For instance,
> consider the MediaWiki software.  It loads all of the following
> stylesheets, in the following order (some possibly appended onto the
> end of others, some loaded really as separate files):
>
> * A hardcoded common CSS file shared among all skins, users, etc.
> * A hardcoded skin-specific CSS file
> * An admin-customizable common CSS file
> * An admin-customizable skin-specific CSS file
> * A user-specific CSS file to enforce preferences selected through  
> the GUI
> * A manually-created user-specific CSS file (that can contain
> arbitrary CSS rules)
>
> Each one of these must override the previous one, logically.
> Currently this is achieved simply by loading them in that order.  To
> override the previous one, you just include a rule, and it magically
> works, overriding existing rules with the same specificity.

Yes, and you would be able to continue to do so, same as you do now.

> But for constants to be overridable at all levels, the stylesheets
> would have to be loaded in the *opposite* order.  The manual
> user-specific stylesheet's constants would need to go first, then the
> automatic user-specific stylesheet, and so forth.  This reverses
> current behavior and complicates it.

To my mind this allows more flexibility. You can continue to have  
additional style sheets overriding each other, when it is most useful  
to do it that way, but you can also have some global constants  
declared up front that are guaranteed to remain exactly as you  
declared them there, regardless of additional rules. Of course you  
could always add more specificity in a later rule, but then you are  
really then overriding one of the key features of constants: their  
constancy.

> To get the full flexibility of
> the proposal, allowing any stop along the line to change the
> variables, you'd have to include twice as many stylesheets, separating
> constants out from everything else.

I would say that if you want that variety of theming, in which  
subsequent rules make changes to previous rules, then you already have  
it. For that sort of theme support, @var does not really add that  
much. It does add other benefits, which are also present in @const,  
but for theme support, it seems you already have what you want. For  
@conts, there is a big benefit of NOT allowing any stop along the line  
to change the values. It is the same reason programmers sometimes use  
constants instead of variables, and why they are usually at the  
beginning of the program code.

[François REMY]

So, let's go for another try.

Feel free to say what you think of it :
=> David Hyatt : Is this realisable, for the UA ? Easily or not ?
=> Everybody : Are my ideas close of your vision of the variables ?

/*
    If no propagation is defined, "public" is used as default value.
    If no media is defined, "all "is used as default value.

    Multiple propagation are proposed because it can be useful in some case
to have
    both PUBLIC and PRIVATE propagation (see later)

    FRIEND is also eligible for PRIVATE search, so you can't use FRIEND and
PRIVATE
    at same time because FRIEND already "implements" PRIVATE.

    Multiple media can be defined too.

    So the current specification is not breaked.
    This new proposal only allow some other possibilities
*/
@variables (public(\s*(friend|private))?|friend|private)?
(MEDIA_TYPE(,\s+(MEDIA_TYPE))*)? {
  myVar: {STRING};
}

Way the variables are computed (some better spec will be wrotten later in
this mail) :
> If some PRIVATE variable is defined in a stylesheet, then it'll be used
> Else if some FRIEND variable is defined in a parent stylesheet*, then
> it'll be used
> Else look at some PUBLIC variable

* A parent stylesheet is any steelsheet that own the specified stylesheet
>> style1.css { @import url('style2.css'); } /* style1 ownes style2 */

/*
    To resolve any "var(x)" in the CSS, this function must be called with
"x, null" or "x".
*/
DOMStyleSheet.getVariableValue(variableName, [propagation=null],
[media=currentDocumentMedia]) {
    1: If "propagation" is equal to "PUBLIC"
        1b: Look for any child stylesheet (beginning by the end of the
stylesheet)
        1c: Set "RESULT" = childStyleSheet.getVariableValue(variableName,
PUBLIC, media)
            1cb: If "RESULT" is not "null"
                1cbb: Return "RESULT"
    /* NOTE that FRIEND is also eligible for PRIVATE, but that PRIVATE is
not eligible for FRIEND */
    2: Look for any @variable block that have a propagation attribute equals
to "propagation" in the stylesheet (beginning by the end of the stylesheet)
        2b: Look for any variableName variable's declaration in it.
        2c: Return it's value.
    3: If "propagation" is not equal to "null" or "FRIEND"
        3b: Return "null"
    4: Look for the parent stylesheet
        4b: Return this.parentStyleSheet.getVariableValue(variableName,
FRIEND, media)
    5: If "propagation is equal to "FRIEND"
        5b : Return "null"
    6: Return this.ownerDocument.getVariableValue(variableName, media)
}

DOMDocument.getVariableValue(variableName, [media=currentDocumentMedia]) {
    1: Look for any stylesheet in the document that are enabled (beginning
by the end of the document)
        1b: Set "RESULT" = stylesheet.getVariableValue(variableName, PUBLIC,
media);
        1c: If "RESULT" is not "null"
            1cb: Return "RESULT"
    2: Return "null"
}


Some test case now :
link:stylesheet1.css {
        @variables friend { bgColor: red};
        s1 { color: var(bgColor); }
    }
    @import:stylesheet1a.css {
            @variables public { bgColor: green; }
            s2 { color: var(bgColor); }
    }
    @import;stylesheet1b.css {
            @variables private { bgColor: orange; }
            s3 { color: var(bgColor); }
    }
        @import:stylesheet1ba.css {
                @variables public friend { bgColor: blue; }
                s4 { color: var(bgColor); }
        }
link:stylesheet2.css {
        s5 { color: var(bgColor); }
}

body:style:color:"var(bgColor)"

>> s1: red (friend is eligible for private)
>> s2: red (public is not eligible for private, parent stylesheet has a
>> friend variable)
>> s3: orange (private var in the style sheet)
>> s4: blue (friend is eligible for private)
>> s5: blue (the last stylesheet that define a public "bgColor" is
>> "1ba.css")
>> body: idem as s5

Am I clear enough ?

Fremy


--------------------------------------------------
From: "David Woolley" <forums@...>
Sent: Sunday, June 29, 2008 8:28 PM
To: "www-style list" <www-style@...>
Subject: Re: WebKit now supports CSS Variables

>
> David Hyatt wrote:
>
>> I agree.  I think the model of just allowing variables to be defined at
>> the document-level is simple and intuitive.  It allows for centralized
>> variable definition and reuse.
>>
>
> I think the only way you can make this work and still retain the cascade
> philosophy is if you require includes and link elements, through which
> variables propagate outwards to have an explicit qualifier to request
> this.
>
> That way any stylesheet can re=define a variable without caring whether
> the name is already in used, and have the scope of that variable limited
> to itself, or the sheets it includes, but still have the option of
> defining a global set of variables.
>
> This is not perfect, because it only really allows one set of variables to
> propagate sideways at any level, e.g. you can't have a set of corporate
> variables and a conflicting set of variables for one department,
> contributing multiple sheets, then have another (matrix management?)
> department having following style sheets, but which use the corporate
> variables.
>
>
> From the comments being made about corporate rules and the involvement of
> Apple, I think this is being introduced for a market that considers the
> cascade a nuisance, because that market believes in central control of
> presentation.
>
> --
> David Woolley
> Emails are not formal business letters, whatever businesses may want.
> RFC1855 says there should be an address here, but, in a world of spam,
> that is no longer good advice, as archive address hiding may not work.
>

[Simetrical-3]

On Sun, Jun 29, 2008 at 3:48 PM, Brad Kemper <brkemper@...> wrote:
> To my mind this allows more flexibility. You can continue to have additional
> style sheets overriding each other, when it is most useful to do it that way,
> but you can also have some global constants declared up front that are
> guaranteed to remain exactly as you declared them there, regardless of
> additional rules.

How is this useful, assuming that subsequent stylesheets are
maintained by increasingly more specific people?  E.g., if admin-set
CSS comes after software default CSS, section-specific CSS after
global CSS, and so on.  In that case, you're reducing the possibility
of the level closest to the needs of the specific page to control
layout.  There *should be* nothing in software default CSS that admins
of a specific installation can't change.  Likewise, there *should be*
nothing in a site-wide stylesheet that a particular section can't
change.  Constants give flexibility where you *don't* need or want it,
in the highest and most general layers, and take it away where you do,
at the most specific level.

> I would say that if you want that variety of theming, in which subsequent
> rules make changes to previous rules, then you already have it. For that
> sort of theme support, @var does not really add that much.

It makes maintenance by hand much easier, of theme supports and
anything else that reuses the same parameters often (especially
colors).  Manually adding a new rule for every rule you want to
override when the values are repeated everywhere is tedious and
error-prone.

It doesn't open up any fundamentally new territory, I agree.  It's not
really intended to, I don't think.  The constants proposal doesn't,
either.  Anyone who can change a page's CSS can de facto override
constants by overriding every rule that uses them, so it really
guarantees nothing.

> For @conts, there is a big benefit of NOT
> allowing any stop along the line to change the values. It is the same reason
> programmers sometimes use constants instead of variables, and why they are
> usually at the beginning of the program code.

I know of multiple programming languages (Python, bash) with no
concept of constants at all.  I know of none with no concept of
variables.  Language-enforced constants are totally unnecessary for
programming, and probably they only exist because in compiled
languages they can be more easily optimized than variables which
happen not to change.  None of the scenarios you've given have shown
any benefit that I can see from unchangeable constants -- assuming
that local stylesheets come after more global ones, which they
generally do because of how CSS has worked to date.

[François REMY]

> I know of multiple programming languages (Python, bash) with no
> concept of constants at all.  I know of none with no concept of
> variables.  Language-enforced constants are totally unnecessary for
> programming, and probably they only exist because in compiled
> languages they can be more easily optimized than variables which
> happen not to change.  None of the scenarios you've given have shown
> any benefit that I can see from unchangeable constants -- assuming
> that local stylesheets come after more global ones, which they
> generally do because of how CSS has worked to date.

I thouht we already have dicussed about it.
And the conclusion was that constants are not possible in CSS.

Why ?
> You can enable/disable stylesheet (by JavaScript, by changing the current
> media, ...)

Consider this situation :

style1.css [enabled] {
    @const bgColor: red;
}
style2.css [disabled] {
    @const bgColor: green;
}
main.css [enabled] {
    body { background: const(bgColor); }
}

The body's background is red. OK.

In JScript, we can change the state of the style1.css and style2.css
stylesheet. [enabled] <==> [disabled]
Now, bgColor has "green" as value.
==> bgColor has changed of value
====> This is not a constant, but a variable.

Fremy

[Andrew Fedoniouk]

Simetrical wrote:
...
> There *should be* nothing in software default CSS that admins
> of a specific installation can't change.  Likewise, there *should be*
> nothing in a site-wide stylesheet that a particular section can't
> change.  Constants give flexibility where you *don't* need or want it,
> in the highest and most general layers, and take it away where you do,
> at the most specific level.

I am not sure I understand your concerns.

"admins" will be the first people who will benefit from @const.

They will define constants. Developers will use them.
Constants cannot be overwritten. So "admins" can sleep calmly.

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.

...

>
>> For @conts, there is a big benefit of NOT
>> allowing any stop along the line to change the values. It is the same reason
>> programmers sometimes use constants instead of variables, and why they are
>> usually at the beginning of the program code.
>
> I know of multiple programming languages (Python, bash) with no
> concept of constants at all.  I know of none with no concept of
> variables.  Language-enforced constants are totally unnecessary for
> programming, and probably they only exist because in compiled
> languages they can be more easily optimized than variables which
> happen not to change.  None of the scenarios you've given have shown
> any benefit that I can see from unchangeable constants -- assuming
> that local stylesheets come after more global ones, which they
> generally do because of how CSS has worked to date.
>

And I know programming languages that support modularity so
have constants. One of them is a next version of JavaScript:
http://www.ecmascript.org/es4/spec/overview.pdf by the way.

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.

--
Andrew Fedoniouk.

http://terrainformatica.com

[brkemper]

On Jun 29, 2008, at 1:14 PM, Simetrical wrote:

On Sun, Jun 29, 2008 at 3:48 PM, Brad Kemper <brkemper@...> wrote:

To my mind this allows more flexibility. You can continue to have additional

style sheets overriding each other, when it is most useful to do it that way,

but you can also have some global constants declared up front that are

guaranteed to remain exactly as you declared them there, regardless of

additional rules.

How is this useful, assuming that subsequent stylesheets are
maintained by increasingly more specific people?  

The most obvious example I can think of would be corporate colors. At the top of the style sheet, you have something that says that the corporate blue color is #006. Now, nobody has to use that color in the subsequent style sheets, but if they do, it will always be #006.

@const {

acmeBlue: #006;

acmeGold: #f90;

}

[David Singer]

At 23:09  +0200 29/06/08, Francois Remy wrote:
>Consider this situation :
>
>style1.css [enabled] {
>    @const bgColor: red;
>}
>style2.css [disabled] {
>    @const bgColor: green;
>}

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.


--
David Singer
Apple/QuickTime

[Simetrical-3]

On Mon, Jun 30, 2008 at 1:16 AM, Andrew Fedoniouk
<news@...> 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@...> 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.

[François REMY]

> 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]

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

[Christoph Päper-2]

Dave Singer:
> I was just reacting the odd-ness of declaring a constant twice (or more)
> with different values.

I haven't followed this thread carefully, but I thought everybody
understood that constants are impossible in the cascade model of CSS.
Author-set constants that is, because we do have constants already, they
are called keywords. We could make keywords variable, but that's it (and
somehow nobody seems interested to pursuit that idea).

> In general in programming languages,

Programming is *very* different from CSS (despite all those curly brackets).

[brkemper]

On Jun 30, 2008, at 8:29 AM, Christoph Päper wrote:

>
> Dave Singer:
>> I was just reacting the odd-ness of declaring a constant twice (or  
>> more) with different values.
>
> I haven't followed this thread carefully, but I thought everybody  
> understood that constants are impossible in the cascade model of  
> CSS. Author-set constants that is, because we do have constants  
> already, they are called keywords. We could make keywords variable,  
> but that's it (and somehow nobody seems interested to pursuit that  
> idea).

In practice, a constant would be similar to a keyword, but one that  
you create yourself. Which is why it would make sense to set it  
somewhere near the top, and not have it change. If people do not have  
a problem with "orange" being constant, then what is the problem with  
"myCompanyColor" being constant, once it is defined? The point is not  
to prevent people from finding some JavaScript loophole method around  
its constancy, it is to allow you to have the keyword-like values that  
you create yourself.

Constants are not impossible in the cascade model of CSS, any more  
than keywords are.


>
>
>> In general in programming languages,
>
> Programming is *very* different from CSS (despite all those curly  
> brackets).
>

[Daniel Glazman]

Dave Singer wrote:

> I was just reacting the odd-ness of declaring a constant twice (or more)
> with different values.

It's brand new. It's called "Variable constants". Patent's pending ;-)

</Daniel>

[Ambrose Li-3]

2008/6/30 Daniel Glazman <daniel.glazman@...>:
>
> Dave Singer wrote:
>
>> I was just reacting the odd-ness of declaring a constant twice (or more)
>> with different values.
>
> It's brand new. It's called "Variable constants". Patent's pending ;-)

Patent denied. Prior art in perl and ruby =)


--
cheers,
-ambrose

The 'net used to be run by smart people; now many sites are run by
idiots. So SAD... (Sites that do spam filtering on mails sent to the
abuse contact need to be cut off the net...)

[François REMY]

> In practice, a constant would be similar to a keyword, but one that  you
> create yourself. Which is why it would make sense to set it  somewhere
> near the top, and not have it change. If people do not have  a problem
> with "orange" being constant, then what is the problem with
> "myCompanyColor" being constant, once it is defined? The point is not  to
> prevent people from finding some JavaScript loophole method around  its
> constancy, it is to allow you to have the keyword-like values that  you
> create yourself.
>
> Constants are not impossible in the cascade model of CSS, any more  than
> keywords are.

Not really. Not at all, in fact.

It's fondamentaly different because the browser know the value of all
constants
before loading the site, because it's the browser itself that define some
constant.

And not the site.

A constant must be defined BEFORE the program run.
It's so that constants are defined in all programming languages.
This is in fact the compiler that remove all reference to the const and
that replace it by the constant's value.

In CSS, we have no compiler. So, the "validity" of the constants cannot
be checked before the program became compiled, because the constant
can be created at any moment.

In any language, if you try to write something like "const x = 1" in file1
and
"const x = 2" in file2 (assuming that both file a defining the variable on
the
same scope), you will get a compilation error and nothing of your code will
be compiled.

In CSS, this is not possible, because you can't check all stylesheets before
loading thems, because the JS can add some new stylesheet later... or
because
a stylesheet can change when the media change !

Well, I see no solution...

Fremy

[Andrew Fedoniouk]

Francois Remy wrote:

> 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.

Constant instantiation (use) happens at the moment of parsing.

So if you will define your style sheet as:

@const COMPANY_COLOR: #11A;
@const COMPANY_PANEL_BORDER: 1px solid @COMPANY_COLOR;

@import url(common.css);
@import url(specific.css);

then at the moment of parsing of common.css constants used there will be
resolved to correspondent values or to none.

Any later DOM permutations should not affect specificity of selectors
and should not change compiled CSS. That is so called perfect
const-correctness.

>
> 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)

According to specification (CSS21):
"if two declarations have the same weight, origin and specificity, the
latter specified wins".

This means that UI shall behave as if it loads styles synchronously
(in single thread) and uses some global 'order' counter for CSS rules.
This is the only way of giving word "latter" reasonable meaning
in given context.

By the way: Shall we specify meaning of "latter" somewhere in CSS3 ?

It appears as "latter" means order in cause-effect chain rather
than anything close to real-time position of correspondent <style> or
<link> elements in the DOM.


--
Andrew Fedoniouk.

http://terrainformatica.com

[Andrew Fedoniouk]

Francois Remy wrote:
>
> In CSS, we have no compiler. So, the "validity" of the constants cannot
> be checked before the program became compiled, because the constant
> can be created at any moment.

And what is the name the thing that gets CSS source (text) and builds
correspondent data structures as a result?

>
> In any language, if you try to write something like "const x = 1" in
> file1 and
> "const x = 2" in file2 (assuming that both file a defining the variable
> on the
> same scope), you will get a compilation error and nothing of your code will
> be compiled.

Depends on many factors, cases and languages. In most languages you can
define constants with the same name but e.g. in different namespaces and
probably files.

CSS uses "silent recovery" method of parsing. So if you have
two entities with the same name you have only two options in CSS:

1) first seen - first used. That is @const.
2) last seen - last used. That is @var.

@const does not require any major changes in CSS parsing and handling.
@var requires change of CSS paradigm - @vars require at least
some additional interpreting layer.

>
> In CSS, this is not possible, because you can't check all stylesheets
> before
> loading thems, because the JS can add some new stylesheet later... or
> because
> a stylesheet can change when the media change !
>
> Well, I see no solution...
>

You see no solution to what?

--
Andrew Fedoniouk.

http://terrainformatica.com