Created by: xing, Last modification: 22 Jul 2004 (13:50 UTC) by xing
this is no actual feature yet, but a feature proposal
Preface
Themes are the reason for webmasters to try out a CMS. Only if its looks can easily be personalized it is considered a professional solution. Modern CMS sport features like "Themes", "Styles, or "Skins". Most of them, though, just have one actual theme, and some variations of colors and borders. The (now) classic source for what themes actually mean, is probably CSS Zen Garden. Every theme is different, still you could vary each one of them with another logo and some different colors to gain a nice sub-theme.
Our Plan
A wizard called my site stylist (not just CSS, but MSS) encourages an admin or user to adapt a given theme and apply basic style-changes. The result will not be a new theme, but a sub-theme. MSS aims at the user who doesn't know enough CSS and HTML to produce a full fledged theme by himself. The main target group is the admin of a Tikipro site. After the MSS wizard is done, the resulting style will give his site a "different from the rest" look.
Flow chart about the whole thing
A designer designed a theme called grind. An unknown admin likes it and decides to use it for his Tikipro site. Four files are involved:
))grind.css((
))grind_comments_en.css((
))grind_admin.css((
))grind_username.css((
The first 2 files were made by that designer, the 3rd file will contain the rules the admin wants to impose, the 4th file will contain rules that a user wants to impose, granted the admin lets him use the MSS feature (if that's not the case, the 4th file would not have to exist at all, in contrary to what had been stated above).
div.grindy {} /* This is the box that is used to display certain stuff on every page. It contains the main content excluding the controls (like tabs and buttons and such). These comments should be as long as possible. */
h1 {} /* headings of main content, also used for blog titles and as file gallery comments */
p {} /* every piece of text of the site (even inside table cells!) */
strong {} /* text that should be bold, but is dark red and not-bold in my theme "grind" */ {CODE}
We had somehow educated that designer that his theme would never be part of Tikipro, and thus he would remain un-honored for the rest of his life, if he didn't deliver a thought-through CSS and very interesting comments in a 2nd file. As soon as the unknown admin fires up his My Site Stylist (MSS), a script must open up grind.css and grind_comments_en.css (language depending on user settings) and collect the selectors, the styles, and the comments, so that the following huge form can happen to the user:
</td> <td> <p>no comment available</p> <p><em><a href="#" onmouseout="document.bgColor='#ffffff'" onmouseover="document.bgColor='#fdfd00'">mouse-over here and <strong>highlight body</strong> to see which element you are editing</a></em></p> </td> </tr> <tr> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> </td> <td> </td> <td> </td> </tr> </tbody> </table>
<p> Leave this field blank, or, If you know some CSS, add more style declarations:<br /> <textarea rows="4" cols="60" ></textarea> </p>
<p><input type="submit" /></p>
</fieldset> </form> {CODE}
Now, ))grind_admin.css(( will be created. In header.tpl it will have to be included as the very last style sheet, so that its style overwrites grind.css (the !important trick will also serve that purpose).
padding and margin ??? -> this can cause a great deal of problems if used wrongly - especially cross browser compatibility will be a major issue - selectively allow these settings e.g. for body?
please add yout thoughts as you see fit
Problems
logo images should not be part of CSS, still MSS wizard should take care of it (like that TikiWiki CI thingy)
upload of harmful pictures (or scripts?) via background-image:url()
file includes via @import (?)
!important rules overwrite short hand somewhat weirdly, like if you used short hand and specified a certain value, and then use !important and don't specify that value, !important might overwrite it with defaults
some (not many) browsers prefer author-!important over user-!important, meaning that our !important's might conflict with somebody's private CSS