Defining CSS Constants

[Ted]

Is there a way to define a constant value for a color in a CSS declaration?

I have numerous colors in different CSS elements, and if I make a change in
color, I have to change all the reference to the color. For example:

Instead of this:
color: #306090

I would like to say:
define MyShadeOfBlue = '#306090'
color: MyShadeOfBlue
Thanks.

[Dana Cartwright]

"Ted" <Te************@aol.com> wrote in message
news:T_********************@comcast.com...

I have numerous colors in different CSS elements, and if I make a change
in color, I have to change all the reference to the color. For example:

Instead of this:
color: #306090

I would like to say:
define MyShadeOfBlue = '#306090'
color: MyShadeOfBlue

I do this using PHP. That is, I create my .css files using software. So I
can write:

$MyShadeOfBlue = '306090';

echo 'color: #' . $MyShadeOfBlue

Obviously, this answer is outside the domain of this newsgroup, and possibly
outside the domain you're interested in. But the problem you describe is
one that used to drive me nuts, because CSS is so much easier when you can
generate it with rules rather than having to write it all out explicitly.
So I switched over to using software to create it. And have never looked
back.

--------------------
-Dana (My e-mail address doesn't have a 2 in it).

[C A Upsdell]

"Ted" <Te************@aol.com> wrote in message
news:T_********************@comcast.com...

Is there a way to define a constant value for a color in a CSS
declaration?

I have numerous colors in different CSS elements, and if I make a change
in color, I have to change all the reference to the color. For example:

Instead of this:
color: #306090

I would like to say:
define MyShadeOfBlue = '#306090'
color: MyShadeOfBlue

Pure CSS can't do this. I sure wish it did.

[Nik Coughin]

Dana Cartwright wrote:

"Ted" <Te************@aol.com> wrote in message
news:T_********************@comcast.com...

I have numerous colors in different CSS elements, and if I make a
change in color, I have to change all the reference to the color. For
example: Instead of this:
color: #306090

I would like to say:
define MyShadeOfBlue = '#306090'
color: MyShadeOfBlue

I do this using PHP. That is, I create my .css files using software.
So I can write:

$MyShadeOfBlue = '306090';

echo 'color: #' . $MyShadeOfBlue

Obviously, this answer is outside the domain of this newsgroup, and
possibly outside the domain you're interested in. But the problem
you describe is one that used to drive me nuts, because CSS is so
much easier when you can generate it with rules rather than having to
write it all out explicitly. So I switched over to using software to
create it. And have never looked back.

--------------------
-Dana (My e-mail address doesn't have a 2 in it).

Yeah, this is a much nicer way to work IMO. The OP should however be aware
that if they choose to go down this path, they need to make sure that PHP
sends the correct content headers (text/css).

[Richard]

"Dana Cartwright" <da******@weavemaker.com> wrote in message
news:RW******************@twister.nyroc.rr.com...

"Ted" <Te************@aol.com> wrote in message
news:T_********************@comcast.com...

I have numerous colors in different CSS elements, and if I make a change
in color, I have to change all the reference to the color. For example:

Instead of this:
color: #306090

I would like to say:
define MyShadeOfBlue = '#306090'
color: MyShadeOfBlue

I do this using PHP. That is, I create my .css files using software. So

I can write:

$MyShadeOfBlue = '306090';

echo 'color: #' . $MyShadeOfBlue

Obviously, this answer is outside the domain of this newsgroup, and possibly outside the domain you're interested in. But the problem you describe is
one that used to drive me nuts, because CSS is so much easier when you can
generate it with rules rather than having to write it all out explicitly.
So I switched over to using software to create it. And have never looked
back.

I believe it can be done in javascript as well, but then javascript can be
turned off and it's useless.
PHP is fine, if you have a host who has it.
It would be nice if CSS could handle variables instead of just plain old
numbers.

[C A Upsdell]

"Richard" <An*******@127.001> wrote in message
news:cp********@news4.newsguy.com...

It would be nice if CSS could handle variables instead of just plain old
numbers.

Ditto HTML. But it will never happen: the W3C (and many cognoscenti here)
seem to be fixated on the mark-up paradigm, unable to conceive that the user
agent (rather than the server) could become the dominant agent in enabling
truly dynamic sites.

[Johannes Koch]

Ted wrote:

Is there a way to define a constant value for a color in a CSS declaration?
No
I have numerous colors in different CSS elements, and if I make a change in
color, I have to change all the reference to the color. For example:

element1, element2, element3, element4 {
color: #306090
}
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Richard" <An*******@127.001> wrote in message
news:cp********@news4.newsguy.com...

It would be nice if CSS could handle variables instead of just plain old
numbers.

Ditto HTML. But it will never happen: the W3C (and many cognoscenti here)
seem to be fixated on the mark-up paradigm, unable to conceive that the user
agent (rather than the server) could become the dominant agent in enabling
truly dynamic sites.

Well, there is Javascript, and as everyone knows it has not very good
support. It and other client side programming is cause of most security
bugs. You can do almost anything in JS already, if you wished, and if it
worked.

If scripting would have been build in HTML and CSS, who knows what would
have happened, but I believe there would be lots more problems than there
is now. The reason is that different browsers need to render HTML+CSS
correctly. Server side stuff does not need to be compatible to one
another. Makes server side programming very powerful, as one is not bound
to single technique either. Think about, what would you like if HTML
clientside stuff would be like Cold Fusion?

It would not be possible to make new language for HTML programming every
second month, like now.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Alan J. Flavell]

On Tue, 14 Dec 2004, Lauri Raittila wrote:

If scripting would have been build in HTML and CSS, who knows what
would have happened,

Something similar to (VB)scripting in MS Word: it would have been fun
for a little while, then it would have been abused, then it would have
been disabled by default.

[Jón Fairbairn]

Lauri Raittila <la***@raittila.cjb.net> writes:

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Richard" <An*******@127.001> wrote in message
news:cp********@news4.newsguy.com...

It would be nice if CSS could handle variables instead of just plain old
numbers.
Ditto HTML. But it will never happen: the W3C (and many
cognoscenti here) seem to be fixated on the mark-up
paradigm, unable to conceive that the user agent (rather
than the server) could become the dominant agent in
enabling truly dynamic sites.

[...]
If scripting would have been build in HTML and CSS, who
knows what would have happened, but I believe there would
be lots more problems than there is now.

Certainly. But there's a big difference between allowing
named constants and going all the way to scripting.

If you had named constants and were allowed to refer to
attributes of named blocks and such, but not change them, it
would still be markup, not scripting, and I think it would
make things much clearer.

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, =?iso-8859-1?q?J=F3n?=
Fairbairn wrote:

Lauri Raittila <la***@raittila.cjb.net> writes:

If scripting would have been build in HTML and CSS, who
knows what would have happened, but I believe there would
be lots more problems than there is now.

Certainly. But there's a big difference between allowing
named constants and going all the way to scripting.

Yes. Named constants would make no difference. So why do that? Thay would
make CSS very unreadable and such harder to learn.
If you had named constants and were allowed to refer to
attributes of named blocks and such, but not change them, it
would still be markup, not scripting, and I think it would
make things much clearer.

There is such thing in HTML, and practically no browser supports it, or
never has, and hardly anyone even knows about it.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Jón Fairbairn]

