Forum OpenACS Development: style controls (informal exploration)

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

Collapse
Posted by Jeff Davis on
Well, for one thing (and it's a nitpick) "_" is not valid in id's or classes. Beyond that, I think it's needlessly verbose. You don't need a <p class="acs-p"> since I see almost nowhere that you would want to style the p tag differently depending on whether it was in adp or user supplied html. The whole point is that the problem with styling now is that things are not generic enough. Providing for ultimate flexibility just makes it harder to get a consistent look, makes the stylesheets verbose and ugly, and ultimately makes theming just not work that well.

I think if you want per package or per instance styling it's better to just have a second stylesheet which modifies the primary stylesheet or is used in place of the primary style sheet rather than add a zillion class names for the particular package.

It also becomes almost impossible to document what css classes are available since they could be literally anything. If you want to be able to have a designer sit down and create css without having to look through the 200+ packages to see which classes they define.

Also you could do per pacakge and per instance styling by making the body tag

<body id="style-@StylePrefix@" class="package-key">
and get most of the advantages yo u would like to get in terms of flexibility without the overwhelmingly verbose complexity your method would entail.
Collapse
Posted by Torben Brosten on
Thanks for the feedback, Jeff. You're right, there could be style madness in providing this flexibility.

I see now that the DefaultMaster parameter in acs-subsite allows all the flexibility per subsite. With your suggestion of using the package_id or package-key as part of a stylesheet name, the StylePrefix idea becomes redundant.

What do you mean by creating a resource tag in place of "hard coded resource paths"?

cheers,

Collapse
Posted by Jeff Davis on
Currently we just stick static files in package/www/resources/ and we put 3 things there right now:
  • images
  • css
  • javascript
Resources is good in that it's not permissioned and has low latency but it has one big problem (besides being restricted to static files) and that is that it means we are hard coding filenames to images within packages all over the place.

The absence of any abstraction means that you can't easily say "for subsite X /resources/acs-subsite/add.gif use /garish-and-vulgar/acs-subsite/add.gif and for subsite Y use /subtle-and-subdued/acs-subsite/add.gif". That means either going through all the code and finding places we say /resources/acs-subsite/add.gif and making them /resources/acs-subsite/@theme@/add.gif or doing what I think is the sensible thing which is add a "theme aware resource tag" which would know the theme for the current subsite and would generate the url from that.

I would envision something like:

 
<resource package="acs-subsite" key="add">
which would emit
<img src="/subtle-and-subdued/acs-subsite/add.gif" ... >
The thing I am a little hung up on is whether it would know to generate <link ...> for css and js etc.

One really cool side benefit of this approach would be that we could fairly easily provide designers (and others) to layer design on an existing site by having this emit

<img src="http://designer.example.com/subtle-and-subdued/acs-subsite/add.gif"...>
Collapse
Posted by Don Baccus on
If behind-the-implementor's-back smartness bothers you, we could always have resource_img and resource_link tags, or resource tag="img" ... or similar uglification (maybe defaulting to img?)
Collapse
Posted by Torben Brosten on
Is it possible to just pass a style theme in the slave tag as an attribute the way that includes do?

&lt;slave theme=@theme@>

so that file references might be:

&lt;img src="@theme@/filename"

Also, could &lt;box> be called something else, such as &lt;encase> or &lt;wrap>?

There are many places where I can see using an include tag to wrap around another include. A generalized version of &lt;box> could be really useful.

I'd see it work sort of like this:

&lt;wrap src="filepath">&lt;include src="filepath2">&lt;/wrap>

That way there would be less need to pass properties through multiple layers of include tags with special handling for special cases.

Collapse
Posted by Torben Brosten on
Jeff, I plan on starting to clean up the code in the ecommerce package soon, which includes separating html from the data.

A &lt;box> tag would be really useful. Any chance it will be available for 5.2?

If so, could it be called something like &lt;wrap> or &lt;pretty> or &lt;widget>?

Hmm.. I just found the &lt;include-option> tag. How would that differ from a generalized &lt;box> tag?