Mind Tree

Well, I guess I’m going to work backwords. There are three layers to the frontend; behaviour, presentation and markup. We’ve done behavior so we’re onto presentational now. CSS Frameworks have been all the buzz lately, we’ve had ones that use python ways of code then regenerate it as css, ones that are specifically for forms and an awesome one which is just for styling print!

Personally I find frameworks to much hassle, I have my own little framework but that is only really 20 or so lines. I might share it with all of you in the coming weeks if you would like it. Now here they are!

1. 960 Grid System - The 960 Grid System is an effort to streamline web development workflow by providing commonly used dimensions, based on a width of 960 pixels. There are two variants: 12 and 16 columns, which can be used separately or in tandem.

2. Blueprint CSS - Blueprint is a CSS framework, which aims to cut down on your CSS development time. It gives you a solid CSS foundation to build your project on top of, with an easy-to-use grid, sensible typography, and even a stylesheet for printing.

3. Hartija - The owner of Hartija describes it as a “universal Cascading Style Sheets for web printing”. It’s extremely customizable and very user friendly.

4. Formy CSS - Formy is mini CSS Framework for building web forms.

5. Clever CSS - CleverCSS is a small markup language for CSS inspired by Python that can be used to build a style sheet in a clean and structured way. In many ways it’s cleaner and more powerful than CSS2 is.

6. SenCSS - SenCSS is a sensible standards CSS Framework. This means that SenCSS tries to supply standard styling for all repetitive parts of your CSS, allowing you to focus on the fun parts. In that sense, senCSS is a bit like a large CSS Reset.

7. Elements -

Elements is a down to earth CSS framework. It was built to help designers write CSS faster and more efficient. Elements goes beyond being just a framework, it’s its own project workflow.It has everything you need to complete your project, which makes you and your clients happy. Read the Overview for more information.

8. LogicCSS - The Logic CSS framework is a collection of CSS files and PHP utilities to cut development times for web-standards compliant xHTML layouts.

This is just the tip of the iceberg, there are tones more css frameworks out there. I plan on releasing one for this site.

• Leave a comment... (0)

Once your latest project is finished, you are very likely to forget the structure of the project’s layout, with all its numerous classes, color schemes and type setting. To understand your code years after you’ve written it you need to make use of sensible code structuring. The latter can dramatically reduce complexity, improve code management and consequently simplify maintainability. However, how can you achieve sensible structuring? Well, there are a number of options. For instance, you can make use of comments — after all, there is always some area for useful hints, notes and, well, comments you can use afterwards, after the project has been deployed.

Indeed, developers came up with quite creative ways to use comments and text formatting to improve the maintainability of CSS-code. Such creative ways are usually combined into CSS styleguides — pieces of CSS-code which are supposed to provide developers with useful insights into the structure of the code and background information related to it.

This article presents 5 coding techniques which can dramatically improve management and simplify maintainability of your code. You can apply them to CSS, but also to any other stylesheet or programming language you are using.

1. Divide and conquer your code

First consider the structure of your layout and identify the most important modules in your CSS-code. In most cases it’s useful to choose the order of CSS-selectors according to the order of divisors (div’s) and classes in your layout. Before starting coding, group common elements in separate sections and title each group. For instance, you can select Global Styles (body, paragraphs, lists, etc), Layout, Headings, Text Styles, Navigation, Forms, Comments and Extras.

To clearly separate fragments of code, select appropriate flags or striking comments (the more *-symbols you have in your code, the more striking a heading is). In the stylesheet they will serve as a heading for each group. Before applying a preferred flag to your code, make sure you can immediately recognize single blocks when scanning through the code.

However, this approach might not be enough for large projects where a single module is too big. If it is the case, you might need to divide your code in multiple files to maintain overview of single groups of code fragments. In such situations master stylesheet is used to import groups. Using master-stylesheet you generate some unnecessary server requests, but the approach produces a clean and elegant code which is easy to reuse, easy to understand and also easy to maintain. And you also need to include only the master-file in your documents.

/*——————————————————————
[Master Stylesheet]

Project:    Smashing Magazine
Version:    1.1
Last change:    05/02/08 [fixed Float bug, vf]
Assigned to:    Vitaly Friedman (vf), Sven Lennartz (sl)
Primary use:    Magazine
——————————————————————-*/
@import "reset.css";
@import "layout.css";
@import "colors.css";
@import "typography.css";
@import "flash.css";
/* @import "debugging.css"; */

For large projects or large development team it is also useful to have a brief update log and some additional information about the project — e.g. you can put the information about who is this CSS-file assigned to and what is its primary use (e.g. Smashing Magazine, Smashing Jobs etc.).

