CMS Made Simple Forums

i have to do this as a guest, i can't log on and see anything,, 

more to the point the above classes and id's are pretty much what i thought CSS was all about? i learned most of what i know from  http://www.w3schools.com/default.asp  great place when you have a question type class in the search and find the diff uses, 
you can asign one sheet just to color or typo whatever and use it with CMSMS if the class or id is not in the HTML it does nothing,, but really you are going to type #FFFFFF  or id="white"  or  class="white" or something, right? you know you will either,
#header, #main, #news{background-color: #FFF;}

header class="white"
main class="white"
news class="white"

.white{background-color: #FFF;}

the great thing about class and id is the ability for great nuance, pick little pieces out and make them special.
hey where is the spellcheck button?

  mark 

Most of you miss one point in the discussion. CSS is only able to manage a color for one usage, i.e. background border or the text. But in most cases you may want to reuse a color for another usage and therefore variables are really useful.

Greats from Germany
LeisureLarry

mark (maksbud) wrote: header class="white"
main class="white"
news class="white"

.white{background-color: #FFF;}

Looks good, but it's not adviced to use "white" as a class name, what if you change that css definition to #F00

so use something like class="important" or "hilight"

ps. another tip, you can define multiple classes for one element using

tsw wrote:

mark (maksbud) wrote: header class="white"
main class="white"
news class="white"

.white{background-color: #FFF;}

Looks good, but it's not adviced to use "white" as a class name, what if you change that css definition to #F00

so use something like class="important" or "hilight"

ps. another tip, you can define multiple classes for one element using

ok sorry just an example "white" = "whatever" from my understanding you can't use numbers for the beginning tho
like class ="2whatever"

  mark

  (thanks Ted! i'm back on)

i think there are far more important things to work on in cmsms than this. i don't think valuable core developer time should be wasted on it at this time.

however, if someone really wants to see this, then perhaps they could develop a module that could act as a replacement for {stylesheet} tag that does the necessary variable => color changes in the css, caches the resulting stylesheets, serves them up to web site visitors, and provides an admin interface to define the variable names and colors.

other things to consider: will these be installation-wide variables? attached to a specific template and/or stylesheet? or are you going to add another thing to manually associate with them? how about per-page changes to those variables? how about the theme manager? what about using these variables elsewhere?

sounds like a heck of a lot of work to me for something that's easily done with a well laid-out css file, proper techniques, and a half-ways decent text editor. and you add the fact that using some proprietary code in what would otherwise be a standards-compliant css file would make it impossible to test that css code on a local machine without having a web server and cmsms installation on it.

kermit wrote: i think there are far more important things to work on in cmsms than this. i don't think valuable core developer time should be wasted on it at this time.

I (still) totaly agree on that

Sometimes it is a good solution to use the ability of smarty's function

config_load

example from the smarty handbook:

{config_load file="farben.conf"}

{#seitenTitel#}



        Vornamen
        Nachnamen
        Adresse

and this is a config-file (from handbook)

# global variables
pageTitle = "Main Menu"
bodyBgColor = #000000
tableBgColor = #000000
rowBgColor = #00ff00

[Customer]
pageTitle = "Customer Info"

[Login]
pageTitle = "Login"
focus = "username"
Intro = """Diese Zeile erstreckt sich über
mehrere Zeilen, und muss deswegen
mit dreifachen Anführungszeichen
umschlossen werden."""

# hidden section
[.Database]
host=my.domain.com
db=ADDRESSBOOK
user=php-user
pass=foobar

you should take a look in the english handbook to use it:

http://smarty.php.net/manual/en/

nils73 wrote: 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 ...

I will, thanks for being so polite.

@piratos: That is indeed a way how one could use smarty to manage colors. But it also not adhereing to the separation of content and layout. Basically what my proposal was about was being able to define a variable that can be used withing css (as that is something the language css does not allow). How you use the variables is another matter left to the user.
Running the stylesheets throug smarty may be a smart solution to that problem as the requirements wrt cacheing etc are similar too.  I'll have a look at it right now. 

Intresting discussion. First we would solve it programmatically and after wards it looks we can solve it with current functionality.

Why I was reading this thread is because I also feel the need for some dynamic css, but not for colors, its for background images. On all my pages I have a kind of banner with a picture in it. Because the picture is not necessary for understanding the content (it is just decoration) I have put that in a background image of the css. Now I will make that background image more dynamic by changing it thought a random image at load time.

Someone an idea how to solve this without dynamic CSS?

ehpotsirhC wrote: Intresting discussion. First we would solve it programmatically and after wards it looks we can solve it with current functionality.

Why I was reading this thread is because I also feel the need for some dynamic css, but not for colors, its for background images. On all my pages I have a kind of banner with a picture in it. Because the picture is not necessary for understanding the content (it is just decoration) I have put that in a background image of the css. Now I will make that background image more dynamic by changing it thought a random image at load time.

Someone an idea how to solve this without dynamic CSS?

when I needed something like this, I created UDT with random generator, in my template I added something like class="back{muUDT}" for the tag i needed to change, and then define all back0, back1, etc. in the css. Of course, if you have 200 images, you need something different, but if there are about 10-20 - it's quit straightforward solution might help.

If I'm reading you right, there is a random image module/tag, and Album has a random image template in it now...

Recently I've had the opportunity to look through the stylesheet code and through general stylesheet caching issues.  I still would like the ability to parse smarty through the stylesheets, but it needs to be controlled and it also needs to be cacheable.  We don't want people downloading the stylesheets (they can get quite heavy) each time they access a new page.

Also, there's the issue of the { and } characters, which are used in stylesheets.  we are currently using them in smarty as well. 

This leads me to believe that although smarty could be of benefit with css:
  1: certain modules could send out their own stylesheet code
  2: you could use the word {$myredcolor} everywhere instead of #cc2200, or
  3: you could use {get_random_image} for a background color

Summary:
It's not a simple issue, and nothing to be taken litely.  The wrong step will result in significant performance reductions.

Smarty has the ability to allow you to change it's delimiters, for example to {{$myvar}} instead of {$myvar), but that would probably require a new instance of smarty which would:
  a) increase memory requirements even more
  b) make using standard CMS plugins, modules and UDT's impossible

Conclusion:
Lets keep this on the burner till we figure out a good solution.  Maybe in 2.0 (where compatibility issues may be broken anyways).  Buit there's probably nothing we can do about this in the 1.x series, without breaking alot of stuff.