Forum OpenACS Q&A: RFI: Look and feel of OpenACS

I think that a move towards better XHTML and CSS compliance will help with this. But perhaps another suggestion would be an advanced tutorial section that walks through it. It would be some good reference material,  I think.

I think Jade's idea about moving into the direction of xhtml and css compliance would be a major leap towards easier skinning. Like said, at the moment most packages rely heavily on tables and hard-coded design attributes which cannot be changed instance by instance. If they relied more on xhtml/css, the appearance could a lot easier be changed by using different css files in different contexts.

I don't know in which state the process of css'ifying the toolkit is, but I could for example take on the task of making lars-blogger and the parts of calendar used in blogger xhtml transitional and css compliant. Not because they would be in the most urgent need of change (at least lars-blogger), but more because I'll need them in short and as current they don't quite cut it for me.

I don't know if these kind of things need to be tipped, tho. Just a thought.

my vote is for xhtml and css usage. if the site was as tableless as possible (i know things like calendar would be hard/impossible to do this with), it would help a lot... you can do so much with just divs lists and paragraphs, which incidentally move over to handhelds/brail very well. now that many people are using list builder, ad_form, etc. these things are improving (since they all use the same css file and if you want to edit the look/feel it can be done in one place), . I think it would be good to have some site wide standards that can be used by any packaged, for example, the a href class=button works throughout the site, if we also had just as an example

<div class="package-nav">
<ul>
  <li><a href="">Page 1</a></li>
  <li><a href="">Page 2</a></li>
  <li><a href="">Page 3</a></li>
</ul>
</div>

available to all packages that use a top nav bar (logger, package manager, bug tracker, etc. come to mind). Then people could choose to have these links look however they want - it could event become a floating left nav pod if they wanted. From what i've seen openacs only has a few functionally different UI elements.

- lists (continued listbuilder integration will make editing it site wide easy)
- forms (this is already standardized for the most part)
- calendars (the css files in calendar would be a good place to standardize on these, as far as i can tell this and lists should be the only places on any site that use tables - i.e. navigation should use lists not tables)
- vertical lists of content - by this i mean things that listbuilder isn't good at, like forums, gc, etc.
- packaged based navigation (with my example above).

If we had a spec doc and a standardized way of dealing with these 5 UI elements (and any that i haven't thought of) i think that editing a handfull of css files would be pretty manageable for any project. I know that would make my life easier, since I've done just this all too many times in the past...