CMS Made Simple Forums

CSS is nice, but a lot of time you are typing in the same #ff33aa color in your sheet. If i make a purely php based site, I dump the style in the html itself so I can define my colors on one place and use variable names throught the rest of the style section. This lets me alter the colors very easy. I guess something similar is not (yet) possible in cmsms, but I like to be proven wrong in this case.
So to reiterate:
be able to define a shortcut/variable/whateveryouliketocallit and use it instead of the tedious and error prone #color statements in the style. 

I think that this is a brilliant idea, please register and submit a feature request in the core so we don't forget about this.

jelle wrote: CSS is nice, but a lot of time you are typing in the same #ff33aa color in your sheet.

Huh?
I get the feeling you didn't grab the concept of CSS.
If you use css as it is intended to be used, then there is no need for 'solutions' like yours.
I personaly would be not thrilled if this was put in this great cms system. Hacks/workarounds have no place in  production quality software.

While I would agree with PeterT that there seem to be ways to handle stuff like cryptic color codes without resorting to smarty tags, I would also say that generically speaking I'm completely in favor for having every bit of generated content run through smarty. 

If there are smarty tags, then I can build a CSS stylesheet from component sheets via the {include} tag -- basically, like CMSMS does now, only more visible to the developer, since the links are in the sheet for the developer to see, not hidden in the database.

Smarty is good. Smarty is our friend.

Michael

thetallguy wrote: While I would agree with PeterT that there seem to be ways to handle stuff like cryptic color codes without resorting to smarty tags, I would also say that generically speaking I'm completely in favor for having every bit of generated content run through smarty. 

If there are smarty tags, then I can build a CSS stylesheet from component sheets via the {include} tag -- basically, like CMSMS does now, only more visible to the developer, since the links are in the sheet for the developer to see, not hidden in the database.

Smarty is good. Smarty is our friend.

And your point is?
We are discussing the potential misuse of a perfect working method of styling a website and you are talking about how great Smarty is?
Let's stay on topic and let us not try to reinvent the wheel (or the cascading in css for that matter).

Peter, I didn't say there was something wrong intrinsically with css, as much as there is nothing wrong with html. In cmsms the html is generated from a db and run through smarty, to make it more flexible and easy for non-geeks. The css is generated from the db too, but the only flexibility you have there is the order in which the framents are placed, or you can bypass cmsms alltogether.
The problem I try to solve is this:
1) Every webpage only uses only a few colors. (That is intentional, it would look messy otherwise)
2) Every stylesheet has dozens of places where you have to fill in these colors. you could do a little with inheritance here, but the problem is sytemic, different elements require different colors. (but from a very limited palette)
3) the css editing pages have no way of doing a search and replace. (And S&R is not fantastic either especially combined with clueless cut & past)
4) Changing colors on a page is somoething you do often, but because of [2] it becomes very tedious and error prone.
5) What if you could just define your colors at the top of the stylesheet (or even seperately in the db, that is nice for the noobs that are allergic to code) and use meaninfull variable names in your css. Changing the colorscheme later on will be as easy at typing in 5-10 #colors or maybe even picking them from an inline palette.
(hmm would that be another feature? an online color(scheme) picker?)

jelle wrote: 2) Every stylesheet has dozens of places where you have to fill in these colors. you could do a little with inheritance here, but the problem is sytemic, different elements require different colors. (but from a very limited palette)

So?

4) Changing colors on a page is somoething you do often, but because of [2] it becomes very tedious and error prone.

No, your assumption was wrong and that leads to wrong concluisions.

5) What if you could just define your colors at the top of the stylesheet

Wow, you just reinvented cascading stylesheets!

and use meaninfull variable names in your css.

It's all there already

Changing the colorscheme later on will be as easy at typing in 5-10 #colors or maybe even picking them from an inline palette.

Yes, so why would you use another method?
I still don't get it.
Maybe some reading of a basic css introduction will show you that what you want is already there.

Peter, could you please dim your agression a bit? I do not mind if you have a different opinion and say so, but if you want to convince me (or anybody) you'd better bring some explanation instead of referring to a basic css lessons.
for instance:

5) What if you could just define your colors at the top of the stylesheet