Lauri Raittila <la***@raittila.cjb.net> writes:

in comp.infosystems.www.authoring.stylesheets, =?iso-8859-1?q?J=F3n?=
Fairbairn wrote:

Lauri Raittila <la***@raittila.cjb.net> writes:

If scripting would have been build in HTML and CSS, who
knows what would have happened, but I believe there would
be lots more problems than there is now.

Certainly. But there's a big difference between allowing
named constants and going all the way to scripting.

Yes. Named constants would make no difference. So why do
that? Thay would make CSS very unreadable and such harder
to learn.

I don't see how you justify that assertion. You want me to
believe that writing something like

cambridgeblue=#0099cc

and using that would convey less information than writing
#0099cc throughout?

If you had named constants and were allowed to refer to
attributes of named blocks and such, but not change them, it
would still be markup, not scripting, and I think it would
make things much clearer.

There is such thing in HTML, and practically no browser
supports it, or never has, and hardly anyone even knows
about it.

You've got me there. I just skimmed through the html 4.01
DTD and couldn't find anything that looks like such a
thing. Would you care to enlighten me?

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

[Neal]

On Tue, 14 Dec 2004 16:05:24 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:

Yes. Named constants would make no difference. So why do that? Thay would
make CSS very unreadable and such harder to learn.