Additionally, you can include a debugging CSS-code to take care of diagnostic styling in case you run in some problems. Consider using Eric Meyer’s Diagnostic Styling as a debugging stylesheet to test your CSS-code and fix problems.

2. Define a table of contents

To keep an overview of the structure of your code, you might want to consider defining a table of contents in the beginning of your CSS-files. One possibility of integrating a table of contents is to display a tree overview of your layout with IDs and classes used in each branch of the tree. You may want to use some keywords such as header-section or content-group to be able to jump to specific code immediately.

You may also select some important elements you are likely to change frequently — after the project is released. These classes and IDs may also appear in your table of contents, so once you’ll need to find them you’ll find them immediately — without scanning your whole code or remembering what class or ID you once used.

/*——————————————————————
[Layout]

* body
    + Header / #header
    + Content / #content
        - Left column / #leftcolumn
        - Right column / #rightcolumn
        - Sidebar / #sidebar
            - RSS / #rss
            - Search / #search
            - Boxes / .box
            - Sideblog / #sideblog
    + Footer / #footer

Navigation      #navbar
Advertisements      .ads
Content header      h2
——————————————————————-*/

…or like this:

/*——————————————————————
[Table of contents]

1. Body
    2. Header / #header
        2.1. Navigation / #navbar
    3. Content / #content
        3.1. Left column / #leftcolumn
        3.2. Right column / #rightcolumn
        3.3. Sidebar / #sidebar
            3.3.1. RSS / #rss
            3.3.2. Search / #search
            3.3.3. Boxes / .box
            3.3.4. Sideblog / #sideblog
            3.3.5. Advertisements / .ads
    4. Footer / #footer
——————————————————————-*/

Another approach is to use simple enumeration without indentation. In the exampe below, once you need to jump to the RSS-section you simply use a search tool to find 8. RSS in your code. That’s easy, quick and effective.

/*——————————————————————
[Table of contents]

1. Body
2. Header / #header
3. Navigation / #navbar
4. Content / #content
5. Left column / #leftcolumn
6. Right column / #rightcolumn
7. Sidebar / #sidebar
8. RSS / #rss
9. Search / #search
10. Boxes / .box
11. Sideblog / #sideblog
12. Advertisements / .ads
13. Footer / #footer
——————————————————————-*/
<!– some CSS-code –>

/*——————————————————————
[8. RSS / #rss]
*/
#rss { … }
#rss img { … }

Defining a table of contents you make it particularly easier for other people to read and understand your code. For large projects you may also print it out and have it in front of you when reading the code. When working in team, this advantage shouldn’t be underestimated. It can save a lot of time — for you and your colleagues.

3. Define your colors and typography

Since we don’t have CSS constants yet, we need to figure out some way to get a quick reference of “variables” we are using. In web development colors and typography can often be considered as “constants” — fixed values that are used throughout the code multiple times.

As Rachel Andrew states, “one way to get round the lack of constants in CSS is to create some definitions at the top of your CSS file in comments, to define constants. A common use for this is to create a color glossary. This means that you have a quick reference to the colors used in the site to avoid using alternates by mistake and, if you need to change the colors, you have a quick list to go down and do a search and replace.”

/*——————————————————————
# [Color codes]

# Dark grey (text): #333333
# Dark Blue (headings, links) #000066
# Mid Blue (header) #333399
# Light blue (top navigation) #CCCCFF
# Mid grey: #666666
# */

Alternatively, you can also describe color codes used in your layout. For a given color, you can display sections of your site which are using this color. Or vice versa — for a given design element you can describe the colors which are used there.

/*——————————————————————
[Color codes]

Background:    #ffffff (white)
Content:    #1e1e1e (light black)
Header h1:    #9caa3b (green)
Header h2:    #ee4117 (red)
Footer:        #b5cede (dark black)

a (standard):    #0040b6 (dark blue)
a (visited):    #5999de (light blue)
a (active):    #cc0000 (pink)
——————————————————————-*/

The same holds for typography. You can also add some important notes to understand the “system” behind your definitions.

/*——————————————————————
[Typography]

Body copy:        1.2em/1.6em Verdana, Helvetica, Arial, Geneva, sans-serif;
Headers:        2.7em/1.3em Helvetica, Arial, "Lucida Sans Unicode", Verdana, sans-serif;
Input, textarea:    1.1em Helvetica, Verdana, Geneva, Arial, sans-serif;
Sidebar heading:    1.5em Helvetica, Trebuchet MS, Arial, sans-serif;

Notes:    decreasing heading by 0.4em with every subsequent heading level
——————————————————————-*/