Wow, you just reinvented cascading stylesheets!

Can you show me a simple example?  I realy hope I am wrong here, but as far as I know you cannot do that.

Can you show me a stylesheet where each color is only used only once? without putting other restrictions on the developer? This means you cannot revert to assigning multiple classes to an element, as that would violate the separation of content and layout.

petert wrote: I get the feeling you didn't grab the concept of CSS.

Au contraire - she got right to the point of it. You might want to discuss it with Shaun Inman, one of the most popular and advanced CSS designers around. He has come up with the concept of

• CSS-SSV (Cascading Stylesheets Server-Side Variables)
• CSS-SSC (Cascading Stylesheets Server-Side Constants)
• Updated CSS SSC

There are several situations I can think of where a dynamic CSS approach comes in quite handy. Very popular websites (like for example the German Bundesbank, look at the source) use variables to achieve certain layout effects and I do not see any reason why it should not be used.

Regards,
Nils

nils73 wrote:

petert wrote: I get the feeling you didn't grab the concept of CSS.

Au contraire - she got right to the point of it. You might want to discuss it with Shaun Inman, one of the most popular and advanced CSS designers around. He has come up with the concept of

That was not the point that was made.
The subject here is a way to stringreplace values in a stylesheet, while there are builtin methods in css for doing so.

jelle wrote: Peter, could you please dim your agression a bit? I do not mind if you have a different opinion and say so, but if you want to convince me (or anybody) you'd better bring some explanation instead of referring to a basic css lessons.

The 'aggression' comes from your remarks in the bug-tracker, maybe you should tone down yourself.

for instance:

5) What if you could just define your colors at the top of the stylesheet

Wow, you just reinvented cascading stylesheets!

Can you show me a simple example?  I realy hope I am wrong here, but as far as I know you cannot do that.

Can you show me a stylesheet where each color is only used only once? without putting other restrictions on the developer? This means you cannot revert to assigning multiple classes to an element, as that would violate the separation of content and layout.

I begin to think that this is too stupid for words.
If you want to achieve what I think you want to do then I wish you all the luck of the world, but I will stick to using standards.

In the other case you better explain some more.

Pat..... Yep, that's the idea

so we could define:  myBackgroundColor once and use myBackgroundColor everywhere, and then when the stylesheet is rendered, it would come out exactly as before.

Exactly my point, but you manage to say it in a lot less words.
another example:
H1 {
    background-color: $dark1;
    color: $light1text;
       }

and somewhere else (don't know where)
you have something like 
$dark1 = "#000254";
$light1 = "#66dd11";
$shadow1 = "#something";
$highlight1 = "#somethingelse";

so that it forms a nice set of colors to be used together.
This example is in pseudo-php but that is more because of my lack of smarty experience. Any method wil do as long as it is not to much work typing.

And back we are at the suggestion by Shaun Inman. You can do quite a lot with variables and stylesheets and the same applies to constants (here: the background-colors). But even if there wasn't this briiliant approach this should be a feature in CMSMS.

Thanks Patricia for calming things down and for getting straight to the point. Just one word, petert: Sometimes people in this forum (and in other communities as well) are not native english speakers (like me for example) and they miss some words to get right to the point. Sometimes I forget about this as well but most of the time I try to figure out what the author was thinking. If my answer wasn't what the person was looking for I try to get more answers and come up with a different solution if neccessary. Your answers in this forum are highly appreciated as you know quite a lot ... so please keep up the good work but please keep in mind what I just wrote. It might help from time to time ...

Regards,
Nils

I agree that this seems to be unnecessary to me.


What I do is set up the classeses I need in my CSS like this:

.bluBg {background-color:#00f}
.italic {font-style:italic}
.red {color:#f00}

then to style a heading for example, I'd use something like this in the template:

{title}

You can also use id="idName" for extra styling if the element is specific to that template.

so in your CSS you'd have:

#idName {padding:100px 0; float:left;}

and in your template you'd have something like

{title}

As far as I can tell, this achives the same thing that you're after, but using standard CSS.
All of the styles for the site are only set in one place, you use whichever classes and/ or IDs you need for a particular element.

HTH

C*