As they would not be mandatory, learning CSS would still be the same
difficulty.

And though it can impact readability, it would improve the ability to
change designs. If we set #000000 as the value of "color1", #ffffff as
"color2, and "#cccccc" as color3, then if I want to change the three
colors everywhere it's much easier to change a theroetical section at the
top reading something like:

@constants {color1:#000000;color2:#ffffff;color3:#cccccc;}

and have all instances of that color change everywhere.

[C A Upsdell]

"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net...

On Tue, 14 Dec 2004 16:05:24 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:

Yes. Named constants would make no difference. So why do that? Thay would
make CSS very unreadable and such harder to learn.

As they would not be mandatory, learning CSS would still be the same
difficulty.

And though it can impact readability, it would improve the ability to
change designs. If we set #000000 as the value of "color1", #ffffff as
"color2, and "#cccccc" as color3, then if I want to change the three
colors everywhere it's much easier to change a theroetical section at the
top reading something like:

@constants {color1:#000000;color2:#ffffff;color3:#cccccc;}

and have all instances of that color change everywhere.

Better than defining constants would be to allow a programming language
(say, JS) to set/compute the values to be later in the CSS. For example:

@JavaScript {
...
var color1 = '#000000';
var fonts = '"Times New Roman", Times, serif';
var page_width = min( document.width, units(60,'em') );
...
...
}

and then

html { color:@color1; font-family:@fonts; width:@page_width }

[Jan Roland Eriksson]

On 14 Dec 2004 18:33:02 +0000, "Jón Fairbairn"
<jo***********@cl.cam.ac.uk> wrote:

Lauri Raittila <la***@raittila.cjb.net> writes: [...]

...Named constants would make no difference...
...would make CSS very unreadable and such harder to learn. I don't see how you justify that assertion. You want me to
believe that writing something like

cambridgeblue=#0099cc

Yes of course that color name would make it excellently clear to Lauri
(who is from Finland) and to me who is in Sweden what it would look like
just from seeing the name? Not!

> If you had named constants and were allowed to refer to
> attributes of named blocks and such, but not change them, it
> would still be markup, not scripting, and I think it would
> make things much clearer.

There is such thing in HTML, and practically no browser
supports it, or never has, and hardly anyone even knows
about it.

You've got me there. I just skimmed through the html 4.01
DTD and couldn't find anything that looks like such a
thing. Would you care to enlighten me?

It's called 'named entity reference' (in search of better terminology)
and if you want to find out how it could have been implemented at least
at a very basic level in browsers you may want to play your way through
this little experiment.

<http://www.css.nu/markup/markup-entities.html>

Note: it seems that Nick has changed the default input to 'File upload'
while it used to be 'URL' so you need to specify URL input for form
generation to onsgmls and osgmlnorm.

--
Rex

[Jan Roland Eriksson]

On Tue, 14 Dec 2004 16:30:07 -0500, "C A Upsdell"
<cupsdell0311XXX@-@[e-mail]> wrote:

[...]

Better than defining constants would be to allow a programming language
(say, JS) to set/compute the values to be later in the CSS...

[...]

And then there is the "of course" as soon as your document leaves the
server to enter into an arbitrary UA, you have lost all possible
"control" of how it will be interpreted.

--
Rex

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, Neal wrote:

On Tue, 14 Dec 2004 16:05:24 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:

Yes. Named constants would make no difference. So why do that? Thay would
make CSS very unreadable and such harder to learn.
As they would not be mandatory, learning CSS would still be the same
difficulty.

Well, how many people have not learned from other peoples CSS?
And though it can impact readability, it would improve the ability to
change designs. If we set #000000 as the value of "color1", #ffffff as
"color2, and "#cccccc" as color3, then if I want to change the three
colors everywhere it's much easier to change a theroetical section at the
top reading something like:
Of course, that makes no sence, unless you actually use lightbackground =
white; emphasized = red; active = red, as it is easier change all
occurances of white to #fa43af, than change the constant definition.

But when you deside you want lightbackground to be dark, you have drawn
yourself to do illogical naming...
@constants {color1:#000000;color2:#ffffff;color3:#cccccc;}

and have all instances of that color change everywhere.

But now when you have

..foo {color:color1;font:font2;border:border3;}

you have no idea what that color is, but you need to go back to where
that constant is set. And why would it be on same file?

If there is:

..foo {color:red;font:inherit Arial;border:2px solid yellow}

It is very easy to spot which element in page it is, even if class name
is poorly chosen.

What I will do on my next CSS, i intend to make comments like this:

color: /*color1*/#fff;

And also make a makro that will easily change all colors.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[C A Upsdell]

"Jan Roland Eriksson" <jr****@newsguy.com> wrote in message
news:tk********************************@4ax.com...

On Tue, 14 Dec 2004 16:30:07 -0500, "C A Upsdell"
<cupsdell0311XXX@-@[e-mail]> wrote:

[...]

Better than defining constants would be to allow a programming language
(say, JS) to set/compute the values to be later in the CSS...

[...]

And then there is the "of course" as soon as your document leaves the
server to enter into an arbitrary UA, you have lost all possible
"control" of how it will be interpreted.

Not if web browsers are required to implement it. And in any case, the
server loses control whenever it serves out any page to the user agent,
since (as we all know) user agents are almost as imperfect as we are. ;-)
Only a thin-client paradigm would prevent this, and although Ellison would
love this, and many IT departments would love this, I would never want to
lose the 'P' in 'PC'.

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net...

On Tue, 14 Dec 2004 16:05:24 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:

Yes. Named constants would make no difference. So why do that? Thay would
make CSS very unreadable and such harder to learn.
As they would not be mandatory, learning CSS would still be the same
difficulty.

And though it can impact readability, it would improve the ability to
change designs. If we set #000000 as the value of "color1", #ffffff as
"color2, and "#cccccc" as color3, then if I want to change the three
colors everywhere it's much easier to change a theroetical section at the
top reading something like:

@constants {color1:#000000;color2:#ffffff;color3:#cccccc;}

and have all instances of that color change everywhere.

Better than defining constants would be to allow a programming language
(say, JS) to set/compute the values to be later in the CSS. For example:

And then we run to all problems of client side scripting again.
@JavaScript {
...
var color1 = '#000000';
var fonts = '"Times New Roman", Times, serif';
var page_width = min( document.width, units(60,'em') );
...
...
}

and then

html { color:@color1; font-family:@fonts; width:@page_width }

Well, IIANM, javascript already allows all that, just not with that
syntax.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Jan Roland Eriksson" <jr****@newsguy.com> wrote in message

And then there is the "of course" as soon as your document leaves the
server to enter into an arbitrary UA, you have lost all possible
"control" of how it will be interpreted.

Not if web browsers are required to implement it.

And how exactly is web browsers required to implement something?

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[C A Upsdell]

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net...

> On Tue, 14 Dec 2004 16:05:24 +0200, Lauri Raittila
> <la***@raittila.cjb.net> wrote:
>
>> Yes. Named constants would make no difference. So why do that? Thay
>> would
>> make CSS very unreadable and such harder to learn.
>
> As they would not be mandatory, learning CSS would still be the same
> difficulty.
>
> And though it can impact readability, it would improve the ability to
> change designs. If we set #000000 as the value of "color1", #ffffff as
> "color2, and "#cccccc" as color3, then if I want to change the three
> colors everywhere it's much easier to change a theroetical section at
> the
> top reading something like:
>
> @constants {color1:#000000;color2:#ffffff;color3:#cccccc;}
>
> and have all instances of that color change everywhere.

Better than defining constants would be to allow a programming language
(say, JS) to set/compute the values to be later in the CSS. For example:

And then we run to all problems of client side scripting again.

@JavaScript {
...
var color1 = '#000000';
var fonts = '"Times New Roman", Times, serif';
var page_width = min( document.width, units(60,'em') );
...
...
}

and then

html { color:@color1; font-family:@fonts; width:@page_width }

Well, IIANM, javascript already allows all that, just not with that
syntax.

Yeah, but JS in HTML can be turned off. I'm suggesting that this CSS JS
could not be turned off, but would have severe limitations -- e.g. read-only
access to DOM values -- which would prevent it from ever becoming malware.

[C A Upsdell]

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Jan Roland Eriksson" <jr****@newsguy.com> wrote in message

> And then there is the "of course" as soon as your document leaves the
> server to enter into an arbitrary UA, you have lost all possible
> "control" of how it will be interpreted.

Not if web browsers are required to implement it.

And how exactly is web browsers required to implement something?

The same way any browser is required to be a conforming user agent. The
problem, of course is that some user agents will not conform. Maybe we need
an xCSS standard?

[Roland Eriksson]

On Tue, 14 Dec 2004 19:40:29 -0500, "C A Upsdell"
<cupsdell0311XXX@-@[e-mail]> wrote:

"Jan Roland Eriksson" <jr****@newsguy.com> wrote in message
news:tk********************************@4ax.com.. .

On Tue, 14 Dec 2004 16:30:07 -0500, "C A Upsdell"
<cupsdell0311XXX@-@[e-mail]> wrote:
[...]

Better than defining constants would be to allow a programming language
(say, JS) to set/compute the values to be later in the CSS...

[...]
And then there is the "of course" as soon as your document leaves the
server to enter into an arbitrary UA, you have lost all possible
"control" of how it will be interpreted.

Not if web browsers are required to implement it.
Can't be enforced, lest browser programmers gets put at gunpoint.
And in any case, the server loses control whenever it serves out any page
to the user agent, since (as we all know) user agents are almost as
imperfect as we are. ;-)
Only a thin-client paradigm would prevent this, and although Ellison would
love this, and many IT departments would love this, I would never want to
lose the 'P' in 'PC'.

No need to lose the 'P' in PC, you can still "lose" your computer.
The organisation I work for has redefined 'PC' to mean "Provided
Computer" (beleive me, it's in an official company statement).

--
Rex

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

Not if web browsers are required to implement it.
And how exactly is web browsers required to implement something?

The same way any browser is required to be a conforming user agent.
The problem, of course is that some user agents will not conform.

No, problem is that *no* user agent conform. Never has, never will.
Maybe we need an xCSS standard?

Why do you think it is good idea to invent yet another standard that will
with good luck be half implemented (and so slowing down implementations
of other stuff), and totally *redundant*?

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote: Well, IIANM, javascript already allows all that, just not with that
syntax.
Yeah, but JS in HTML can be turned off.

True.
I'm suggesting that this CSS JS
could not be turned off,
CSS is optional in first place, so how on earth would that be possible? I
would think that if JS on CSS could not be turned of, that would be end
of CSS. One security bug there, and people would turn off *all* CSS.
There is not enaugh clueless webmasters using CSS incorrectly to force
masses to use CSS.
but would have severe limitations -- e.g. read-only
access to DOM values -- which would prevent it from ever becoming malware.

Well. It was not possible to make virus attached to documents, untill
microsoft implemented document formats. It was impossible for virus to
spread on email whiout users action, until microsoft made their email
programs capable of doing that, it was impossible to viruses spread in
internet whiout some malfunctioning application, so microsoft included
that in operating system.

What I am after, is that there is no security problems in javascript. All
of them are in implementions. All you can do using CSS is to crash
browser/windows. Most likely there already is security problems with JS
embedded to CSS using MS syntax...

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Jón Fairbairn]

Jan Roland Eriksson <jr****@newsguy.com> writes:

On 14 Dec 2004 18:33:02 +0000, "Jón Fairbairn"
<jo***********@cl.cam.ac.uk> wrote:

Lauri Raittila <la***@raittila.cjb.net> writes:

[...]

...Named constants would make no difference...
...would make CSS very unreadable and such harder to learn.

I don't see how you justify that assertion. You want me to
believe that writing something like

cambridgeblue=#0099cc

Yes of course that color name would make it excellently
clear to Lauri (who is from Finland) and to me who is in
Sweden what it would look like just from seeing the name?
Not!

Think about it for a moment. You know what blue is? You've
heard of Cambridge? Does not "cambridgeblue" suggest a blue
that is in some way connected with Cambridge? Can you use
Google? On the other hand, if it just says #0099cc, you can
tell it's a sort of blue colour, but the other information
is not present. So you haven't refuted the rest of my
sentence about how there is more information in this
version.

There is such thing in HTML, and practically no browser
supports it, or never has, and hardly anyone even knows
about it.

You've got me there. I just skimmed through the html 4.01
DTD and couldn't find anything that looks like such a
thing. Would you care to enlighten me?

It's called 'named entity reference' (in search of better
terminology) and if you want to find out how it could have
been implemented at least at a very basic level in
browsers you may want to play your way through this little
experiment.

<http://www.css.nu/markup/markup-entities.html>

Thanks. I'll peruse that.

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

[Harlan Messinger]

"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote in message
news:wf************@calligramme.cl.cam.ac.uk...

Lauri Raittila <la***@raittila.cjb.net> writes:

in comp.infosystems.www.authoring.stylesheets, =?iso-8859-1?q?J=F3n?=
Fairbairn wrote:

Lauri Raittila <la***@raittila.cjb.net> writes:

> If scripting would have been build in HTML and CSS, who
> knows what would have happened, but I believe there would
> be lots more problems than there is now.

Certainly. But there's a big difference between allowing
named constants and going all the way to scripting.

Yes. Named constants would make no difference. So why do
that? Thay would make CSS very unreadable and such harder
to learn.

I don't see how you justify that assertion. You want me to
believe that writing something like

cambridgeblue=#0099cc

and using that would convey less information than writing
#0099cc throughout?

That particular choice of name would be a poor one. Suppose you decided to
use #cc9966 instead. You'd change it to

cambridgeblue=#cc9966

which would be absurd. Then you'd rename it lightbrown:

lightbrown=#cc9966

and would have to replace all references to "cambridgeblue" to refer to
"lightbrown" instead. This would defeat the purpose of using a constant name
in the first place.

The goal in *any* kind of programming, markup, or whatever, where names can
be assigned to constants or variables, is to choose a name that expresses
the function or purpose of the constant or variable, *without* reference to
what the current value happens to be. Good names would be "footnotecolor" or
"newsflashcolor".

[C A Upsdell]

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

> in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote: >> Not if web browsers are required to implement it.
>
> And how exactly is web browsers required to implement something?

The same way any browser is required to be a conforming user agent.
The problem, of course is that some user agents will not conform.

No, problem is that *no* user agent conform. Never has, never will.

Maybe we need an xCSS standard?

Why do you think it is good idea to invent yet another standard that will
with good luck be half implemented (and so slowing down implementations
of other stuff), and totally *redundant*?

Why do you think we should stop improving our tools?

[Jón Fairbairn]

"Harlan Messinger" <h.*********@comcast.net> writes:

"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote in message
news:wf************@calligramme.cl.cam.ac.uk...

I don't see how you justify that assertion. You want me to
believe that writing something like

cambridgeblue=#0099cc

and using that would convey less information than writing
#0099cc throughout?
That particular choice of name would be a poor
one. Suppose you decided to use #cc9966 instead.

You seriously think that the University of Cambridge is,
after eighty years or something, going to change from using
light blue to brown?
cambridgeblue=#cc9966

which would be absurd. Then you'd rename it lightbrown:
You've missed the point. cambridgeblue is the name of a
color, and as such it conveys more information than #0099cc.

In fact, cambridge blue isn't really #0099cc -- for one
thing, the colour we're supposed to use on the web for light
cambridge blue is #99ccff and even that's a "web safe"
colour that was chosen at some point. If later on it was
decided that enough viewers could handle pantone 284 or the
University decided to change to pantone 337, one could
change the definition.
The goal in *any* kind of programming, markup, or
whatever, where names can be assigned to constants or
variables, is to choose a name that expresses the function
or purpose of the constant or variable, *without*
reference to what the current value happens to be.
Not quite. Expressing the function or purpose is half of
it. Giving mnemonic names to numbers that represent
something is another.
Good names would be "footnotecolor" or "newsflashcolor".

And so, in conformance with sensible programming practice
you would write

footnotecolor = cambridgeblue

and elsewhere

newsflashcolor = #0099cc

if that was an arbitrary choice not intended to be an
approximation to light cambridge blue.
--
Jón Fairbairn Jo***********@cl.cam.ac.uk

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message

Maybe we need an xCSS standard?

Why do you think it is good idea to invent yet another standard that will
with good luck be half implemented (and so slowing down implementations
of other stuff), and totally *redundant*?

Why do you think we should stop improving our tools?

standard != tool

I would be all for simple server side/pre server tool for handling CSS
nicely. If such tool was to be invented server side, it would be usable
immidiately, not in 4 years, when some browser actually supported client
side way. I don't support any client side standards, that have nothing to
offer for end users, becuase end users should want browsers to be more
usable and less buggy.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Harlan Messinger]