4. Order CSS properties

When writing the code often it’s useful to apply some special formatting to order CSS properties — to make the code more readable, more structured and therefore more intuitive. There is a variety of grouping schemes developers use in their projects. Some developers tend to put colors and fonts first; other developers prefer to put “more important” assignments such as those related to positioning and floats first. Similarly, elements are also often sorted according to the topology of the site and the structure of the layout. This approach can be applied to CSS selectors as well:

    body,
    h1, h2, h3,
    p, ul, li,
    form {
        border: 0;
        margin: 0;
        padding: 0;
    }

Some developers use a more interesting approach — they group properties in an alphabetical order. Here it’s important to mention that alphabetizing CSS properties may lead to some problems in some browsers. You may need to make sure that no changes are produced as a result of your ordering manipulations.

body {
    background: #fdfdfd;
    color: #333;
    font-size: 1em;
    line-height: 1.4;
    margin: 0;
    padding: 0;
}

Whatever grouping format you are using, make sure you clearly define the format and the objective you want to achieve. Your colleagues will thank you for your efforts. And you’ll thank them for sticking to your format.

5. Indentation is your friend!

For better overview of your code you might consider using one-liners for brief fragments of code. This style might produce messy results if you define more than 3 attributes for a given selector. However, used moderately, you can highlight dependencies between all elements of the same class. This technique will dramatically increase code readability when you have to find some specific element in your stylesheet.

#main-column { display: inline; float: left; width: 30em; }
        #main-column h1 { font-family: Georgia, "Times New Roman", Times, serif; margin-bottom: 20px; }
        #main-column p { color: #333; }

You remember exactly what you did and can jump back in there and fix it. But what if you made a lot of changes that day, or you just simply can’t remember? Chris Coyier suggests an interesting solution for highlighting recent changes in your CSS-code. Simply indenting new or changed lines in your CSS you can make recent changes in your code more visible. You can as well use some comments keywords (e.g. @new) — you’ll be able to jump to the occurrences of the keyword and undo changes once you’ve found some problems.

#sidebar ul li a {
     display: block;
     background-color: #ccc;
          border-bottom: 1px solid #999; /* @new */
     margin: 3px 0 3px 0;
          padding: 3px; /* @new */
}

Conclusion

CSS styleguides are helpful if and only if they are used properly. Keep in mind that you should remove every styleguide which doesn’t effectively help you to get a better understanding of the code or achieve a well-structured code. Avoid too many styleguides for too many elements bundled in too many groups. Your goal is to achieve a readable and maintainable code. Stick to it and you’ll save yourself a lot of trouble.

• Leave a comment... (0)

Overview of XHTML 2.0

XHTML 2.0 is based solely on XML, forgoing the SGML heritage and syntax peculiarities present in current web markup. XHTML 2.0 is supposed to be a “general-purpose language,” with a minimal default feature set that is easy to extend using CSS and other technologies (XForms, XML Events, etc). It’s a modular approach that allows the XHTML2 group to focus on generic document markup, while others develop mechanisms for presentation, interactivity, document construction, etc.

Priority one for the XHTML2 working group is to further separate document content and structure from document presentation. Other goals include increased usability and accessibility, improved internationalization, more device independence, less scripting, and better integration with the Semantic Web. The group has been less concerned with backward compatibility than their predecessors (and the HTML working group), which has led them to drop some of the syntactic baggage present in earlier incarnations of HTML. The result is a cleaner, more concise language that corrects many of Web markup’s past indiscretions.

Overview of HTML 5

While XHTML 2.0 aims to be revolutionary, the HTML working group has taken a more pragmatic approach and designed HTML 5 as an evolutionary technology. That is to say, HTML 5 is an incremental step forward that remains mostly compatible with the current HTML 4/XHTML 1 standards. However, HTML 5 offers a host of changes and extensions to HTML 4/XHTML 1 that address many of the faults in these earlier specifications.

HTML 5 is about moving HTML away from document markup, and turning it into a language for web applications. To that end, much of the specification focuses on creating a more robust, feature-ful client side environment for web application development by providing a variety of APIs. Among other things, the spec stipulates that complying implementations must provide client-side persistent storage (both key/value and SQL storage engines), audio and video playback APIs, 2D drawing through the canvas element, cross-document messaging, server-sent events, and a networking API.

