Package: My Site Stylist - the Wizard Of Style

Created by: laetzer, Last modification: 13 Dec 2004 (05:06 UTC) by SEWilco
this is no actual feature yet, but a feature proposal


Themes are needed in a CMS for consistent appearance and flexibility is needed so it can be adjusted for a site. 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 bitweaver 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 bitweaver site. Four files are involved:
  1. ))grind.css((
  2. ))grind_comments_en.css((
  3. ))grind_admin.css((
  4. ))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).

grind.css source


grind_comments_en.css source


We had somehow educated that designer that his theme would never be part of bitweaver, 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:

this form is currently under heavy development

user's form source code / form


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

grind_admin.css source


That's it. Let's talk about
  • the actual attributes that can be set (not too many! no positioning whatsoever)
  • their values and how to pick them (dealing with colors and units? rather input than dropdown?)
  • that whole table should be ultra-usable, as to help somebody who's actually not aware of what he's doing
  • links gotta be in here, too. people always wanna change those
  • single table-rows could be single forms, so by constantly "applying one row" the user can play around with one element
  • actually there shouldn't be just one CSS file per theme, but one per feature (to avoid CSS overhead). Right?

Suggestions for Tags, Attributes and Classes that can be set:

  • major tags such as
    • body
    • h1, h2, h3
    • th
    • td
    • a
    • p (i don't think this is used at all on tp)
    • forms in general
      • input, textarea...
  • all major layout id's
  • classes that can be set
    • some specific table classes including
      • panel and data tables
      • odd and even rows
    • menu links
      • menuhead and menuoption
  • resriction of settings that can be modified
    • background and colour settings
      • background-image, background-repeat, background-position, background-color
    • font settings
      • font-family, font-color, font-weight, font-size
    • borders
    • 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


  • logo images should not be part of CSS, still MSS wizard should take care of it (like that ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and bitweaver and 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


some thoughts

by xing, 22 Jul 2004 (09:44 UTC)
i like the idea of using seperate submission buttons for each row. we will require a final submit button at the end as well, in case someone nows what he's doing and wants to submit the whole thing at once.

i bundled some stuff into tables such as the border and the font settings to make them more 'modular'. this way we can just include, say, the border table wherever we need to and it's complete with all settings, and the formatting of this section will always be the same as well.

you suggest line height in there, do we need that?

Re: some thoughts

by laetzer, 22 Jul 2004 (12:43 UTC)
> seperate submission buttons + final submit button

Is that possible? Wouldn't that require forms inside of form. Think that's illegal. Also, the person who knows what he's doing, shouldn't have to use MMS (?).

> line height

Definetely! For all those switching-to-Tiki-because-it-has-feature-XYZ? bloggers!

multiple submit buttons

by xing, 22 Jul 2004 (13:42 UTC)
you don't require multiple forms to have multiple buttons. once you press submit, you can work out what button was used and only process the fields of that portion of the from

Multiple Submit Buttons in HTML

what sort of form?

by xing, 23 Jul 2004 (10:55 UTC)
should we really have one endless form with hundreds of tables and settings? in addition to the fact that it's overwhelming, i think it would be better to configure class by class.

perhaps have a dropdown at the top, or links to start off with, which take you to a page with, say, a few settings you can work on.

maybe we could categorise them a bit, such as:
  • layout
  • links
  • tables
  • boxes and modules
  • ...

Re: what sort of form?

by laetzer, 23 Jul 2004 (13:42 UTC)
I agree! Maybe collapsing areas like above for the CODE examples?
  Page 1 of 1  1