Forum OpenACS Development: Idea to allow storing icons etc in themes

Collapse
1: Idea to allow storing icons etc in themes
Posted by Dave Bauer on 12/13/07 03:30 AM
We have more an more desire to add icons etc, that match a theme.

A recent example is a set of mime type icons, that are useful in packages like file-storage. Originally I added the gnome set of icons in acs-templating. That's nice, but they don't go well with every theme.

So this idea is to create a set of standard reusable bits that can live in a theme.

I was thinking we could create a set of message keys each theme should implement.

ie:

<span>#</span>theme.icon_mime_type_ms_word#

so anyplace you wanted to use that icon you use that message key. The theme would include the proper URL to the image for the icon under that theme.

of course, this would require making themes work with OpenACS without dotlrn and having a default theme that ships with OpenACS.

I wanted to share this before I forgot it :) Hopefully we can do all these things in the next couple of releases.

Collapse
2: Re: Idea to allow storing icons etc in themes (response to 1)
Posted by Torben Brosten on 12/13/07 09:42 AM
Shouldn't the acs-lang message-keys use the default quoting (vs. noquote)? Wouldn't this suggestion of imbedding html in message keys open security issues that are currently blocked with the default quoting?
Collapse
3: Re: Idea to allow storing icons etc in themes (response to 1)
Posted by Torben Brosten on 12/13/07 11:52 AM
Why not just make a themes api?

A proc could grab the theme item with defaults based firstly on passed values, then parameters and finally context (or some other prioritization)?

Collapse
4: Re: Idea to allow storing icons etc in themes (response to 1)
Posted by Dave Bauer on 12/13/07 02:58 PM
Message keys are not user contributed content, that I am aware of, so only site wide administrators can modify them. Right now message keys can contain HTML as well as variable placeholders that will be filled in when the key is translated.

I thought about a Tcl api, but I think this idea meets the requirements as well as being simpler and requiring no new code to implement. It just requires documenting the set of resources that we want to be reusable. Of course, you could also define custom resources and reuse them per package also. (That is, if you have an icon that only makes sense in one package, it should still be a message key.) Icons should be localized also, if they include text, or even an image that only makes sense in certain languages. Hmm I just thought of that last bit, that reinforces the idea that they are message keys. Even if we don't implement this theme idea, I think it makes sense to use message keys for this kind of thing.

Collapse
5: Re: Idea to allow storing icons etc in themes (response to 1)
Posted by Torben Brosten on 12/13/07 10:09 PM
You're right. There are times when icons behave like message_keys as much as anything else.

Yet, image tags are different whether publishing html or xhtml. In a proc or template, making one change would affect all cases, but I don't see how to do that with acs-lang.

If icons will be added to acs-lang, could some kind of guideline about html use be added to the acs-lang docs, ie to keep appropriate usage practices? I can see where abuse of this feature could lead to whole web pages defined in it.

Collapse
6: Re: Idea to allow storing icons etc in themes (response to 1)
Posted by Dave Bauer on 12/13/07 10:17 PM
Torben,

Thanks, these are great issues.

We could put the URL of the resources in the key
then the template could change, but if you change the templates you have to change ALL of them anyway, so you need to globally replace image tags wherever they appear.

I would be open to an api that would do this, I just want it to be easy and simple.

I think we can hold off on an actual implementation until after 5.4 is released and we bring up theming in OpenACS.

Collapse
7: Re: Idea to allow storing icons etc in themes (response to 1)
Posted by Emmanuelle Raffenne on 12/16/07 07:09 PM
Hi Dave,

Usually a theme is implemented using stylesheets. On the other hand, to comply with basic accesibility requirements it's recommended not to insert icons using a IMG tag (in this case, remember that you would have to provide an ALT text), but to set them in stylesheets. So I don't see how a message key would help us.

Collapse
8: Re: Idea to allow storing icons etc in themes (response to 1)
Posted by Dave Bauer on 12/16/07 07:32 PM
Ok :)

So how would we implement something like mime type icons?

I suppose we could define a class for every mime type, would this make sense?

Collapse
9: Re: Idea to allow storing icons etc in themes (response to 8)
Posted by Don Baccus on 12/16/07 08:39 PM
I think so, but it's not any weirder than defining a new message key for each one :)
Collapse
10: Re: Idea to allow storing icons etc in themes (response to 1)
Posted by Dave Bauer on 12/16/07 08:48 PM
Don, I agree :) I am glad I mentioned this, using CSS makes alot more sense if it works.
Collapse
11: Re: Idea to allow storing icons etc in themes (response to 10)
Posted by Emmanuelle Raffenne on 12/16/07 11:21 PM
I don't know either for mime-type icons. I guess Don is right.

Here's an example of a style that displays an icon (from my site CSS):

.spanish {
background: url(/acs-lang/resources/es.gif);
background-repeat: no-repeat;
padding-left: 1.3em;
border: none;
}

Collapse
12: Re: Idea to allow storing icons etc in themes (response to 11)
Posted by Don Baccus on 12/17/07 11:35 AM
You just use that in a div, then? i.e &lt;div class="spanish"&gt;&lt;/div&gt;?
Collapse
13: Re: Idea to allow storing icons etc in themes (response to 12)
Posted by Emmanuelle Raffenne on 12/17/07 12:55 PM
Actually I use it in an &lt;a href="@url@" class="spanish"&gt; but yes, would be the same for a DIV I guess.
Collapse
14: Re: Idea to allow storing icons etc in themes (response to 13)
Posted by Michael Cordova on 12/21/07 02:03 AM
I think it's better using css instead of message keys, for several reasons. One point not mentioned yet is that we could define similar mime-type icons in one line, using the same configuration, for instance:
.mime-type-doc, .mime-type-docx, .mime-type-txt {
  background: url(/acs-lang/resources/images/mime-types/doc.png);
}

I recommend using a self-explanatory class name, for instance: mime-type-blablabla. Sample:

...download a &lt;a href="../blabla/file.zip" class="mime-type-zip"&gt;zip version&lt;/a&gt; of this folder...

You could also define a css style using "css attribute selectors", in order to put a spanish flag in every explicit spanish link. Something like that:

a[lang=spanish] {
  background: url(/acs-lang/resources/es.gif);
}
if you had something like &lt;a href="@url@" lang="spanish"&gt;

Anyway, there is one question I have found: How could we mix 2 icons (i.ex. for a spanish zip file)?

Collapse
15: Re: Idea to allow storing icons etc in themes (response to 1)
Posted by Tom Jackson on 12/21/07 05:45 PM
Just to confuse things even more, remember that you can have multiple classes:

&lt;div class="regular @lang@" &gt;Some stuff&lt;/div&gt;

Here is a quick example of using icons from a stylesheet, and alt text for non graphical browsers:

http://junom.com/document/

This is just a massaged dir_proc from AOLserver used with the tigris.org stylesheet.

Stylesheet composition is very tricky and depends entirely on order in some cases, and also upon errors. Debugging an issue is also very difficult because you may never get access to the users' setup. It is kind of like javascript, without the error messages to help you out.

The regularizing of forms and other reused blocks of markup will help the most for anyone trying to re-style a site, so one idea for variations at a package level would be to use div at some level which acts like a breadcrumb trail:

class="myclass site1 forums forum1"

If the default 'myclass' is all that exists, you get the default behavior. If someone adds site1 styles, these get mixed in (don't ask me how), etc. You don't have to do this at every point, just at reasonable levels, maybe only one per page, or at package boundaries.