Syntax

The CSS syntax conventions used with Hawidu CSS to keep the markup manageable. ##Rules Rules should be entirely on a single line, with no extraneous spaces. A space between selectors, such as

ul li{}

is necessary for CSS to evaluate properly, but spaces after commas or before braces are not. Each nesting level is a single tab character.

ul{}
	ul li{}

By using a text editor more advanced than notepad, you can tweak the line wraps and tab display to your liking.

##Selectors Syntactically, selectors should have a basis either in the HTML specification being used or a semantic naming convention. Base HTML tags are preferred to classes, which are preferred to IDs, even when not included in the base library. For instance, <del> is not styled in default Hawidu CSS, as the user agent defaults for most major browsers work as expected, but if your application warrants it,

<del>example</del>
del,s,strike{text-decoration:line-through;}

is preferable to crap like:

<span class="strike">example</span>
.strike{text-decoration:line-through;}

which indicates nothing to anyone except sighted users. Additionally, it is best practice to use classes for styles so they can be reused.

#Declarations All declarations, regardless of their position in a rule, should end with a semicolon. This is helpful for when you go back and edit things; one less reason for a bug to show up.

###Properties Declarations should be alphabetized by property name within each rule. It's up to you whether you mindfully enter your decs this way or cycle through your sheet afterward to do it. The idea is just to make it easy to revisit things. Firebug will tell you which line something's on and re-orders the properties in the inspector. Good alphabetization will make it fast once you're in the file.

###Except not really

• Browser-specific properties start with a dash. Hawidu CSS lumps these together at the beginning, then orders them alphabetically by the prefix following the dash
• It's also good practice to break alpha order for commonly-shorthanded decs. In that case, you'd want them in top->right->bottom->left order, just like their shorthand counterparts

###Values All common shorthand declarations are acceptable except font. Here's some finicky junk that can be helpful in multi-developer and Hawidu CSS contributor circumstances:

• Use 3-character hex shorthand only when all the characters in the string are the same (#ccc but not #fc4)
• Use 1, 2, and 4-value shorthands for margin, padding, and other t-r-b-l values. 3 is potentially confusing: don't commit it

##Comments Major sections are separated with

/*--Section Name--*/

Subsections are split with

/*-Subsection-*/

And sub-subsections are

/*Sub-subsection*/

There are no plans for hawiducss core to have more than three levels of categorization.

The base sheet relies on the Google Code wiki documentation for explanatory comments. You should probably annotate your own stuff if you find it helpful for yourself and others on your development team. If you create an annotated copy of a particular hawiducss version, perhaps we make a branch or clone for an annotated special edition.