Look and Feel

There are 4 tasks related to skinning and CSS.

Skinning Infrastructure - Tom Trenka, Torrey, Dylan??

Goals

• ability to define multiple skins (look and feel for widgets). A skin applies to all the widgets, not just a single type of widget.
• user can pick the skin via djConfig or similar variable
• default skin

Strategy

Each theme will exist in it's own directory, separate from the widget definitions

src/themes/aqua/...
src/themes/windows/...

The theme consists of three things:

1. CSS (ex: font, background color, etc.)
2. images (ex: shape of buttons or tabs)
3. altering javascript of base class (ex: fade out rather than just erasing suddenly) (post 0.3?)

CSS

• make clean separation in dojo between "skinning CSS" (ex: color: red) and "intrinsic CSS", style that is essential to a widget working correctly (ex: position: absolute). All the skinning CSS should be in a src/themes directory, and all the intrinsic CSS is specified in javascript/javascript template file? or do we keep the templateCSSPath variable and use it for intrinsic CSS?
• each theme contains a file for common CSS attributes plus files for widget specific attributes
  src/themes/[themename]/common.css + [widgetname].css
• common.css should always be loaded before subclass.css

I'm envisioning something like this.

src/themes/aqua/common.css

.aquaBase {
	color: blue;
	font: times-roman;
}

src/themes/aqua/floatingPane.css

.aquaFloatingPane .titleBar {
	background: #a0a0a0;
}

Dom tree generated by floating pane widget (when aqua theme is loaded)

<div class="aquaBase aquaFloatingPane">
	<div class="titleBar">this is the title</div>

	...
</div>

Images

• images will need to be included in the theme directory, as opposed to the template dir

Javascript

src/themes/[themename]/widgetName.js

gets mixed into the class. That'll let you change the behavior of the widget. Stuff like fading in rather than just appearing. Unclear if src/themes/[themename]/widgetName.js is a mixin or a subclass of src/widget/widgetName.js

There was some some concern that we couldn't tackle this one for 0.3 release, and we should start with just CSS, or at the most CSS+images.

Deferred

The tasks below seem useful but too much to bite off for the 0.3 release.

• mix and match of themes

User Custom CSS

Goals

• Ability to set the style (font, color, etc.) of an individual widget instance. Currently it's quite difficult to set the style for just one instance of a TabPane without affecting the other TabPanes on the page.
• Mark one or more widgets as "class1", and then specify CSS info for all "class1" widgets.
• Make it easier to specify CSS for all TabPanes (dojo specifies a default skin for widgets; it's hard to override those rules short of modifying the dojo source CSS files. This is because the dojo CSS files are included last and thus take precedence over user defined CSS rules. User has to make his rules more specific...)

Strategy

• widget takes css classname argument, and attaches it to this.domNode

   <style> .myCssClassName { color: red; } </style>

...
   <div dojoType="LayoutPane" outputClass="myCssClassName">...</div>

• maybe can specify classname to attach to each of the subnodes in a widget? (ex: for floating pane, titlebarClass, contentPaneClass). SortableTable is like this. Not sure on the necessity of it. Maybe the CSS patterns matchers can be designed such that it isn't necessary