"I'd set one goal to make OpenACS Core XHTML compliant and switch the header to XHTML Transitional. This move should go hand in hand with a .LRN cleanup of the HTML code in the packages used by .LRN to make them XHTML compliant.
To make the site easier to manipulate with a CSS, I suggest to wrap every HTML code generated by an < include> with a CSS < div> tag. The ID of the < div> tag should be automatically generated from the package_key.lib_file_name combination with the possibility to override. This should make the integration of code pieces in the CMS parts of OpenACS easy, as you can define the look of these pieces more easily."
These are good ideas. The OCT has breifly discussed cleanup of the HTML and we are not sure what level of HTML should be supported. It might be HTML 4.0 but either way, the point is to have the default installation validate against a specifcation of HTML or XHTML.
I think giving includes a standardized css class naming convention is also a good idea, although it might cause some explosion in the number of CSS classes that need to be defined. It might make more sense to build out a number of functional classes that would cover the most use cases in a default installation and use those system wide. It would then be possible for a designer to define a class for a specific page or include and change that. One problem with defining CSS per include is that is reduces the reusability of the include! If you predefine what it looks like, you can't use it in as many situations.
So I think defining a set of functional classes, but what role a include is playing in a page, main content, sidebar, navigation etc... rather than by the content of the include, will bring the most benefit and flexibility.
