Forum .LRN Q&A: Re: .LRN Gardens

Collapse
32: Re: .LRN Gardens (response to 1)
Posted by Nima Mazloumi on 03/30/04 06:03 PM

A proposal for how we might improve the use of CSS in OpenACS/dotLRN.

After some very interesting consulations we (Nima, Bruce, Andreas, Paul, Brademer, Denis, Lars) had during the bug bash in Copenhagen we came up with some ideas on how to make OpenACS fully css-able. We solicit your comments, advice, criticism, and blessings.

Before I start once again many thanks to the friends in Copenhagen who made this bug bash possible. Special thanks to Joel - you are a great release manager.

So this is the suggestion we would like to make:

1. Conception

We think that three or four style levels will be needed to allow for basic levels of site-wide stylistic consistency while allowing for individual application or portlet flexibility.

Level 1: Site-wide master layout sheet.

A master layout style that defines how to place the standard elements of the site. Think of them as header, footer, navbar, page. This sheet is used for templating purposes. So making changes here will change the position these elements.

Level 2: Site-wide master style.

A master style sheet that defines the most used elements used all over OpenACS/dotLRN. These are for instance

  • headings
  • html lists (ordered, unordered)
  • bold/emphasized elements
  • anchor tag (visited,...)
  • default text (font type, size, ...)
  • ...

Level 3: Builder Styles.

Default styles for the builders we have in OpenACS/dotLRN. These are:

  • formbuilder
  • listbuilder
  • portlets
  • ...

This already happens on package level but is still different from normal packages since the builders can be used everywhere within the plattform so their style sheets have to be included in the master template (as is done already).

It is important in the longrun to have more and more of such builders for standard components used in packages. Thus you can make development easier on the one hand but also enforce a consistent look and feel for the whole site.

Level 4: Application-specific styles.

There are a few packages, like calendar, with features needing styles that might go beyond inheritable upper level styles. There are now two different ways to define these package level styles

  • on a page level so we will have for each adp also an css
  • on package level within the resource folder

This will allow developers the freedom they need in special cases.

2. Steps to get there

2.1 First step

A dummy page is created using existing material to define a consistent style that can cover about 80% of what is described above without a single change required inside the packages.

The materials include:

  • default-master template for the layout elements we have
  • forms.css and lists.css for the builders we have
  • default-master.css for the standard elements required for the site

The resulting dummy page will include most of what is required in the site and serve as test case for

  • consistency of look & feel for all styles
  • consistency for all style classes defined for the site

At this stage we will have a proof of concept which can be discussed broadly in the community.

2.2 Second step

Once all suggestions, comments are taken into the consideration and compatibility is tested for browsers the styles and the default master template will be commited to CVS.

2.3 Third step

Create a style guide that explains in detail the design classes defined and how and where changes need to be made to change the look and feel of the site and of a package a developer is working on.

2.4 Final step

A design release is suggested for OpenACS/dotLRN doing nothing but fixing the code to make it fully css conform. For this purpose we need to define rules on how to transform the files.

These rules deal with

  • embedded style elements html tags
  • deprecated html tags like b, font...
  • ...

Once these rules are defined those that can be automated should be implemented as service package in OpenACS the other rules that require semantic knowledge have to be decided manually. This effort could be done in two ways: a css bash or decentralized through each package maintainer. While both approaches have their benefits the first also creates a platform to create a common understanding of css within the community and to share knowledge and best practise faster.

3. Moving towards XHTML

During the whole process the limitation of the efforts are set by only changing what is reusable whe we introduce xhtml to OpenACS in the long run. So we have to find out if there are any conformance issues that are required to ensure that all the work that is done won't be in vain.

 

Writing code, building community.

A number of us worry about how best: 1) to solve the technical problem, 2) build a consensus, 3) and build a development model that will encourage as many people as possible to contribute. We hope community members will respond to all three elements of this problem. We also hope to schedule some time working on this problem at the next Bug Bash in Heidelberg.

Many thanks to all who have contributed thus far!