The HTML 5 specification maintains an SGML-like syntax that is compatible with the current HTML specifications (though some of the more esoteric features of SGML are no longer supported). Also included in the specification is a second “XML Serialization” which allows developers to serve valid XML documents as well. Again, by maintaining an SGML-like serialization the HTML 5 working group has struck a balance between pragmatism and progress. Developers can choose to markup content using either the HTML serialization (which looks more like HTML 4.x) or the XML serialization (which looks more like XHTML 1.x).

Similar Features

It shouldn’t be too surprising that both working groups are proposing a number of similar features. These features address familiar pain points for web developers, and should be welcome additions to the next generation of markup languages.

Removal of Presentational Elements

A number of elements have been removed from both XHTML 2.0 and HTML 5 because they are considered purely presentational. The consensus is that presentation should be handled using style sheets.

HTML 5 and XHTML 2.0 documents cannot contain these elements: basefont, big, font, s, strike, tt, and u. XHTML 2.0 also removes the small, b, i, and hr elements, while HTML 5 redefines them with non-presentational meanings. In XHTML 2.0, the hr element has been replaced with separator in an attempt to reduce confusion (since the hr element, which stands for horizontal rule, is not necessarily either of those things).

Navigation Lists

Navigation lists have been introduced in both XHTML 2.0 and HTML 5. In XHTML 2.0, navigation is marked up using the new nl element. Navigation lists must start with a child label element that defines the list title. Following the title, one or more li elements are used to markup links. Also new in XHTML 2.0 is the ability to create a hyperlink from any element using the href attribute. Combining these features produces simple, lightweight navigation markup:

<nl>
  <label>Category</label>
  <li href="/">All</li>
  <li href="/news">News</li>
  <li href="/videos">Videos</li>
  <li href="/images">Images</li>
</nl>

In HTML 5, the new nav element has been introduced for this purpose. Unfortunately, nav is not a list element, so it cannot contain child li elements to logically organize links (perhaps a new idiom will develop). And since anchor tags are still required to create hyperlinks in HTML 5, navigation markup is not quite as elegant:

<nav>
  <h1>Category</h1>
  <ul>
    <li><a href="/">All</a></li>
    <li><a href="/news">News</a></li>
    <li><a href="/videos">Videos</a></li>
    <li><a href="/images">Images</a></li>
  </ul>
</nav>

Enhanced Forms

Both specifications have new features to create more robust, consistent forms with less scripting. In XHTML 2.0, standard HTML forms are dropped completely in favor of the more comprehensive XForms standard. The XHTML2 working group does not control this standard, but references it from the XHTML 2.0 specification. To facilitate reuse, XForms separates the data being collected from the markup of the controls. It’s a robust and powerful language, but a full description is way beyond the scope of this post. Suffice it to say, there will be a bit of a learning curve for web developers trying to get up to speed with this technology.

HTML 5 retains the familiar HTML forms, but adds several new data types to simplify development and improve usability. In HTML 5, several new types of input elements have been introduced for email addresses, URLs, dates and times, and numeric data. This will allow user agents to provide more sophisticated user interfaces (e.g., calendar date pickers), integrate with other applications (e.g., pulling addresses from Outlook or Address Book), and validate user input before posting data to the server (less client-side javascript validation).

Semantic Markup

Both working groups have embraced the coming Semantic Web by allowing developers to embed richer metadata in their documents. As with forms, the XHTML2 working group has embraced a more sophisticated technology, while the HTML working group has kept things simple.

In XHTML 2.0, metadata can be embedded by using several new global attributes from the Metainformation Attributes Module. In particular, the new global role attribute is intended to describe the meaning of a given element in the context of the document. The technical term is Embedding Structured Data in Web Pages. Again, the group leverages an existing standard by referencing RDF. The technology is extremely powerful, but it’s also complicated.

The HTML working group has taken an approach that feels more like microformats by overloading the class attribute with a predefined set of reserved classes to represent various types of data. The specification currently lists seven reserved classes: copyright, error, example, issue, note, search, and warning. While overloading the class attribute like this might be confusing, it’s unlikely that user agents will render elements with these classes differently. And the class names are specific enough that there’s little worry: if an element has its class set to copyright, it’s probably a copyright whether the developer knew about the reserved classes or not.
Only in HTML 5

There are several new features that the HTML 5 specification describes that have no counterparts in XHTML 2.0.

Web Application APIs

