Forum OpenACS Development: Themes and Package HTML guidelines

Collapse
Posted by Jeff Davis on

I am going to start working on theming for openacs. I want three things to come from this.

  1. Documentation for CSS classes on existing widgets and "Package markup Guidelines"
  2. A structure for self contained themes that can style a standard OpenACS install.
  3. A basic "theme generator" which can construct a theme based on some simple inputs.

In rough terms I think packages should:

  • Validate as XHTML 1.0 strict.
  • Use structural markup.
  • Be styled via CSS.
  • Use the available standard mega-widgets (list builder, form builder or ad_form, etc).

I am willing to do a lot of the work to make the packages meet those requirements but of course any help and extra eyeballs on the problem will make a big difference.

I want to be able to produce most of the standard styles of persistent nav on an unmodified distribution. I would say thats topbar, right and/or left sidebars, and combinations of that (with submenus handled either nested or separate).

Particularly important is that themes be self contained so that a designers can package up a theme without chasing down changes across dozens of files in the tree. As an adjunct to this I would like to consolidate the images used in the packages and provide a standard image dictionary as well. I think on other projects that allowed for this sort of thing there have been some very professional looking results contributed back.

I am not sure if any of this is at all controversial but I would like to hear any feedback people might have and I will incorporate it into the two TIPs (on Package HTML Guidelines and on Theming Package Structure).

Collapse
Posted by Steve Ivy on
Jeff, just to say this is great, and I'd like to be involved if I can.
Collapse
Posted by Jun Yamog on
Hi Jeff,

Maybe I can share some notes and expriences on this one.  Right off the bat.  I can already provide:

- pure css form template.  Only form section needs to be tested.

http://cvs.openacs.org/cvs/openacs-4/contrib/packages/bcms-ui-base/resources/form-template.adp

- pure css list template.  Although I removed aggregates and group by at the moment.  I need samples to test the aggregates and group by.

http://cvs.openacs.org/cvs/openacs-4/contrib/packages/bcms-ui-base/resources/item-list.adp

Although still have to check if its 100% XHTML :)

Steve has seen it in action and is starting to use the package that uses the css form and list template.  Although I will update the style sheet.  Well atleast now I just update the sytle sheet!

Anyway let me know what ever help I can do.  I will be interested to help.

Collapse
Posted by Don Baccus on
This is great, and I can't see it being controversial seeing as we've been talking about doing it forever ...

I assume this is for 5.1, since we've feature-freezed 5.0, eh?

Your TIP should probably make that clear.

I agree that being able to support the standard nav designs out of the box is a good thing, and it would be good to include a few sample themes for folks to build on.  That would go a long ways towards making the toolkit more usable out-of-the-box, as has Lars's work on the default index page and other things.

Collapse
Posted by Ola Hansson on
Jeff,

Are you picturing some kind of engine for running a collapsable/expandable navigation hierarchy, and a UI for creating/editing its links? Or is that out of scope for this theming project?

If you are, I'd like to get involved. And if you're not, I think I'll prepare a TIP for a persistent navigation package.

/Ola

Collapse
Posted by Mark Aufflick on
I have a fair bit of css experience - i'd love to help out structuring the html and css.
Collapse
Posted by Jeff Davis on
Ola, I had not gotten so far as to consider building support routines for persistent nav. I think it is useful although I think in terms of returns the biggest win is going to be simply cleaning up the existing markup and documenting the classes that exist. certainly anything that did persistent nav should work in conjunction with theming...

I have been thinking more about how to structure a theme package so that it can be self contained, multiple themes can be active on a given site, and it be reasonable for designers to work with. (i.e. something that creates a tarball of static html which is created from the master templates and with the various widgets in it). I have some of that done and have some thoughts about other issues but its a long way from being concrete.

Mark, any help would be great. I will put what I have up somewhere and we can start talking about more concrete things like class names and a basic design to start with.

I would love it if we could find some designers using design tools (golive or dreamweaver or whatever it is designers use now) and try to make sure that what we do build does work well for them.

You can look at the html demo pages and some links on approaches to theming on my dev site (note that I have ripped out a lot of the markup and made most of the dev site use css layout).

Collapse
Posted by Andrei Popov on
What maybe also a nice touch to facilitate the XHTML conformance, is to somehow hookup Developer Support with [o]nsgmls validation of a generated page.  Something like a valid/invalid link that can then list out validation errors/warnings.

Also, possibly, as a condition to "releasability" of a given package it should validate w/o errors (but with warnings).

Collapse
Posted by Andrei Popov on
...and the easiest way to do it in the short-run is to have a link to W3C's Validator: http://validator.w3.org/check/referer
Collapse
Posted by Andrei Popov on
TIP #8
Collapse
Posted by Ben Koot on