"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote in message
news:wf************@calligramme.cl.cam.ac.uk...

"Harlan Messinger" <h.*********@comcast.net> writes:

"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote in message
news:wf************@calligramme.cl.cam.ac.uk...

I don't see how you justify that assertion. You want me to
believe that writing something like

cambridgeblue=#0099cc

and using that would convey less information than writing
#0099cc throughout?
That particular choice of name would be a poor
one. Suppose you decided to use #cc9966 instead.

You seriously think that the University of Cambridge is,
after eighty years or something, going to change from using
light blue to brown?

That's not a bad point, but what one specific university is or isn't likely
to do doesn't really change the fundamentals of good practice.

cambridgeblue=#cc9966

which would be absurd. Then you'd rename it lightbrown:

You've missed the point. cambridgeblue is the name of a
color, and as such it conveys more information than #0099cc.

OK, I do see your point.

[C A Upsdell]

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message

>> Maybe we need an xCSS standard?
>
> Why do you think it is good idea to invent yet another standard that
> will
> with good luck be half implemented (and so slowing down implementations
> of other stuff), and totally *redundant*?

Why do you think we should stop improving our tools?

standard != tool

Really? Do you then assert that chaos == tool ?
I would be all for simple server side/pre server tool for handling CSS
nicely. If such tool was to be invented server side, it would be usable
immidiately, not in 4 years, when some browser actually supported client
side way. I don't support any client side standards, that have nothing to
offer for end users, becuase end users should want browsers to be more
usable and less buggy.

