Sakai 3 skins again

Responding to a message from Chris Roby to the Sakai Nakamura list, I took a test run through the process of tailoring the look and feel of Sakai 3 to match the branding needs of an institution and the results were  very gratifying. Very few lines needed in skins/default/skin.css (less than 60!) to produce something acceptable that represents the University of Michigan clearly and follows the institutional web style guides.  Only 4 new or modified images (that go in a new folder skins/default/images) were needed as well. Here is a screenshot.

Some possible improvements

1) skin CSS linked to too soon

skins/default/skin.css is linked to before other CSS styling canvases that could be considered important canvases for institutional skins – luckily these can be trumped in the skins css by ratcheting the specificity in skins/default/skin.css, ie: topnavigation.css is linked to after skins/default/skin.css and trumps the style for #general_search_container in skin.css unless one uses a contextual selector with more specificity: #topnavigationcontainer #general_search_container instead of #general_search_container

This is somewhat clumsy and not very obvious. Did not have to resort to !important but can see that happening if the later CSS selector is too specific to trump.

I notice for example that in the Wiki documentation !important is used to change the color of links – this is a symptom.

In other words: it may be a good idea to include skins/default/skin.css last.

2) side effects from overrides

There is a flash and jiggle of previous styles that is very apparent if the palette of skins/default/skin.css or the position of an element affected there is at variance with the values of any of the previous core selectors. This flash and jiggle is more pronounced if the connexion is slow or there is load or the sheets are not cached.

It may be a good idea to leave style “gaps” in the core sheets and supply a skin/example sheet that fills them in – this would accomplish several things:

  1. avoid possible flash and jiggle;
  2. identify clearly what are good skinnable canvases/targets;
  3. separate style concerns into core sheets (generic substance), skin sheets (institutional style);
  4. establish a sort of contract: “address the selectors in the skin/example and everything will be simple and you will not have to touch anything else probably,” reducing the task of the adopter to painting by numbers sort of.

3) facilitating broad strokes changes to match the institutional style guide.

Links are a good example that tend to spark a lot of controversy. One of the gaps in the core sheets may be link color and decoration. This would be addressed in the skin sheet, which would address the generic link (and the pseudo classes), and also the ones that are identified by class/id or context. This is very hard as everyone’s definition of what should be in the skin scope will be different. But identifying what a core set of skinnable possibilities will cover the majority of the cases.

4) increasing the scope of the core sheets and decreasing the scope of widget/page sheets

This would also be very helpful – specially since the widget sheets are loaded last – migrating all rules that should be generic to the core sheets would allow a skin sheet to affect anything it needs to affect with more ease (because it could trump core sheets without any skullduggery). I see this is happening  (SAKIII-1800, SAKIII-1803), which is great.  For example in order to eliminate the rounded corners in the main content area this was needed in the skin:

.header .fixed-container,
.header .fixed-container .decor,
.search-container .content_search .fixed-container,
.search-container .content_search .fixed-container .decor,
.account_preferences .header .fixed-container
  {
    background-image: none;
  }

Since it is the same graphic element anywhere it happens, it might best be served by a core sheet, once.

These points all revolve around separating core and page from skin, core and page from widget, skin from widget. 1) above is moot if we get the widgets out of the business of styling generic items best left to the core; 2 and 3 are moot if the core avoids declarations best left to the skin and so forth.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: