Raible Designs

[TSE] Building Modern Web Applications with Mike Stenhouse

Mike Stenhouse is the creator of the CSS Framework we use in AppFuse¹. Mike is going to talk about the tools he uses to develop web applications. Mike works solely on the front-end, no backend work.

"In 2007 we’ll witness the increasing dominance of open internet standards. As web access via mobile phones grows, these standards will sweep aside the proprietary protocols promoted by individual companies striving for technical monopoly. Today’s desktop software will be overtaken by internet-based services that enable users to choose the document formats, search tools and editing capability that best suit their needs." -- Eric Schmidt, CEO Google

Web Standards is a methodology and philosophy, not just valid CSS and XHTML. The main philosophy behind web standards is progressive enhancement. The methodology behind web standards is a 3-step process.

Figure out what the content means
Code the HTML accordingly, ignoring the design
Then write your CSS to realise the design
Finally, add a sprinkling of Javascript to tune the interaction

HTML
X/HTML is where you get most of your benefits from. It should be content only, nothing else. If your content and XHTML sucks, CSS is probably not going to be able to help a whole lot. HTML vs. XHTML have small syntax differences, the main differences show up with the mode of the doctype. HTML 4 Strict, XHTML Transitional and XHTML Strict are all good. HTML 4 Loose sucks.

HTML is the skeleton and isn't as easy as people think it is. Tables and nested tables are some of the worst offenders of bad HTML. When people move from table-based layouts to standards-based layouts, it's usually a disaster because of meaningless classes on div tags. A lot of times, adding classes to HTML elements is completely meaningless. The less classes and ids, generally the better. By removing classes, your HTML becomes much more readable (save for input tags and such).

This is what's called semantic HTML. It has nothing to do with the Semantic Web. Using HTML for what it's designed for. Headings are in order, paragraphs, lists, inputs, labels, fieldsets. Tables are used only for tabular data.

To write semantic HTML, use the following guidlines:

Look at your content and figure out its meaning
Think of the document outline mode in Word -the headings are used to navigate
Group form elements and work out what order they should be filled in
If it’s too tricky there might be a problem with the design

Using these guidelines will help you write cleaner code. The CSS Zen Garden is a poor example of semantic HTML - there's just too many classes. You should try to push classes and ids upwards. For example, you can convert the following HTML from:

<ul>
    <li><a class="navlink" href="x">
    <li><a class="navlink" href="y">
    <li><a class="navlink" href="z">

To:

<ul class="nav">
    <li><a href="x">
    <li><a href="y">
    <li><a href="z">

The first example only allows you to style with "a.navlink", whereas the 2nd gives you more elements to style (ul.nav a, ul.nav, ul.nav li).

Another suggestion is to use multiple classes on your HTML elements. <body class="order final sales"> can be controlled with body.sales, body.final and body.order.final CSS classes. CSS class names should be almost like metadata - they should relate more to the content to the design.

By using web standards-based design, you get the benefits of debugging (W3C Validator). In addition, you get SEO benefits from good HTML. If you use proper semantic HTML, machines can make better sense of your HTML. Headings are one of the most important things for SEO. It's amazing how simple this stuff is and how few people understand it.

Microformats
Microformats are a way of adding metadata to your HTML. They basically say to use classes, rels and refs, and use them in a specific way. The Semantic Web community has recently started forming ties with the microformats community. A few uses are currently in existence: hCard, hReview, hCalender, hResume, XFN, XOXO, rel-directory, rel-pavatar, rel-nofollow, rel-tag and xFolk.

To conform to a microformat, you simply need to add add certain classes to your existing markup. For example, here's an address in hCard format:

<div class="box vcard">
   <h3>Contact Details</h3> 
   <a class="fn url" href="ttp://adactio.com/">
       <span class="given-name">Jeremy</span> 
       <span class="family-name">Keith</span>
    </a> 
    <p class="adr">
        <span class="street-address">57/58 Brunswick Road</span> 
        <span class="locality">Hove</span>
        <a class="postal-code" 
           href="http://maps.google.co.uk/maps?q=bn3+1dh" title="map">BN3 1DH</a> 
        <span class="country-name">England</span>
    </p> 
</div>

