Jeff, I'm posting this here, in response to your tip 78 "Theming changes"[1] and Tip #77 Package parameter scoping and permissions[2]. I would like to explore combining a variation of the resource tag idea with a "cascading set of parameter defaults".
The benefits are quick, convenient, and consistent styles to any level.
For templating, instead of creating a new resource tag, how about modifying the existing template tags to automatically include a class attribute if one does not exist?
For example, a plain p tag in an adp file would be compiled with a class="acs_para" attribute, if no class attribute existed.
Woah! That means there would need to be default styles for all OpenACS supported tags up to all tags that can have class attributes, which seems tedious to setup, but would provide instant cross browser consistency as tag default styles in browsers can vary wildly. Also, it should work if only a few tags were supported to begin with.
The acs_* class styles would be defined in packages/acs-subsite/www/resources/site-master.css or something.
The class attribute value would be the value of a parameter "StylePrefix" in the current package combined with a root class value based on tag. For example, "fm-p" might be the value of a class attribute associated with p tags in a mounted forum instance.
By "cascading defaults" I mean that if the mounted package's StylePrefix were blank, then the package's StylePrefix would be set to the value of the "StylePrefix" paramater of the current subsite etc etc. and if all blank, then defaults to the main site's "StylePrefix" value, say "acs". For example, a fresh OpenACS install's pre tags would have class attribute values set as class="acs-pre".
This way, style can be controlled to any consistency, fairly quickly, in a way that is easily understood (hopefully =).
I think any current parameter name conflicts could be addressed by a worker bee; If any exist, I would gladly rectify them. The only other problem I foresee is how to set a parameter to be blank instead of taking on a larger scoped value... maybe {} or something like that could represent a blank parameter value?
Please let me know how this idea fails ;)
1. https://openacs.org/forums/message-view?message_id=271924
2. https://openacs.org/forums/message-view?message_id=271910