Cascading Style Sheets (CSS)

Architecture

The file drake.css contains all the CSS used in the core Drake CMS output and is shared between components/modules.

The file template.css contains the customized CSS for each component/module which the template has a customization for.

Each component and module has a dkcom_componentid or dkmod_moduleid parent class which allows specific customization. Structural CSS of the template only has no dk* prefix of any kind, while structural CSS of Drake CMS (which is standard and defined in the next paragraph) is defined in the first part of drake.css.

Structural CSS of components/modules, which does not have to be customized, is defined in the relative components/modules files.

Some general CSS definition are shared between components/modules and are defined through a generic dk_ prefix on them.

The following table summarizes how Drake CMS CSS is organized:

Stylesheet type Classes defined Where are classes defined?
Drake CMS structure or generic classes dk_*, dkmod_moduleid, dk_componentid drake.css
Module structure or shared classes dkmod_* drake.css
Component structure or shared classes dkcom_* drake.css
Template structure free template.css
Module (specific) free (always subclassing dkmod_moduleid) template.css
Component (specific) free (always subclassing dkcom_componentid) template.css
Module structure (specific) free (can override shared structure classes) module PHP or module CSS file
Component structure (specific) free (can override shared structure classes) component PHP or component CSS file

Each component/module should be within a div with the proper dkcom_/dkmod_ class. The number of sorrounding tables around the main inline rendering area should be minimized if not removed totally.

Prefixes used by Drake

  1. dk_ - Classes used by core files for output
  2. dkmod_ - Classes used by module output
  3. dkcom_ - Classes used by component output
  4. dkbot_ - Classes used by drabots output

Defining classes for use

Basic format used for standard front-end templates will be:

 dk_<identifier>
 dkcom_<component>_<identifier>
 dkmod_<module>_<identifier>
 dkbot_<drabot>_<identifier>

If you are developing templates for the Administration side the format is similiar but should follow below conventions:

 dka_<identifier>
 dkacom_<component>_<identifier>
 dkamod_<module>_<identifier>
 dkabot_<drabot>_<identifier>

If a class will be global to all elements in a given section omit the middle section and use as normal by just using the prefix and what you need to define. Example:

 dkcom_heading  -  Used to format all heading output by components

Appropriate use of tags

DIV and SPAN tags are the primary form for creating tableless output. Remember that a DIV tag works like a paragraph and anything after it is automatically placed below. If you need items on the same line a SPAN tag works well for this.

Do not use DL, DT, DD elements for creating a form unless you intend an indented type of form. To get a standard form that people are used to use DIV's and SPAN's as necessary.

ONLY, ONLY use tables as a last resort for formatting. While a fully tableless environment is nice it is not realistic in that tables do have a purpose and a valid use.

General layout

For each component/module three div tags are used during rendering:

General rules

  1. All CSS identifiers should be lowercase.
  2. All Drake objects should only use the class attribute and not custom style attributes
  3. Core, component or module output should not contain tags with style attributes as it is not a good MVC separation principle and makes it harder to override
  4. Do not use ID's in core, module, or component development
  5. Templates may use ID's in order to provide a greater level of flexibility
  6. Do not use tables, if positioning is needed CSS relative positioning (ex. forms layout) is the good choice
  7. Absolute positioning should only be used in template CSS
  8. Try to minimize duplicates using CSS tags already declared in the master CSS Class / ID list
  9. Use multiple CSS files. You should in general use 1 for our content and 1 for the templates general layout. One advantage to doing this is that it would allow you to port your template to other engines much more easily as your presentation and CMS formatting are separated.
  10. do not use ID's for your CSS classes, use instead
 <elementtype>.<your class name>

This way it can work in conjunction with a sites module / element prefix / suffix capabilities.

If you need multiple classes remember you can chain the classes together. Example:

 <style type="text/css">
   .type1
   {
     color:red;
   }
   .type2
   {
     font-weight:bold;
   }
   .type3
   {
     text-decoration:underline;
   }
 </style>
 <span class="type1 type2 type3">something</span>

NOTE: Reasoning for not using IDs. As a end user/template developer I can change the overall usage of a class by subclassing it using id level identifiers.

Example:

// Our class

.dk_module
{ 
   background:green;
}

// Users classes using ID's to differenciate objects.
#menu .dk_module
{
   background:red;
}

Specific items to include in any template development

There are known issues with different browsers as we all know when in comes to rendering not only CSS but just HTML. To address some of this we will list here items that should be used / taken into consideration when developing any templates.

CSS Tags to include

form { display:inline; } ---> This tag is needed to control form rendering by IE7. When forms are nested within divs or tables IE7 adds extra spacing around the form. This tag has been tested on FF2 and IE7 to make sure there were no crossover issues.

Current documented classes used by Drake Administration Templates

 CSS Class Name           Description
 ========================================================

Wanted features

Drake CMS officially supported CSS might have the following features:

This list is under completion.