Yes, server side would be better from many points of view. If the
server-side processing could apply to both pages being served out, and to
the files (like CSS files), to which pages are linked.

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

Yes, server side would be better from many points of view. If the
server-side processing could apply to both pages being served out, and to
the files (like CSS files), to which pages are linked.

As it can do that just fine, I fail to see your point.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[C A Upsdell]

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

Yes, server side would be better from many points of view. If the
server-side processing could apply to both pages being served out, and to
the files (like CSS files), to which pages are linked.

As it can do that just fine, I fail to see your point.

Perhaps you can enlighten me. When I use Perl to serve out pages, the
script serves out only a single file, the HTML file. Unless you are
suggesting that the CSS be embedded in the HTML rather than appear in a CSS
file.

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

Yes, server side would be better from many points of view. If the
server-side processing could apply to both pages being served out, and to
the files (like CSS files), to which pages are linked.

As it can do that just fine, I fail to see your point.

Perhaps you can enlighten me. When I use Perl to serve out pages, the
script serves out only a single file, the HTML file. Unless you are
suggesting that the CSS be embedded in the HTML rather than appear in a CSS
file.

That is because you use your Perl only to serve out HTML pages. There is
absolutely no reason why you couldn't do same for CSS files, exept that
you never thought about it. Just print text/css instead text/html.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Harlan Messinger]