If you feed this into Technorati, it can give you back a vCard. It can also work by specifying a URL that contains HTML with this microformat.

Even Bill Gates said "We need microformats". They're definitely starting to get a lot of traction. The beauty is they're very simple to use and implement.

CSS
What's important about CSS is it allows you to redefine how your HTML elements behave and display on a page. Firefox actually uses CSS (including some CSS 3.0 stuff) to control how HTML renders. With CSS, you can extract your design from the HTML. It's the icing on the HTML cake.

CSS allows you to separate the front from the back. It can very useful for designers and developers. Developers do the HTML, designers do the CSS. The CSS Zen Garden is the best example of how powerful CSS is.

CSS allows you to retask-content. For example, supplying a different CSS file for printing is a great use. There's also support for mobile devices and projectors, but they're not as well supported.

CSS allows you to define your display once and reuse more. DRY for HTML. You can even get re-use between sites by using "modular CSS". Mike generally breaks his CSS down into groups using @import:

@import url("tools.css");
@import url("typo.css"); 
@import url("forms.css");
@import url("tables.css"); 
@import url("layout.css");

Other breakdowns: site sections, color, old browsers vs. new browsers and layout (CSS Framework). Basically, use a different stylesheet to separate these different breakdowns.

Mike invented the CSS Framework as a "set of standard naming conventions for the HTML and an example set of layout stylesheets".

The CSS Framework gives you a massive head start on small projects, but may not be as useful for large projects. Mike is working with Clay Loveless to create an updated version of The CSS Framework. The first thing I'd suggest is a new name, while "the CSS Framework" is a descriptive name, it's too much of a mouthful. Look at what the term "Ajax" did for XHTML, JavaScript, CSS and XHR.

Hacks for the different browsers: the only one that Mike uses regularly is "* html" for IE. He generally applies "height: 1%". Occasionally he needs \ for IE 5.x.

w\idth: 50px; 
width: 40px;

The final hack is to put your IE-specific rules in ie.css, but Mike's not a big fan of it.

Rules of thumb to avoid browser-compatibility issues:

Avoid margins and padding on elements with a width
Use % font-size on the body and ems for everything else
Avoid PNG and alpha transparency
Avoid too much styling on form elements (can be a nightmare to do cross-browser)

IE7 fixed the * html parsing error so filter doesn't work in IE7. They haven't fixed "hasLayout" or conditional comments. "hasLayout" is a bug in IE that adds padding around list elements whenever they have any CSS styles applied to them. I'm sure there's more too this, but I didn't get a chance to write it down.

Triggering hasLayout cures similar problems to height: 1% in previous versions. You can manipulate programmatically using object.currentStyle.hasLayout.

Conditional comments are still a problem. Mike likes it because it allows you to put all your IE hacks in one place. He doesn't like it because it requires you keep an extra things in your head.

JavaScript
JavaScript has gotten a bad name because it was used to add a lot of crap to web pages for so many years. It used to be used to create atrocities, whereas now it's used to create very elegant sites.

The first thing that brought back Ajax is "DOM Scripting". DOM Scripting is methods for accessing and modifying the DOM. The DOM is an HTML page represented as a tree of objects.

History: DOM0 was not a standard. DOM1 is a standard for navigation and manipulation. DOM2 is XML and events (onclick, onblur, etc.).

The 2nd thing that brought back JavaScript is Ajax. There's a number of different Ajax techniques:

XmlHttpRequest object
IFrames
Flash Remoting
Applets
Comet

Mike is using applets on a project right now for heavy visualization. They use Ajax with applets so it doesn't unload the VM and they're calling it "AppleJax".

The main problems with Ajax when it first came out where: network latency, usability, JavaScript off, SEO and Accessibility.

Frameworks can help you get around a lot of the issues with Ajax. The problems with frameworks is there are so many. A few of the best: Dojo, Prototype, YUI, MochiKit, Moo Tools and jQuery. Mike's favorite is jQuery.

Dojo is great, but almost does too much. Mike is afraid to use it because he doesn't understand how they do some things.

Dojo:

Devilishly clever
Application-like functionality in the browser
Includes stuff like client-side storage
Massive
Not much documentation
Black magic

YUI:

