How to make application more easily skinnable?

skins
retag add tags

Looks like it's time to make our forum more easily skinnable. Do you have any suggestions?

A few things to look at:

how should site administrator change/customize skin?
what naming conventions to choose for id and class names
what elements to pick as "application native" and which - leave them as part of local customization?
how to make javascript that is part of UI automatically work in new skins?

edit: sorry used some made up terminology. by "native" I mean the "core" elements. For example I would consider question title a "core" element, but any layout elements as belonging to local customization - any containers that package say question title, tool links - non-mandatory. That way we could clearly mark which elements are key, and which are up to the skin designer.

edit 2: we should probably limit element lookup in javascript to those "core" elements only - that way it will be easier to guarantee that skin javascript will work - another good reason to mark those up clearly.

13.2k

Evgeny

updated 2010-05-06 20:43:57 -0600, asked 2010-05-06 13:42:33 -0600

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

2 Answers

Sort by

oldest

newest

most voted

how should site administrator change/customize skin?

I think the current way skins are customized is fine. The template system is easy to understand, and Django's cascading mechanism (i.e. if a file isn't there in the custom template, load it from the default directory) is great. I personally am also fine with the skin being defined in a config file. Once there's an admin tool, it's of course also nice to have it there as a drop-down menu, but it's not really a priority IMO.

what naming conventions to choose for id and class names

I think it pretty much doesn't matter as long as they are consistent, and written down in the Wiki.

I would propose to make a choice between Camel Case and underlines:

.MainQuestion or .main_question

there are arguments for and against both of them. Using underlines and small caps prevents case errors that are often easy to overlook.

Other than that, I think class names should be as short as possible, and be defined by function (and not by properties).

.YellowBox No! .InfoBox yes!

One thing that should be decided early on is whether we're going to use multiple classes. Using more than two classes breaks in IE6.

Multiple classes would be a great tool. Consider

    <div class="InfoBox LeftMenu Warning">

it would be possible to split CSS rules that generally apply to Info boxes, rules that apply to Info boxes in the left hand menu, and Info boxes that are warnings into three reusable classes.

We are going to want to support IE6 in the standard template, though, I presume. Sadly, it still has a considerable market share.

what elements to pick as "application native" and which - leave them as part of local customization?

Can you make an example of an element that could be part of the local customization? I'm not sure I understand this entirely.

how to make javascript that is part of UI automatically work in new skins?

This is a very good question. If I understand Django's templating system right, it would be possible to have a common.js in the default template. As long as people don't overwrite that with a local common.js in their template, the default file is used. Is this correct? If it is, I would suggest to maintain a core JavaScript directory that is directly connected with the JavaScript framework used.

/default/media/js/askbot_core/jquery.js
/default/media/js/askbot_core/org.askbot.editor.js
/default/media/js/askbot_core/org.askbot.utils.js
/default/media/js/askbot_core/...

people looking to customize their template will be told not to create a askbot_core directory so the one from the default template can be used (and updated). Should people, however, want to fork the JavaScript core (e.g. in order to use a different JS framework) they can override the askbot_core directory completely (at their own risk).

Would this be a workable idea? I'm still a ... (more)

590

Pekka

answered 2010-05-06 15:51:41 -0600

edit flag offensive 0 remove flag delete link

Comments

cool, what about common prefix for "our" class and id names? and should we use different naming conventions for classes and ids? Say ab_logo_id - would be ID and ab_logo would be class.

Evgeny (2010-05-06 17:49:00 -0600) edit

I think common prefix is a good idea - that reduces chance of clashing definitions - like we had for tag between wmd text editor and our style.css. Plus it will add clarity for the skin designers as to which id/class belongs to askbot and which does not.

Evgeny (2010-05-06 18:02:38 -0600) edit

regarding core javascript directory - actually have skin called "common" - that's where all the core scripts could go.

Evgeny (2010-05-06 19:40:55 -0600) edit

@Evgeny a common prefix is a great idea. I'm in favour of `ab_`. Re "common": Yes, that was the skin I meant :)

Pekka (2010-05-07 02:31:51 -0600) edit

How about ab_id_logo for IDs?

Pekka (2010-05-07 02:32:12 -0600) edit

add a comment see more comments

Regarding cascaded skins - they are not part of django per se, I've built that system for the forum.

Its weak point is that it makes possibility for two kinds of skins - the "full" ones that have all the files and "lazy" ones that have only some files. They are not the same because you cannot inherit from the "lazy" template in the same way (and it's actually impossible), yet they are stored the same way and may confuse people that they are equivalent in their function.

Secondly we have only one full skin - but I imagine that there might be several - e.g. with different layouts. If we want to support more than one base skin then we need two variables to define skin: name of full base skin and name of "lazy" one.

I thought that it would also be nice to upload media images through the admin UI (something that less tech savvy users will probably like) - so that is asking for another layer for media resolution on top of "lazy"->"full": "uploaded"->"lazy"->"full". However for the templates we'd leave "lazy"->"full". Or "uploaded"->"full" if lazy skin is not defined.

An unsolved issue is resolution of media files in javascript. Currently javascript is pulling media from the skin - i.e. your customized skin - there is no cascaded fallback, that's why you have to copy at least all media files from default into your directory or replace them all with your files. However, media is resolved correctly on the server side. I gues we'll have to provide a javascript media lookup map which has correct url for each media file.

13.2k

Evgeny

updated 2010-05-06 19:36:56 -0600, answered 2010-05-06 18:01:02 -0600