"C A Upsdell" <cupsdell0311XXX@-@[e-mail]> wrote in message
news:jc********************@rogers.com...

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.individual.ne t...

in comp.infosystems.www.authoring.stylesheets, C A Upsdell wrote:

Yes, server side would be better from many points of view. If the
server-side processing could apply to both pages being served out, and to the files (like CSS files), to which pages are linked.
As it can do that just fine, I fail to see your point.

Perhaps you can enlighten me. When I use Perl to serve out pages, the
script serves out only a single file, the HTML file. Unless you are
suggesting that the CSS be embedded in the HTML rather than appear in a

CSS file.

Not at all. You create a Perl file called, for example, styles.pl. Your HTML
includes the tag

<link rel="stylesheet" href="styles.pl" type="text/css">

You program styles.pl in Perl to write the contents of a CSS document, just
as the Perl files you're familiar with are programmed to write HTML content.
On top of that, you have to tell your server to serve that particular file
as text/css instead of as text/html. I don't know whether that can be done
within the script in Perl; in ASP, you'd use Response.ContentType =
"text/css".

[Jón Fairbairn]

"Jón Fairbairn" <jo***********@cl.cam.ac.uk> writes:

Jan Roland Eriksson <jr****@newsguy.com> writes:

It's called 'named entity reference' (in search of better
terminology) and if you want to find out how it could have
been implemented at least at a very basic level in
browsers you may want to play your way through this little
experiment.

