Forum OpenACS Improvement Proposals (TIPs): Tip #78: (Approved) Theming changes

Collapse
1: Tip #78: (Approved) Theming changes
Posted by Jeff Davis on 03/01/05 02:16 AM

I have written a <box> tag which takes id and class as attributes and emits the divs needed for doing css based rounded corners etc, which I would like to commit in acs-templating. See this page and and the source for why I think it's useful.

I would like to change the standard form and list templates to be xhtml and more css friendly (I think a number of people have done this already -- maybe someone has them already on hand). Also, the current css has hardcoded fonts and sizes which interfere with per site css and I would like to make the css more generic and less cosmetic so that most of the theming is isolated to the individual theme css files.

I would like to add a <resource> tag which would replace the hardcoded resource paths and which would allow us to have per theme images and css looked up rahter than hard coded in the .adp files (it would also let us do things like map images to an image only webserver or akamai with a centralized change). I am not 100% sure what attributes the resource tag should take yet but I am pretty convinced it would make theming a *lot* easier.

Some theming guidelines

  • Don't use inline styles, color, background, etc.
  • Use class in preference to id.
  • class names in camelCase, (_ is invalid, - would be ok but we should choose camel or -)
  • Anchors which are currently numbers need a letter as well (number only not valid)
  • Use generic class names in preference to package specific ones.
  • Use semantic markup and class names.
  • Generic markup for portlet and includelets (h2 for heading, h3 for subheading, p, ul, etc for content).
  • xhtml 1.0 transitional as a goal.
  • No per package css.

Things which make building accessible websites easier:

  • Don't depend on context bar as only means of navigation.
  • Don't assume a sidebar or tabbed navigation.
  • Don't require more that 640px for the content pane.

Things I am not sure about

  • should we have a class name prefix for the classes we define in openacs (like oacs or OA)?
  • How abstract should the resource tag be? Should it return a url or an html fragment for the resource. If it's a url things like a "text theme" which returned "edit" rather than an edit icon would not be possible (nor would doing sensible things with alt tags for i18n, it would be down to the person doing the adp to get that right).
  • How many people would be interested in trying to get this cleaned up?
Collapse
2: Re: Tip #78 Theming changes (response to 1)
Posted by Dave Bauer on 03/01/05 03:21 PM
I am definitely interested in this.

I think resource tag should emit HTML. It seems pretty similar to the acs-lang system of message keys. I think using an ADP tag instead of just special characters is alot easier to read.

Collapse
3: Re: Tip #78 Theming changes (response to 1)
Posted by Jeff Davis on 03/01/05 03:24 PM
Collapse
4: Re: Tip #78 Theming changes (response to 1)
Posted by Jade Rubick on 03/03/05 03:47 AM
I approve the box tag.

I think these changes are fantastic. Can you summarize the resource tag discussion and what conclusions you've come to after that? I'd like to see that summarized before I vote on that portion.

Collapse
5: Re: Tip #78 Theming changes (response to 1)
Posted by Malte Sussdorff on 03/03/05 08:10 AM
I think all ideas posted here are valuable and should be implemented. Please make sure to post the design guidelines somewhere prominent.

As for the resource tag, why don't we start with it first and then come up with more attributes as we go along.

To your questions:

- Class prefix: YES. Very useful.
- The resource tag should return HTML fragments.
- Interest yes, time depends :).

APPROVING BOX tag and resource tag with HTML fragments.

Collapse
6: Re: Tip #78 Theming changes (response to 1)
Posted by Jeff Davis on 03/20/05 04:21 PM
I discovered something we should probably follow for class names: the WSRP 1.0 specification (PDF) in section 10.6 actually defines a collection of CSS classes and says in part:
One of the goals of an aggregated page is a common look-and-feel across the Portlets contained on that page. This not only affects the decorations around the Portlets, but also their content. Using a common CSS style sheet for all Portlets, and defining a set of standard styles, provides this common look-and-feel without requiring the Portlets to generate Consumer specific markup. Portlets SHOULD use the CSS style definitions from this specification in order to participate in a uniform display of their content by various Consumers. For markup types that support CSS stylesheets, Consumers MUST supply a CSS stylesheet to the End-Users agent with definitions for the classes defined in section 10.6 of this specification.

Even if we don't end up implementing WSRP, they seem well thought out and ultimately a good starting point. There are some proposals for WSRP 2.0 (due later this year) to add some further classes but I didn't track them down.

Collapse
7: Re: Tip #78 Theming changes (response to 1)
Posted by Don Baccus on 03/21/05 07:29 PM
If there's anything approaching a standard set of class definitions, or even a fairly widely-accepted one, I'm all in favor of our doing so. It will certainly simplify the process of adding themes to a theme library.