CSS compatibility
All other target browsers except IE6 support CSS2.1 selectors, notably :hover and child-selector (>). In order to make our HTML structure more efficient and simple, all unnecessary DIV tags and classnames should be removed from the document tree.
We can get pretty close to that goal by simply using the CSS selectors mentioned. The only real thing to do is to "hack" IE6 to comply.
/IE7/ library
The :hover effect is simple to reproduce in IE6 with a little JavaScript? (manipulating the document.styleSheets object), but the child selectors are a bit of a pain.
There is a ready-made solution available, called "IE7" (http://dean.edwards.name/IE7/). It works well with medium sized static pages, but with dynamically injected HTML and the size of our CSS files it becomes almost unusable.
We could write our own implementation with less functionality that would be more agile, but I doubt it will be worth it. I think we'll just stick to naming our CSS classes in a consistent manner to avoid unwanted clashing.
JS :hover solution for IE6
This involves using a separate .htc file for IE6 (CSS behaviour-attribute, not recognized by other browsers). E.g.
.button {
behaviour: url(csshover.htc);
}
TODO: The performance hit of this is still unclear.
Conclusion
Don't implement child-selector support, add :hover support (either leave IE6 without or use HTC hack).
CSS classname conventions
To keep our HTML structure clean, we need company-wide instructions how to name different components classnames. It should also be so intuitive, that a developer/designer could almost guess the different elements without looking at the HTML structure.
Because of the initial decided theme structure (5.6.2007, still subject to change, more on that later), we don't really have to care about theme inheritance with CSS. This frees us more or less from CSS selector overrides and keeps the selectors rather simple (affects CSS performance also).
The idea of using the real power of CSS, cascading, is brilliant, but turns against us real quickly. If we use generic classnames like "border", "pad" or "layout" we soon end up overriding those styles in many different components. Generic classnames that imply behaviour may be used, e.g. "show", "hide", "disable" etc. These utility classes should be really light, containing at most three different attributes (except when defining attributes that are different in different browsers, like opacity).
Proposals
1. All classnames are written in lowercase
No technical reason, just for pure consistency.
2. All classnames start with prefix "i", regardless of context
This means that not only the root node of a component has a classname that starts with "i" but all subnodes which have classnames also start with "i". E.g. "i-panel", "i-panel-caption" etc.
This removes the possibility of classname clashings with components residing inside each other.
3. All classnames that belong to a certain component include the components name in the classname after the "i" prefix, separeted with a dash E.g. "i-panel-content"
This will prevent style definitions from flowing in inappropriate nodes (i.e. generic "content" vs. "i-panel-content"). This problem is really isolated to container components (layouts, panel, window, tabsheet, table etc.).
4. Use the least specific selectors you can
E.g. use ".i-textfield-input" instead of ".i-textfield .i-textfield-border .i-textfield-input". Adding more classnames in the selector won't affect anything other than performance.
Eases the task to override styles if necessary.
5. Don't use tagnames in selectors. Exceptions apply for form elements (INPUT, SELECT, BUTTON etc.), but avoid these as well.
Simply because they add unneeded priority to the selector. And if the implementation someday changed a node from DIV to SPAN, the selector would be broken.
TODO: how to handle different setStyle parameters from Java side.
Component CSS structure
As said earlier, the structures should be as intuitive and as simple as possible. Following exceptions are applied:
1. One additional, purely presentational, DIV/SPAN element is allowed per component structure to allow more advanced styling if needed. This DIV/SPAN element has a classname of form "i-componentname-deco"
For example to allow rounded corner implementations in the future:
<div class="i-textfield"> <span class="i-textfield-caption">Text field</span> <span class="i-textfield-deco"><input type="text" class="i-textfield-input" /></span> </div>
Caption nodes
The current consencus seems to be that general component preferences, such as captions, descriptions, icons and error messages, should be extracted from the actual component. This will greatly easy the task of creating a new component, when the developer doesn't have to worry about generics. This means that the following structure proposals won't include any related elements in elements that don't want to handle these generics themselves (e.g. textfield, datefield, table, tabsheet...).
Proposals
Label (could use original GWT)
<span class="i-label">Label text</span>
Textfield (could use original GWT, but we lose the label-tag behaviour then, which can be a usability issue)
<div class="i-textfield"> <input type="text" class="i-textfield-input" /> </div>
Button (inherit GWT-button)
<button class="i-button">Button caption</button>
Fancier buttons can be made with either additional styles or inheritance. A HTML prototype is available (ask Jouni).
Checkboxes (inherit GWT-checkboxes)
TODO
Link
<a href="..." class="i-link">Link text</a>
Datefield
TODO (already implemented, copy the structure here)
Select (drop-down)
<div class="i-select"> <select class="i-select-select">...</select> </div>
Select (radiogroup)
<div class="i-select i-select-optiongroup"> GWT native radiobuttons/checkboxes ... </div>
Select (twincol)
<div class="i-select i-select-twincol"> <select size="10" class="i-select-select">...</select> <span class="i-select-twincol-buttons"><button><<</button> <button>>></button></span> <select size="10" class="i-select-select">...</select> </div>
Table (scroll table)
TODO
List A simple style attribute for table (reuse table styles as much as possible)
TODO
Tree
Copy structure from 4.0 version.
OrderedLayout? (vertical)
<div class="i-orderedlayout"> <div class="i-orderedlayout-cell"></div> ... </div>
OrderedLayout? (horizontal)
<table class="i-orderedlayout"> <tr> <td class="i-orderedlayout-cell"></td> ... </tr> </table>
GridLayout?
Copy structure from 4.0 version.
CustomLayout?
Copy structure from 4.0 version.
Panel
<div class="i-panel"> <div class="i-panel-caption">Panel caption</div> <div class="i-panel-content">Panel content</div> <div class="i-panel-deco"></div> </div>
TabSheet?
Use GWT native. Some classnames changes, others can't be changed.
Window (inline)
Copy structure from 4.0 version.
Embedded object
Copy structures from 4.0 version (but revise).
Upload (revised version of 4.0 structure)
<div class="i-upload"> <iframe class="i-upload-target" /> <form class="i-upload-form"> <input type="file" class="i-upload-file" /><input type="submit" value="Upload" class="i-upload-button" /> </form> </div>
How we handle .setStyle("foo")
In the DOM structure, add the style as a classname as all the rest (i.e. "i-component-style") to the root node of the component.
Example:
textfield.setStyle("foo");
results in
<div class="i-textfield i-textfield-foo"> <input type="text" class="i-textfield-input" /> </div>
Theme package structure
The "base" theme for 5.0 is packaged tightly within the Toolkit, and will not be clearly visible to developers. All component specific CSS and images will be packaged in the source folders of the components. The look and feel will most likely be in lines of current "corporate" theme. This will be the only default theme provided with the product. The word "theme" is slightly incorrect here, because the default implementation and look&feel isn't a theme per se, it is more like a foundation to build upon.
All the different CSS files will be catenated by the server into one file which is sent to the client.
Inheritance
Theme inheritance will be more restricted. It will be possible to inherit client-side implementations of components (Java-classes), but the visual side of these components is totally separated from the behaviour.
A "theme" consists only of a specific CSS file and the accompanying images. No CSS inheritance is used. Developers can override the style declarations they wish and the rest will use the packaged default look&feel. If a developer wishes to make the whole application use a specific look, he must override all the styles and images. If an application has several similar themes (color variations, like -removed-), the developer must create a new CSS file for every variation, duplicating the whole file, even to make one simple difference in another theme.
Images aren't inherited either (the servlet won't check any "parent theme" for missing images). Icons are inherited.