<http://www.css.nu/markup/markup-entities.html>

Thanks. I'll peruse that.

Having looked at it (strictly the property is of sgml rather
than html), I agree with what it's author says about what
could have been. Sic transit gloria mundi.

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

[Jón Fairbairn]

"Jón Fairbairn" <jo***********@cl.cam.ac.uk> writes:

Jan Roland Eriksson <jr****@newsguy.com> writes:

It's called 'named entity reference' (in search of better
terminology) and if you want to find out how it could have
been implemented at least at a very basic level in
browsers you may want to play your way through this little
experiment.

<http://www.css.nu/markup/markup-entities.html>

Thanks. I'll peruse that.

Having looked at it (strictly the property is of sgml rather
than html), I agree with what its author says about what
could have been. Sic transit gloria mundi.

--
Jón Fairbairn Jo***********@cl.cam.ac.uk
The crux of the biscuit, said the dog, is the apostrophe --- Frank Zappa

[Jan Roland Eriksson]

On 16 Dec 2004 20:33:22 +0000, "Jón Fairbairn"
<jo***********@cl.cam.ac.uk> wrote:

"Jón Fairbairn" <jo***********@cl.cam.ac.uk> writes:

Jan Roland Eriksson <jr****@newsguy.com> writes:

> It's called 'named entity reference' (in search of better
> terminology)...
> <http://www.css.nu/markup/markup-entities.html>

Thanks. I'll peruse that.

Having looked at it (strictly the property is of sgml rather
than html), I agree with what its author says about what
could have been. Sic transit gloria mundi.

Thanks :)

--
Rex