You'll find on this page documents that will help you learn, use and develop with Tahchee.
Cassidy manual is included below for your on-line reading pleasure !
Writing CSS is not always an easy task, especially when you have to think about naming and organizing your classes. Writing a simple CSS is usually an easy task, but when your site evolves, you quickly run into problems such as styles leaking from one element to another–and that's not to mention the headaches you'd have with IE-compatibility.
The goal of this document is to provide general and specific guidelines to allow people who develop rich web applications to get their CSS written right. We've analysed the CSS files of a couple of major websites, and we were surprised by the inconsistency of their CSS rules, suggesting that most of web developers grow CSS in an ad-hoc manner rather by sharing common guidelines.
The scope of this document is to propose a CSS framework that covers the following domains:
Here are the goals we tried to follow when designing this CSS framework:
The CSS framework is separated in two different layers:
Before going into the detail fo these layers, we'll detail the naming convention which is the foundation of the CSS framework.
Names are important, and as the studywe made shown it, most major web sites have an inconsistent naming of their CSS rules. Inconsistencies generally lead to ambiguous naming, name clases (as CSS has no notion of namespace) and in the end, bugs which are often difficult to track… it's the usual story in software engineering anyway.
The goal of this section is to lay out a sound base on which we'll build the CSS framework. Analyzing the different types of elements that one could have in a web page, we found the following categories:
<p>, <a>, <ul>, <li>, etc.<message> tag, you'd use something like '<div class="message">'. These classes typically denote important element which are specific to your application.divs in the resulting HTML pages.clearfix class for fixing use of floating elements, or things such as bigger, smaller, two-columns, etc.odd, even to indicate wether the element has an odd or even index. Conversely, you could use classes such as first and last to qualify the first and last elements of this list.button to indicate that a particular tag is to be rendered as a button.:hover selector and JavaScript allows the classes to change dynamically. We often see classes such as selected, current, dragged, dropped being used to denote elements that are involved in some kind of interaction.Looking into the details of more advanced web applications, we also identified the following categories:
So in essence, we have the following kind of elements:
p,'ul','li',…) .message, .user, …) .button, .dialog, …) .signup, .login, …) .name, .date, …)Which can be annotated in different ways:
.page,'.area', …) .smaller,'.hidden', …) .first, .last, .empty,…) .current,'.dragged','.dropped',…) .showThisDialog, .doThisOperation, …)Considering names we decided to take into account the following requirements:
And here is the naming convention we propose:
lowercase, consisting of a single word.lowercase, consisting of a single word such as first, last, etc.lower-case, optionally prefixed by an application specific prefix (like acme, acme-message, etc).lower-case prefixed by a common prefix. We suggest w as the prefix (like w-button, w-dialog)..w-dialog .w-button as opposed to .w-dialog-button.CamelCase, because they usually correspond to a class with the same name in your JavaScript application. For instance, you could have a MessageList JavaScript class/prototype, which HTML view component would have the MessageList CSS selector.NavigationBar) should used HTML ids instead of CSS classes (this would be #NavigationBar instead of .NavigationBar)mixedCase, because they often correspond to a property of an object. So imaging you have a User class with firstName and lastName properties. The CSS selectors would be .User .firstName and .User .lastName. We recommend the out- common prefix to denote that these selectors will be used as “out paramaters” by the JavaScript application. So the selector would rather be .User .out-firstName instead of .User .firstName. This makes it easier to spot and find which elements are used as placeholders.mixedCase (there is either a property or a method representing the read operation in the JS widget class), using the in- prefix to denote that they're used as input. So if you have a user signup form you'd have 'in-firstName', and 'in-lastName' classes to indicate which parts of the HTML documents should be used as inputs by the widget.mixedCase, prefixed by the do- prefix to denote that an operation will be trigger. Their name should be the same as the corresponding operation. If a button shows the sign up dialog, its class should be op-showSignUpDialog.mixedCase prefixed by on, such as on-focus, on-drag, on-drop, etc.As you can see, we use lowercase, lower-case, mixedCase and CamelCase for different kind of elements, and we used prefixes to denote the different roles of the elements and prevent name clashes. In practice, these conventions will avoid too long CSS selectors, and allow a natural prioritization of styles:
/* Generic widgets styles */
.w-dialog { ... }
.w-dialog .w-button { ... }
/* Widget instances styles */
.SignUp .w-button { ... }
.Alert .w-button { ... }Here is a summary of these conventions
| Elements | ||
| Specific element | lower-case | message, status, book |
| Widget type | w-lower-case | w-button, w-dialog, w-panel |
| Sub widget type | w-parent-lower-case | w-dialog-operations, w-filter-results |
| Widget instance | CamelCase | SignUp, NavigationBar, MessageList |
| Annotations | ||
| Formatting | lowercase | small, hidden, clearfix |
| Meta | lowercase | empty, first, last |
| MVC Input | in-camelCase | in-firstName, in-lastName |
| MVC Placeholders | out-camelCase | out-firstName, out-lastName |
| MVC Triggers | do-camelCase | do-addUser, do-showDialog |
| MVC Events | on-camelCase | on-drag, on-focus |
So this was a bit long, but vital to get the foundation of our CSS framework right. The next sections will propose a list of default CSS classes, describe what they mean and when they should be used.
The core layout classes make it easy to express the structure of your pages, allowing to quickly shape the big areas and sections of your page, and provide hooks that the designers can use to make things pretty as soon as possible.
The content of a page can be decomposed into four main types of elements:
PAGE .=============================================================. || || || AREA || || +----------------------------------------------------+ || || | | || || | | || || +----------------------------------------------------+ || || || || || || AREA || || +----------------------------------------------------+ || || | SECTION | || || | +------------------------------------------------+ | || || | | | | || || | | | | || || | +------------------------------------------------+ | || || | | || || | SECTION | || || | +------------------------------------------------+ | || || | | GROUP | | || || | | +--------------------+ +--------------------+ | | || || | | | | | | | | || || | | | | | | | | || || | | | | | | | | || || | | +--------------------+ +--------------------+ | | || || | +------------------------------------------------+ | || || | | || || | SECTION | || || | +------------------------------------------------+ | || || | | | | || || | | | | || || | +------------------------------------------------+ | || || +----------------------------------------------------+ || || || || AREA || || +----------------------------------------------------+ || || | | || || +----------------------------------------------------+ || || || .=============================================================.
All these elements can have the following content
.page|area|section|group
.header
.title
.body
.footerWhere .header contains header information (generally the .title) and a '.body' that takes the content. It's good to enclose the content in a '.body' instead of putting it as a direct child of the page/area/section/group because you can set 'padding' without affecting the 'width' of the container. The same for '.header' and '.footer'.
You'll sometimes want to layout structural elements content so that some part will be to the left or to the right. To do this, Cassidy provides the following selectors:
.left for left-positioned layout .middle for middle/center positioned layout .right positioned layout+-------------------------------------------------------------+ | LEFT MIDDLE RIGHT | | +-------------+ +--------------------------+ +------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-------------+ +--------------------------+ +------------+ | | | +-------------------------------------------------------------+
It is sometimes useful to have add hooks for specific decorative elements. If you want to use bitmaps to style the edges of a container, you'll need the following classes to hook your style definitions:
.N for “north” .S for “south” .E for “east” .W for “west” .NE for “north-east” .NW for “north-west” .SE for “south-east” .SW for “south-west” NW----------N----------NE
| |
| |
W E
| |
| |
SW----------S----------SEIt is generally good to enclose these decorations in a containing .decoration class, so that you can easily switch them on or off:
.decoration
.N
.S
.E
.W
.NE
.NW
.SE
.SWHere is a complete example of how to use the above selectors:
<body id="SiteMainPage" class="page">
<div id="Navigation" class="area">
<div class="body">
...
</div>
</div>
<div id="Content" class="area">
<div class="header"> </div>
<div class="body">
<div class="section Articles">
<div class="header">
<div class="left"> </div>
<div class="middle"> </div>
<div class="right"> </div>
</div>
<div class="body">
<div class="left"> </div>
<div class="middle content">
...
</div>
<div class="right"> </div>
</div>
<div class="header">
<div class="left"> </div>
<div class="middle"> </div>
<div class="right"> </div>
</div>
</div>
<div class="footer"> </div>
</div>
</body>/* Structural elements */
.Content .header { ... }
.Content .body { ... }
.Content .footer { ... }
/* Strucutral elements layout */
.Articles .header .left { ... }
.Articles .header .middle { ... }
.Articles .header .right { ... }
.Articles .body .left { ... }
.Articles .body .middle { ... }
.Articles .body .right { ... }
.Articles .footer .left { ... }
.Articles .footer .middle { ... }
.Articles .footer .right { ... }It is common to use a generic CSS classes to have a specific effect on the rendering elements. These are classes that will help laying out elements:
<ul> padding, margin and list style type will be none. You also may want to give more hints about the way you are going to render an element:
When you are implementing lists in HTML, you'd probably want to give hooks to style these lists in the most flexible way. Here are some classes to be used with elements placed in sets or lists:
Now here are some classes that help indicate the state of the current element:
The first group of widget classes that we want to provide are classes that help organize specific widgets. These are usually called containers, because they are made to contain widgets. Here are the classes we propose:
We also provide more specific containers that hold elements in different ways:
Every container can of course use any of the classes mentioned before, especially the structure annotation classes such as header, body and footer, which make styling even easier.
The next group of widget classes that are useful are classes that allow interaction with the user, such as buttons and forms.
This may seem like a lot of classes, but buttons are actually a very, very important part of the UI, and thus deserve adequate classes to differentiate them.
Another important set of interaction elements are forms, and they have to be structured in different sections:
label and inputs) inputs or not) As a general principle, interaction widgets are used within containers. So you can always redefine their appearance by prefixing them with the specific or generic container class. For instance, an AlertBox buttons could be styled like:
.AlertBox w-button { ... }
.AlertBox w-button-default { ... }Specific form elements (checkboxes, text areas, etc) can be styled using the existing HTML elements as selectors. You might also have a look at the interaction annotations that specify classes that allow to denote errors and the state of different fields in the form.
One of the cornerstone of modern application UI design is to provide good feedback when the user is doing things (but not as much as say… Windows ;). There are a number of different types of feedback widgets that you can use:
Events classes denote what's currently happening for a specific widget. These classes denote the effects of user interaction, so you'll find a mix of state-related annotations and some more classic UI interaction events (minus focus and hover which have CSS pseudo-selectors for this):
Here are the classic drag-and-drop events:
Here are generic states that can results from events (especially with forms):
These classes should be dynamically added and removed (after some finely tuned delay) to produce nice UI effects.
We've seen all the different parts of the Cassidy CSS framework, so here comes the time of the mandatory summary of the selectors. This will help you have all the selectors at once.
| Core | ||
| Content structure | page, area, section, content, title | |
| Content decoration | header, body, footer, left, middle, right | |
| Layout formatting | clear-left, clear-right, clear-both, absolute, relative, centered, no-list, clearfix, hidden | |
| Layout hints | bigger, smaller, standard, highlighted | |
| Position meta | first, last, even, odd, current, previous, next | |
| State meta | empty, optional,'required', 'disabled' 'fake', 'template' | |
| Widgets | ||
| Containers | w-panel, w-group, w-window, w-dialog w-list, w-set | |
| Forms | w-form, w-form-description, w-form-example, w-form-group, w-from-group-emphasis, w-form-group-optional, w-form-row, w-form-input, w-form-submit | |
| Interaction | w-button[-default|-small][-disabled], w-button-label | |
| Feedback | w-tooltip, w-hint, w-info, w-notification, w-alert, w-question | |
| Events (state) | on-select, on-deselect, on-change, on-empty | |
| Events (DnD) | on-drag, on-dragOver, on-dragOverAccept, on-dragOverRefuse', 'on-drop', 'on-dropAccept', 'on-dropRefuse' | |
| Events (status) | on-error, on-warn, on-process, on-success | |
HTML browsers do not offer all the same defaults, so it's a good idea to redefine them. Here is a list of CSS selectors that you should fill-in to have a clean base of your website:
/* Core HTML elements */
html { ... }
body { ... }
table { ... }
table tr td { ... }
ul { ... }
ol { ... }
ul li { ... }
h1 { ... }
h2 { ... }
h3 { ... }
/* Links */
a:link { ... }
a:active { ... }
a:hover { ... }
a:visited { ... }
/* Forms */
form { ... }
form label { ... }
input[type=text] { ... }
input[type=password] { ... }
input[type=button] { ... }
input[type=submit] { ... }
textarea { ... }Redefining this set of styles is sufficient to get a first cut at the styling of your web site.
Naming conventions are important to ensure consistency in any framework.
Problems with IE:
.A.B will apply do both A and B class elements instead of elements with both A and B classes. This means that you have to do a specific class for that.Example: Facebook
lower_case lower_case app_switcher, app_switcher_button, app_switcher_selected dashboard_header and dh_titlebar, dh_links .dashboard_header .dh_titlebar Example: LastFM
CamelCase, mixedCase, alllowercase and lower_case LastAd_FooterLeft, LastAd_Mid, LastAd_Top CamelCase or mixedCase (most) or alllowercase CamelCase classes are used for top-level containers sometimes corresponding to ids (.LastAd and #LastAd) eventPoster and eventPosterTitles .dashboardWidget, .dbwContainer Example: Netvibes
mixedCase, or lower-case mixedCase too, sometimes lower-case, rarely lower_case or lowercase #feedReader .feedContent) nv-tabListNav, nv-thumbnailedList Example: Reddit
lowercase lowercase too Example:Ext-JS
lower-case and lowercase ids collapsedimg_forumhome_activeusers, #collapseimg_forumhome_birthdays lower-case x-dlg-bd, x-dlg-ft, ext-mb-input, ext-mb-progress-bar, ux-startbutton-center) .ux-taskbuttons-scroller-left instead of .ux-taskbuttons .scroller-left) Example: Blueprint CSS
lowercase ids scarcely lower-case align-left, align-center, align-justify, etc) Example: WYMstyle
lower-case and sometimes lower_case ids nav-lang, nav-pri, nav-sec lower-case float-left, float-right, force-new-line, etc) id attributes in your HTML documents,
as HTML ids will populate your browser JavaScript namespace,
giving the opportunity to make name clashes. Usually, the rule
is that document ids won't override global declarations in your
JavaScript namespace, even if an HTML element id is declared
after your global variable.