HTML 5 introduces several APIs that will drastically improve the client-side web development environment. These APIs are what set HTML 5 apart as a proposal for a technology stack for Web Applications, rather than simply a markup language for documents. It should be noted that the details of these APIs are being worked out by the Web API working group, so they may be adopted with or without the rest of HTML 5. The new APIs, and corresponding elements are:

    * A 2D drawing API using the canvas element.
    * An audio and video playback API, supporting the ability to offer multiple formats to user agents, which can be used with the new video and audio elements.
    * Persistent storage on the client-side with support for both key/value and SQL databases.
    * An offline web application API (similar to Google Gears).
    * An API that allows Web Applications to register themselves for certain protocols or MIME types.
    * An editing API that can be used in combination with the global contenteditable attribute.
    * A drag & drop API that can be used with the draggable attribute.
    * A network API allowing Web applications to communicate using TCP.
    * An API that exposes the browser history, allowing applications to add to it so they don’t break the back button.
    * A cross-document messaging API.
    * Server-sent events in combination with the new event-source element.

New Elements

Several new elements are being introduced by HTML 5 that aren’t available in XHTML 2.0:

    * figure represents an image or graphic with a caption. A nested legend represents the caption, while a normal img element is used for the image.
    * m represents text that has been marked in some way. It could be used to highly search terms in resulting documents, for example.
    * time represents dates and time.
    * meter represents a measurement.
    * datagrid represents an interactive tree list or tabular data.
    * command represents a command that the user can invoke.
    * event-source is used to “catch” server sent events.
    * output represents some type of output, such as from a calculation done through scripting.
    * progress represents a completion of a task, such as downloading or when performing a series of expensive operations.

In addition, several new elements will help semantically markup the parts of a document. They’re fairly self explanatory: section, article, header, footer, and aside. And a new dialog element is designed to represent conversations using child dt elements for the speaker’s name and dd elements for the text.

Track Users by Pinging URIs

The new ping attribute can be used on the a and area elements to do user tracking. Rather than using redirects, or relying on javascript, the ping attribute allows you to specify a space separated list of URIs that should be pinged when the hyperlink is followed.
Only in XHTML 2.0

Also notable are the following new features that are available only in XHTML 2.0.
Any Element can be a Hyperlink

In XHTML 2.0, any element can be the source of a hyperlink — the href attribute can appear on any element. With this change the a element is no longer necessary, but it is retained.

Any Element can be an Image (or other resource)

In XHTML 2.0, the img element has been dropped. No worries, though — any element can now be an image. The idea is that all images have a “long description” that is equivalent to the image itself. By placing a src attribute on any element, you’re telling the user agent to load that resource in place of the element. If, for whatever reason, the resource is unavailable, the element is used instead. This allows developers to provide multiple equivalent resources using different file formats and representations by nesting elements within one another.
Lines Replace Line Breaks

The venerable br element, used to insert line breaks, has also been dropped from XHTML 2.0. The new l element is being introduced to replace it. l represents a line of text, and behaves like a span followed by a br in today’s markup.

New Heading Construct

The new h and section elements have been introduced to replace the numbered h1 through h6 elements. The goal is to accurately represent the hierarchical structure of a document. The current numbered headings are linear, not nested. By nesting section and h elements within parent sections the document structure is made explicit.

New Elements

The XHTML2 working group has focused on creating a more generic, simplified language. To that end, they’ve refrained from adding numerous specialized elements to represent different types of content. They argue that the new role attribute provides a mechanism for including rich metadata, making specialized elements unnecessary. That said, a couple new elements were included:

    * blockcode represents computer code.
    * di represents a group of related terms and definitions in a dl (definition list). This is useful for words with multiple definitions, or multiple spellings.
    * handler represents a scripted event handler, with a type attribute specifying the handler language. If the user agent doesn’t understand the language, the handler’s children are processed (otherwise they’re ignored). Handlers may be nested to provide multiple implementations in various languages.

Conclusion

Both proposals look promising, with lots of new features that address common web development problems. But neither specification is an official recommendation, and it’s likely to stay that way for some time.

Despite its late start, the HTML 5 working group seems to have more industry support, and is further along in the recommendation process. Their goal is to have a complete spec, with multiple interoperable implementations, by late 2010 (as I said before, though, the W3C has already missed some milestones in the approval process). With industry support from most of the major browser vendors (the only notable exception being Microsoft) it’s likely that this specification will be implemented quickly and consistently once it’s reached a stable state.

What everyone wants to avoid is another standards war. Fortunately, since both languages support XML namespaces (or, in the case of the HTML serialization of HTML 5, DOCTYPE switching) it’s unlikely that we’ll see the sort of browser dependent behavior we did in the 1990s. Standards wars aside, the future looks bright for web development. These new markup features and APIs will provide a rich environment for web development that should narrow the gap between Web and Desktop applications.

• Leave a comment... (1)