The full weight of Yahoo! behind it
Extremely well documented
Modular
Lacking in sex-appeal
Can get very heavy

MochiKit:

Modeled after Python
Quite heavy
Highly rated but hasn’t experienced the sort of adoption the other frameworks have seen

Prototype:

Built into Rails (the main reason Mike used it)
Good Ajax
Quite heavy, especially with Scriptaculous
Dispersed documentation but readable source code
Missing some basic helpers (addressed by Low Pro)

Moo Tools:

Modular
Functional
Very compact

Mike mentions Moo Tools because friends have recommended it that are "in the know".

jQuery:

Lightweight
Uses CSS syntax
Perfectly suited to progressive enhancement
Functional design
Well documented
Basic Ajax

However, Ajax frameworks can be dangerous. It's the problem of leaky abstractions - if you don't understand what the framework is doing, it can be difficult to debug and refactor. Mike recommends writing JavaScript the long way and then refactor it to use a framework after you understand it.

Unobtrusive JavaScript is why Mike came here to talk today. It allows you do "progressive enhancement for your applications". To use progressive enhancement, your JavasSript should be kept separate from your HTML and CSS. Everything should work without JavaScript. It should be possible to use progressive enhancement with full-blown Ajax applications.

Inline JavaScript sucks:

<a href="#" onclick="lightbox('/show_email/224899'); return false;">Daily Call</a>
<a href="#" onclick="lightbox('/show_email/138512'); return false;">Access Card Information</a> 
<a href="#" onclick="lightbox('/show_email/83407'); return false;">Can UBS Tame Enron's Wild Traders?</a>

A better solution is:

<a href="/show_email/224899">Daily Call</a>
<a href="/show_email/138512">Access Card Information</a> 
<a href="/show_email/83407">Can UBS Tame Enron's Wild Traders?</a>

<script type="text/javascript">
window.onload = function() { 
    if (!document.getElementsByTagName) return;
    var links = document.getElementsByTagName(&lsquo;A&rsquo;); 
    each (link in links) {
        link.onclick = function() { lightbox(this.href); return false; }; 
    }
}; 
</script>

onready is a better way to do window.onload as it will fire as soon as the HTML has come down. Hijax embraces this idea. The approach is as follows:

Make a rock-solid, Web 1.0 app
Good, old fashioned GETs and POSTs that will work in any browser and on any platform
Just HTML styled with CSS
Add a layer of Javascript attached via the DOM to enhance the experience

It might take a little more work to develop this way, but it's a much more solid foundation. If your JavaScript/Ajax starts to break, the app should still work. A good example is Odeo. Apparently, one of their releases, they forgot to deploy the JavaScript and the whole site continued to work - no one even told them.

Other benefits: your app doesn't depend on JavaScript so it'll work on devices that don't support it. There's no way you can possibly account for every use someone might put your site to (mobile phone, accessibility devices, set top boxes, etc.).

Keep your JavaScript and CSS separate. Don't manipulate styles with JavaScript, just switch CSS classes.

Back to Eric Schmidt's quote. If you use "progressive enhancement", it's an excellent way to leverage web standards. The better the browser, the better the experience.

1. At the end of his talk, Mike mentioned that he got invited to this conference because we use the CSS Framework in AppFuse. Cool!

My Thoughts
After Mike's talk, I walked up and introduced myself. I thanked him for the CSS Framework and we chatted a bit about his talk. I really like his recommendations of progressive enhancement (or Hijax) and plan to use it a lot more when developing UIs. Mike was an excellent speaker and one of those guys you instantly want to have a beer with.

Posted in The Web at Dec 10 2006, 08:51:40 AM MST 2 Comments

Comments:

Nice, very nice, nicely composed.

Posted by Aleksandar Pavic on December 11, 2006 at 06:22 AM MST #

Thanks for the nice comments Matt! That's a really good point about the 'CSS Framework' name. Dan Webb wrote a good post about the importance of a catchy name... I'll put some thought into it. Shame we didn't get to grab a beer though. Next time.

Posted by Mike Stenhouse on December 11, 2006 at 08:29 AM MST #

10+ YEARS

TWITTER

RECENT ENTRIES

Tag Cloud

[TSE] Building Modern Web Applications with Mike Stenhouse