But they can also generate a surprising number of superfluous elements.

The 960 Grid System encourages the addition of <div> elements and class attributes, especially on complicated pages. Is this really an improvement over nested tables?

Creating cleaner code means going beyond the framework and thinking about what it really represents.

CSS frameworks provide a workflow solution, namely a rapid deployment of grid-based web layouts. One of the most popular frameworks today is the 960 Grid System (960.gs), named after its default width. With practice, 960.gs can be a great tool for any web designer. But it also revisits a few old problems.

Before CSS saw widespread use, tables provided all the layout a web designer needed. More complicated designs had tables nested within tables, but used in excess these created a tangled mess of HTML. CSS-based layouts lured designers with the promise of less HTML; they also appealed to semantics enthusiasts. Simply put, CSS encouraged the use of HTML that described what content was about, not what it should look like.

As designers learned to use CSS, div elements replaced tables. But divs can be—and often are—nested, just like tables.

The Spread of Class-itis and Div-itis

Clear, lean code offers many advantages. It’s easy to fix, quick to download and causes fewer problems across different types of browsers. Relevant tags help screen readers, search engines and mobile devices interpret meaning in addition to layout.

Other than the semantics, the great advantage of using <div>…</div> over <table><tr><td>…</td></tr></table> is that we end up with less code to do the same job. But now designers face a glut of classes and divs.

Do CSS frameworks such as 960.gs recreate the underlying problem with tables? If their goal is efficient HTML, can designers and developers use 960.gs without spreading “class-itis” (i.e. excessive use of classes) and “div-itis” (i.e. so many divs that tables start looking good again)? Yes, they can.

To understand how, we need to look at the framework itself.

A Rundown of 960.gs

960.gs provides a set of columns, written in CSS, that facilitate the laying out of web pages. Download the files, add them to your website and it’s ready to go. No special plug-ins or new technology are needed, and you can use it in conjunction with other CSS files.

Columns are contained within blocks called (naturally) “containers.” The defaults are container_12 and container_16, which divide into 12 and 16 columns, respectively. Custom sizes are available.

The diagram above shows the two default containers with 12 and 16 columns. The gray won’t be visible on your final website, of course. The columns merely show where blocks, called “grids,” can be arranged.

A grid is a block of content that can cross more than one column in a container. Grids float left by virtue of being held in .container_x, making them ideal for modular layouts. The width of each block is determined by which grid you apply to it: grid_1 is one column wide, grid_5 is five columns wide, etc.

Above, .container_12 holds three grids. Each grid, in turn, would hold different elements of the page’s content.

Above, .container_16 holds two blocks of 12 and 4 columns, respectively. Like .container_12, this 16-column-wide layout measures 960 pixels wide—but its columns are narrower.

Resizing the grids in which the content’s elements fit is simple: change the grid_x in each div.

The official 960.gs website showcases websites that were built on the framework, and it also provides page templates, links to a custom grid generator and the framework itself. Detailed instructions are included, too, because there’s more to learn. Grid margins and the ability to step into gutters between grids make the system even more flexible.

In spite of these benefits, embedding <div class="grid_x">…</div> in <div class="container_x">…</div> encourages coders to use many class attributes (class-itis) and divs (div-itis).

Solutions

Arguing against tables for layout is easy enough. But using three or more levels of nested divs doesn’t solve the problem—it just replaces one set of tags with another. Frameworks help but don’t always solve the dilemma. With a little forethought, many of these problems can be avoided.

Only Use Classes That You Actually Need

The simplest solution to excessive CSS code is to cut out what isn’t necessary. 960.gs was conceived as a wireframing tool, meant to be replaced when the website goes live. It includes more than 180 class definitions.

If your design is structured on, say, .container_12 and never uses more than .grid_5 and .grid_7, then remove the others from the CSS.

Apply class=”grid_x” to Appropriate Elements: Headings, Images, Links, Paragraphs

The .container_x and .grid_x classes aren’t restricted to div elements. The class attribute can be applied to any element except html, head, meta, param, script, title and style—so, practically anything in the body. If a pair of div tags enclose only one item, then they may be unnecessary.

Applying Grid Code to Non-Divs

Grant Grid Properties to Certain Elements

Being simple CSS, .grid_x has properties that would work with any other class name—or any element. By copying the properties to certain elements, extra classes become unnecessary.

.examples li { (properties of .grid_4) }

<ul class="examples">
  <li>…</li>
  <li>…</li>
  <li>…</li>
</ul>

Below, applying the grid to list items creates even columns, with minimal changes to the HTML.

CSS turns the above list into a multi-column group. If you need a normal list with bullet points, just discard the class="examples" attribute. Is this semantic? Certainly—as long as the content merits a list. The CSS merely changes how each bullet point is presented.

Another example:

.photos p { (properties of .grid_10) }
.photos img { (properties of .grid_6) }

<div class="container_16 photos">
  <img src="…" alt="photo" />
  <p>First caption</p>
  <img src="…" alt="photo" />
  <p>Another caption</p>
</div>

This automatically puts captions, enclosed in paragraph tags, adjacent to photos.

When tables are not appropriate, the tabular effect is easy to create with non-tabular HTML.

.datelist { (properties of .container_12) }
.datelist h3 { (properties of .grid_3) }
.datelist p { (properties of .grid_7) }
.datelist strong { (properties of .grid_1) }

<div class="datelist">
  <h3>subhead</h3>
  <p>…</p>
  <strong>3 p.m.</strong>
  <strong>Jan 1, 2010</strong>
  <h3>subhead</h3>
  <p>…</p>
  <strong>3 p.m.</strong>
  <strong>Jan 1, 2010</strong>
</div>

The example above is a schedule of events in which each “cell” in the table has a different tag to reflect its unique content, rather than having the catch-all <td> tag. (Ideal? Maybe not. The HTML doesn’t distinguish between groups of content.)

Applying .grid_x properties to other elements requires some planning, but it results in less-cluttered HTML and doesn’t interfere with 960.gs itself.

Use Classes in Parent Items, not Child Items

Div-itis and class-itis aren’t limited to CSS frameworks.

All of the examples in the last section share an interesting trait: only one class declaration in each. Wherever the same class attribute is used several times in a row in the HTML, change the parent instead of the children.

Unnecessary:

.item { (various properties) }

<ul>
  <li class="item">…</li>
  <li class="item">…</li>
  <li class="item">…</li>
  <li class="item">…</li>
  <li class="item">…</li>
  <li class="item">…</li>
</ul>

Above, all six elements have a class. They’re redundant because the classes are identical. Here’s a better way:

.group-of-items li { (various properties) }

<ul class="group-of-items">
  <li>…</li>
  <li>…</li>
  <li>…</li>
  <li>…</li>
  <li>…</li>
  <li>…</li>
</ul>

The remedy here for class-itis is to assign a single class to the parent element. CSS selectors do the job, applying the styling to every <li> inside the .group-of-items class. This method can be used on any group of elements with a common parent. For example:

<div>
  <h1 class="title">…</h1>
  <h1 class="subhead">…</h1>
  <p class="publication-date">…</p>
  <p class="body-text">…</p>
  <p class="body-text">…</p>
  <p class="body-text">…</p>
  <p class="body-text">…</p>
  <p class="body-text">…</p>
</div>

.title { (various properties) }
.subhead { (various properties) }
.publication-date { (various properties) }
.body-text { (various properties) }

Most of the paragraphs above are just simple paragraphs and yet have needless class attributes. We also have two headings, distinguished only by their classes—yet adjoining <h1> elements don’t make for a good content structure. Here is a better solution:

<div class="article">
  <h1>…</h1>
  <h2>…</h2>
  <p class="publication-date">…</p>
  <p>…</p>
  <p>…</p>
  <p>…</p>
  <p>…</p>
  <p>…</p>
</div>

.article h1 { (various properties) }
.article h2 { (various properties) }
.article .publication-date { (various properties) }
.article p { (various properties) }

Now only two classes remain. We’ve kept the .publication-date class to distinguish it from the normal paragraphs below it. Because HTML doesn’t have a “date” tag, this class is necessary to show what the paragraph contains. The new .article class enables you to style that div and the elements in it in the CSS with minimal mark-up. The CSS in both examples has four definitions each, and yet we end up with much cleaner code in the second.

In general, identical elements with a common parent do not need extra attributes. Classes only help when there’s a difference between them. A rule of thumb: use classes only when you need to distinguish between otherwise identical types of content.

Simplify

The purpose of the 960 Grid System, and CSS frameworks in general, is to reduce the effort needed to lay out web pages. The benefit of CSS is that it reduces the amount of HTML necessary to display a page. But as a layout language, CSS isn’t perfect. Frameworks are merely tools that help people achieve solutions, not the solutions themselves. It’s up to designers and developers to combat class-itis and div-itis.

Written exclusively for Webdesigner Depot by Ben Gremillion. Ben is a freelance web designer who solves communication problems with better design.

How do you say more with less? Share how you streamline code and your workflow in the comments below…

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C

Firefox has always done an excellent good job of supporting both CSS and JavaScript in a standards-compliant manner without too many awkward bugs.

There are, however, a few CSS properties and selectors that aren’t supported by one or more of the versions released since version 3.0., which I will cover here.

This article will cover bugs, inconsistencies, and nonsupport. So, if you’re having trouble with a CSS property or selector in Firefox and it’s not listed here, then you’ll probably have to rethink your layout and reconsider what the culprit might be.

Since Firefox 2 is virtually non-existent, I won’t be considering that version specifically, but this information will generally apply to that version by default.

And I should note that the material for this post was taken primarily from the newly-updated SitePoint CSS reference, which is hands-down the best and most comprehensive CSS reference available anywhere.

The Outline Overflow Bug

In Firefox 3.x, when an element overflows the border of a parent that has the outline property set, the outline will stretch to fit the containing element, as shown in the screen capture below:

The correct implementation is shown in the next screen capture taken from Chrome:

As shown above, the outline should encompass the element that is being outlined, and should not be affected by any overflowing elements. To ensure there’s no confusion, note that this is a bug in the implementation of the outline property, not the border property.

Reference: SitePoint CSS Reference: outline Property

Tables with Collapsed Borders

In Firefox, when a table has its borders set to collapse using the border-collapse property, the table’s top and left margins in relation to nearby elements is 1 pixel off. This is shown in a zoomed-in screenshot in the image below, which displays the bottom border of a block-level element (red) touching the top border of a collapsed table (blue):

Here is the correct implementation of this property/value pair, as shown in Chrome:

As shown above, because the borders are “collapsed”, and because the table is not a block element, there should be a slight offset in the left margin, and the top margin should be even with the bottom border of the element above it.

Reference: SitePoint CSS Reference: border-collapse Property

Empty Cells in Table Rows

This is a property value that is not implemented properly by any browser, including Firefox. When a table row has no visible content and all its cells have their empty-cells property set to hide, the entire row should behave as if it were set to “display: none”, with no borders or backgrounds visible.

No browser handles this correctly, so the table row is still visible, as shown in the image below.

Reference: SitePoint CSS Reference: empty-cells Property

Word Spacing on Inline Elements

In Firefox 3.x, a negative value on the word-spacing property will be treated as zero on adjacent inline elements. The negative value should cause the inline elements to overlap one another, as would be the case with text, but this doesn’t happen. Instead, the elements are just given zero white space separation with no overlap.

The image below displays both the correct and incorrect implementations:

In the examples shown above, the three words “Fruits”, “Vegetables” and “Other Foods” are individually wrapped in <span> elements, while the paragraph that wraps them has its word-spacing property set to a negative value.

The second example (Firefox) fails to apply the negative word spacing, except between the last two words because those words are not individually wrapped by spans but are natural text elements.

As a side point, this bug occurs similarly in IE8, but not in previous versions of IE.

Reference: SitePoint CSS Reference: word-spacing Property

Text Decoration on Floating Descendants

When an element has a text-decoration value set, that value should not be inherited by floating descendants. In Firefox 3.x, floating descendants are given the same text-decoration values as their parent, even though this should not be the case.

In the image above, the first line is a screenshot from IE8, displaying a <span> element floated inside of an anchor. The text inside the <span> does not have a visible text decoration, which is the correct way to display it. In Firefox (shown in the second example), the text-decoration is incorrectly applied to the floating <span>.

You may have noticed this bug in Firefox when trying to remove the text-decoration from floated images inside of anchors.

Reference: SitePoint CSS Reference: text-decoration Property

pre-line & pre-wrap for the white-space property in FF 3.0

Using the white-space property in Firefox 3.5, you can specify whether multiple space characters should be collapsed down to a single space or not. By default, HTML documents will collapse multiple spaces down to a single space. In some instances, you can apply white-space: pre to prevent white space from being collapsed, which is similar to the use of the <pre> HTML tag. Subsequently, you may want to remove that setting using white-space: pre-line (to collapse white space).

Firefox 3.0 does not support this value, so the white space will be retained. Firefox 3.5 collapses the space correctly. The image below shows both examples:

Similarly, when a paragraph of text is set to white-space: pre-wrap, this should preserve white spaces between words, but should naturally include line breaks. Firefox 3.0 fails to implement this correctly, while later versions (and all other browsers) include the natural line breaks. Both examples are shown below.

Keep in mind that the outer element is given white-space: pre while an inner <span> is attempting to override the lack of line breaks using pre-wrap. On its own, pre-wrap would not have any effect.

Firefox 3.x also treats the some of the white-space values differently from other browsers when those values are applied to the <textarea> element. For example, applying white-space: nowrap should cause all typed text in a <textarea> to form one line, but Firefox 3.x does not do this.

Reference: SitePoint CSS Reference: white-space Property

Page Break Properties

CSS allows developers to specify where page breaks should or shouldn’t occur using the three properties page-break-before, page-break-inside, and page-break-after. Opera is the only browser that fully supports these properties, while other browsers offer partial support or no support.

The page-break-inside property specifies whether or not a page break can occur inside a single block-level element. Firefox does not provide support for this property. Using the syntax page-break-inside: avoid, you can prevent an element from being divided during printing. The image below, from a print preview in Opera 10, shows how this property can prevent an unordered list from being split over two pages:

By contrast, look at the image below, taken from the print preview option in Firefox 3.5:

Reference: SitePoint CSS Reference: Paged Media Properties

Orphans and Widows on Printable Pages

The orphans and widows CSS properties are supported only by Internet Explorer 8 and Opera since version 9. This property is used to specify the minimum number of lines from a single paragraph that can occur on a printed page, either at the bottom (orphans) or the top (widows). Depending on the number chosen, lines will be moved from one page to the next (or previous) in order to prevent a single line from being printed at the top or bottom of a page.

Even with the orphans property set to a value of “3″, as shown in the image below, Firefox’s print preview shows a single line at the bottom of one of the printable pages:

Similar to the page-break-inside property, Firefox also fails to support the values avoid, left, and right for both the page-break-before and page-break-after properties.

References: SitePoint CSS Reference: orphans Property | SitePoint CSS Reference: widows Property

The :first-line Pseudo-Element Bug

The :first-line pseudo-element allows the first line of any given text block to have different formatting from the rest of the text. For example, the first line of a paragraph of text can be changed to uppercase or to a different color. For this CSS element to work in a practical manner, it should allow for the possibility of nested block-level elements. For example, a <div> element that contains a <p> element should allow the :first-line pseudo-element to change the styling of the first line of text inside the <div>. In Firefox (and in many other browsers), this is not possible unless the pseudo-element specifically targets the child paragraph.

Internet Explorer 8, Chrome, and Safari implement this feature correctly, preventing nesting of block elements from breaking the styling, as shown in the image below:

In the paragraph above, the text is inside of a <p> element, which resides inside of a <div>. The <p> has the :first-line pseudo-element set to color: blue, which fails in Firefox because of the nesting of the paragraph inside the <div>.

Reference: SitePoint CSS Reference: first-line Pseudo-Element

CSS3 Support in Firefox 3.x

Firefox has gradually added better support for CSS3 since the release of version 3.0. Below is a description of how Firefox handles different features of CSS3. Some of these may still be in the working draft or candidate recommendation stage, therefore we can’t be dogmatic about what should and shouldn’t be supported until they have reached the recommendation stage.

• Firefox 3.0 doesn’t support the text-shadow property
• Firefox 3.x doesn’t support the box-shadow property, except when using the proprietary prefix -moz-
• Firefox 3.x doesn’t support the box-sizing property, except when using the proprietary prefix -moz-
• Firefox 3.x doesn’t support multiple columns unless the proprietary prefix -moz- is used
• Firefox 3.0 and 3.5 do not support CSS3 gradients and multiple backgrounds (both of these were recently added in 3.6)
• Firefox 3.0 doesn’t support the border-image property, but 3.5 supports it using the -moz- proprietary prefix
• Firefox 3.0 doesn’t support a number of CSS3 pseudo-classes (:nth-child, :nth-last-child, :nth-of-type, etc.)
• Firefox 3.0 doesn’t support CSS transforms
• Firefox 3.x doesn’t support CSS transitions
• Firefox 3.x doesn’t support CSS animations

Other CSS Features Not Supported

Some of the more significant bugs and incompatibilities were discussed above, but there are a few others worth noting.

• Firefox up to version 3.5 doesn’t support the value run-in for the display property
• Firefox doesn’t support the ::selection pseudo-element
• The @page at-rule is not supported by Firefox
• The @font-face at-rule is not supported by Firefox 3.0

Conclusion

After going through this material, you can clearly see that lack of support of CSS features in Firefox is minimal, and in many cases quite irrelevant since many of the properties discussed here are not very commonly used.

Nonetheless, I hope this will provide a decent reference for the most significant bugs and inconsistencies in Firefox. If you are having problems with a particular feature of CSS in Firefox that isn’t listed here, chances are you’re doing something wrong or may not fully understand certain CSS concepts and principles.

So, in that respect, this reference should work well as a reverse-reference, since those not listed here can be trusted to work fine if they are implemented correctly with proper syntax.

Of course, if there’s anything I’ve missed, or any errors, please comment and I’ll do my best to make any necessary corrections and additions.

Further References

• CSS improvements in Firefox 3
• Newly-supported CSS Features in Firefox 3.5

Firefox Image provided by Rakaz

This post was written exclusively for Webdesigner Depot by Louis Lazaris, a freelance writer and web developer. Louis runs Impressive Webs where he posts articles and tutorials on web design. You can follow Louis on Twitter or get in touch with him through his website.

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C

You could divide your traffic sources into four broad categories:

Search engines, mobile visitors, visitors using screen readers and visitors who have JavaScript turned off.

When planning your information architecture and design, you must figure out how to deal with these special groups.

I have assembled a few recent real-world scenarios to find clarity on the issue.

When you want to hide lengthy content behind an animated scroller, or rotate through products or testimonials in sequence, or present categorized page-level content cleanly, you could use accordions, carousels or any other imaginative solution.

If you keep up with JavaScript best practices or use any of the myriad of JavaScript libraries, you are probably already familiar with unobtrusive JavaScript, which is the technique of presenting JavaScript interactivity only when JavaScript is enabled.

This principle should be extended to presentation as well: build your dynamic feature(s) and set your display and visibility values only after the document is ready and only if the visitor has JavaScript enabled, rather than set the properties in your HTML code or define them server-side.

Like many screen readers, Google’s crawler tends to ignore content wrapped in an element set to display: none, while it does crawl any content set to display: visible.

So your task as a designer is to plan the space and layout around your dynamic features, and also to prepare for instances when “dynamic” is not an option.

If the content on one of your pages will always be visible in the browsers of certain users, how should it be displayed? Should hidden content remain hidden even if JavaScript is disabled? Should all content be available to screen readers and search engines? If a piece of content becomes visible only after an AJAX call, how do you adequately fill that space when JavaScript is disabled?

The Accordion

An accordion is a structure that usually consists of a pattern of pairs of heading and content. Blocks of content would expand one at a time, in response to an event triggered in the heading.

Hulu’s Accordion

I recently helped one client overcome the problem of having very long pages. This client had an online catalog of training courses and stipulated that all of the information for a particular program must be available up front: no page skipping or pop-ups for core course descriptions or program definitions.

All program information had to be available to the visitor on the same page, without having to navigate back and forth in the course catalog.

The right solution here was an accordion, collapsing course descriptions beneath headings for each area of study (math or history, for example). A poor implementation would have been to set the visibility of those collapsed course descriptions before the HTML was rendered on the screen.

If the content was hidden pre-rendering, then some visitors and search engines would miss much of the important content.

Using jQuery, I targeted the content for collapsing and set the accordion to trigger after the page had loaded and the document was ready. For this client, making the content available to all audiences was extremely important. Some of the content could run very long, and so a design that could accommodate extreme vertical expansion was needed.

The Carousel

You’ll see carousels fairly often in portfolios and product spotlights.

Typically in carousels, content will scroll in response to a time-out interval or some user interaction (see “Your Recent History” on Amazon). I like carousels for their flexibility and because they allow you to fix at least one dimension of the container.

Amazon’s carousel

Another client recently inquired about the “News and Highlights” area of their home page. Like many other content blocks of this type, this one featured the eight most recent additions to their news pages (though that number could vary).

The teasers in this block contained a summary of the article and an image. The images could be large and the content long, so a carousel that rotated between teasers was the right solution here.

Again using jQuery, I targeted the DIV wrapper for the carousel and, after the page had loaded and the document was ready, applied the carousel and set my transitions. With JavaScript enabled, the home page rendered nicely: every 15 seconds, the carousel shuffled to the next teaser. By default, all of the teasers were visible, but I hid all but the first when I created the carousel.

For this client, we again chose to display all hidden content if JavaScript was disabled. In that case, the home page would expand vertically to accommodate the extra content.

We had alternatives, though. Considering the four categories of users we identified at the beginning of this article, the priority for this content was accessibility, with search engine ranking a close second. We could have satisfied these two groups by leaving all of the teasers visible but fixing the dimensions of the container DIV and setting overflow to scroll, auto or hidden.

Any of these options would have preserved the layout’s dimensions. And screen readers and search engines would have picked up on the content, too, because the content would not be hidden with the display or visibility property.

The Content Swapper

This technique is similar to the carousel in that content in a block is rotated using some animation.

The main difference is that the tweening animation is not used; instead, one piece of content fades out while another fades in (or you could have a hard transition with no fade). The swapper is similar enough to the carousel that the alternative no-JavaScript solutions mentioned above hold true.

Yet another client came to me with the task of showing an indefinite number of testimonials on their website. We opted for a content swapper in this case because we had no need for the pagination typically found in carousels (the user wouldn’t need to scroll back one testimonial or skip to the end).

For visitors who had JavaScript disabled, we respected the design. After careful consideration, the client rightly determined that the testimonials would have such a small effect on visitors that setting the display to none would not be detrimental.

The decision afforded me a little more freedom in planning the right-hand column of the website, where the testimonials were to appear.

The Sorter

Anyone who has adjusted their Hulu queue has seen the drag-and-drop sorter. This bit of JavaScript allows users to drag and drop rows (table rows, list items, independent DIVs, etc.) into a different order.

Netflix’s sorter

Take one last client of mine as an example, who had a set of standard procedures that all employees had to follow.

Each procedure consisted of any number of tasks. An administrator could add or remove tasks and could change the order of tasks.

This was a textbook example of sorting, an implementation of drag-and-drop reordering.

Thanks to Scriptaculous and Prototype.js, creating the sortable list was easy. When the code was written and the page was live, we had a perfectly operable rendering of the design comp. Then we realized that without JavaScript, we had only the HTML equivalent of a paper weight. There was no drag-and-drop or on-the-fly reordering.

Some quick thinking and slight modification of the design gave us the same set of rows we had before but with the addition of text input boxes that could accommodate the inputting of row order (note, though, that without JavaScript, we were forced to add some significant server-side validation for these input boxes). We lost on-the-fly reordering, but at least we regained the sorting functionality.

Then we turned back to JavaScript-enabled browsers and hid the text boxes mentioned above; after all, we had drag-and-drop functionality for this group. At this point, we had a perfectly operable rendering of the design comp that was also serviceable for visitors who had JavaScript disabled. Next time, I’ll know to plan for this condition.

Conclusion

The evolution of the web will continue, and visitors to our websites should be able to continue enjoying dynamic flair.

Carry on planning for interactive responses with animated tweens: fade in, fade out, collapse, expand, slide things around. Given all of this animation, think of how your website will appear to visitors who cannot see the animation because of JavaScript limitations. Your clients will be happier, and you’ll be a better designer for it.

http://www.thecounter.com/stats/2008/January/javas.php
http://www.w3schools.com/browsers/browsers_stats.asp

Jason Corns is a freelance web developer and full-time GUI developer for Systems Alliance, Inc., specializing in usability for all audiences.

How do YOU plan for the absence of JavaScript? Please share your tips with us…

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C

A link is either one color or another. A text field is either one size or another. A photo is either transparent or opaque. No in-betweens from one state to the next. No transitions.

This has led to most web pages feeling abrupt, with elements shifting and changing ungracefully.

Yes, we can use DHTML and leverage the jQuery library for transitions, but this requires a lot of code for something that should be very simple.

What we need is a quick and easy way to add simple transitions to the page and in this article you’ll find useful information about CSS transitions and how to use them.

A few months back, I stuck my foot in my mouth by suggesting that designers should start using the new CSS 3 techniques that allow them to do some of the basic styling that they’ve been pleading for. The only issue: none of them worked in Internet Explorer. Nope, not even IE8.

Some readers felt that suggesting techniques that around 75% of audiences would not be able to see was imprudent.

To those readers I say, ‘Hold onto your hats’, because I’m going to introduce you to another new CSS property that allows you to add transitions to any element with only a couple of lines of code.

CSS transitions are being introduced right now in CSS Level 3 but have already been added as an extension to Webkit. Right now that means they work only in browsers based on Webkit, including Apple Safari and Google Chrome.

Where CSS Transitions Come From

Transitions have been a part of Webkit for a while and are the basis of a lot of the cool things that the Safari UI can do that other browsers cannot.

But the W3C CSS Workgroup resisted adding transitions to its official specs, some members arguing that transitions are not style properties and would be better handled by a scripting language.

But many designers and developers, myself included, argued that these are in fact styles— only dynamic styles, rather than the traditional static styles that so many of us are used to.

Fortunately, the argument for dynamic styles held the day. Last March, representatives from Apple and Mozilla began adding the CSS Transitions Module to the CSS Level 3 specification, closely modeled on what Apple had already added to Webkit.

A Brief Note on Design Enhancements

Before we continue, let me emphasize one point: never rely on styles for website functionality if the styles are not browser interoperable (i.e. available on all common browsers).

One more time for those who missed it: never rely on styles for website functionality if the styles are not browser interoperable.

That said, you can use styles, such as transitions, as design enhancements to improve the user experience, without sacrificing usability for those who cannot see them. This is okay as long as you could otherwise live without the transitions and users can still complete their tasks.

First, a Few Transition Ideas

CSS transitions will not replace all uses of DHTML, but here are a few ways to enhance your design in browsers that support transitions, without ruining it for the rest of your audience.

You will need to view this page in Apple Safari 3+ or Google Chrome to see these transitions work. Both browsers are available in Mac and PC flavors.

Roll-Overs

The most obvious use for transitions is to highlight elements (whether links, tables, form fields, buttons or something else) when the user’s mouse hovers over them. Transitions are a great way to give the page a smoother look.

Example #1

Drop-Down Menus

Pure CSS menus are easy to accomplish, and transitions let you give menus slide-down and highlighting effects.

Example #2

Animation

You can move an object between two points on the page and use transitions to animate its movement.

Example #3

Click & Hold!

Transitions, States and Actions

But hold on a minute there, Tex. Before diving into transitions, we have to understand the various states to which an element can transition.

States define how a particular element currently interacts with the user or the page, and they are specified in CSS using the pseudo-classes. For example, when the user hovers over an element, that element would be styled with the hover pseudo-class.

Transitions work by changing a style over a period of time between different element states. For example, the color value of the default state of an element will pass through intermediate colors in the spectrum before appearing as the color value for the hover state.

A Simple Transition

Let’s consider a simple transition from one color to another when the user hovers over a link. Like any other CSS property, transitions are added directly to the selector that it is to be applied to. The property can then take one of following four values.

CSS property
The property that is to be altered (for example, color). See the table below for a list of all of the CSS properties that can be transitioned.

Duration
How long the transition will last, generally in seconds (for example, .25s).

Timing function
Allows you to control how the duration is timed. Rather than using a simple linear count, you can speed up or slow down the transition or even specify a beat or count (for example, linear). More on this later in the article.

Delay
How long to wait between the action and the beginning of the transition, usually expressed in seconds (for example, .1s). This value can be omitted if you don’t want a delay.

Because the transition property started out as a Webkit extension, we have to include both the transition and -webkit-transition properties for backwards compatibility.

Let’s first add both of these properties to the :hover pseudo-class:

<br />
a:hover {<br />
   color: red;<br />
   -webkit-transition: color .25s linear;<br />
   transition: color .25s linear;<br />
}<br />

Now, when a link is hovered over, rather than jumping from blue to red, it will transition for a quarter of a second through the intermediate colors.

Of course, we also want to transition back to the default link color, so we’ll add a transition to the :link (and probably :visited) pseudo-classes, with just a very brief delay (one-tenth of a second) before it fades:

<br />
a:link, a:visited {<br />
   color: blue;<br />
   -webkit-transition: color .25s linear .1s;<br />
   transition: color .25s linear .1s;<br />
}<br />

Adding Multiple Transitions

Because a transition is a CSS property, if you add multiple instances of the transition property in the same rule, then the last one will override previous ones, rather than add to them. So in the following rule, the only transition would be the background color:

<br />
a:hover {<br />
  color: red;<br />
  background-color: rgb(235,235,185);<br />
  -webkit-transition: color .25s linear;<br />
  transition: color .25s linear;<br />
  transition: background-color .15s linear .1;<br />
}<br />

Multiple transitions are added as a comma-separated list in the same transition property definition:

<br />
a:hover {<br />
  color: red;<br />
  background-color: rgb(235,235,185);<br />
   -webkit-transition: color .25s linear, background-color .15s linear .1s;<br />
  transition: color .25s linear, background-color .15s linear .1s;<br />
 }<br />

This will create both a color and background-color transition.

What Can Be Transitioned?

Almost any CSS property that has a color, length or position component, including many of the new CSS 3 properties, can be given a transition. One notable exception seems to be box-shadow.

Straight from the W3C’s Transitions spec, here is a list of CSS properties that can be given a transition, along with the aspects that are transformed. I’ve highlighted a few of the more useful properties.

Transition Timing and Delay

With transitions, you can vary the count rate, counting slower at the beginning and speeding up at the end, vice versa, or anything in between. CSS transitions come with five keywords for transition timing and allow you to specify values for your own timing curve.

A Universal Transition?

Transitions will quickly become standard operating procedure for all websites, enhancing user interface feedback.

To add ubiquitious transitions across your entire website, one option is to add a transition to the universal selector, similar to a CSS reset. This applies a default transition to all elements on the page, allowing you to keep a consistent transition:

<br />
*:link, *:visited, *:hover, *:active, *:focus {<br />
   -webkit-transition:<br />
     color .25s linear,<br />
      background-color .25s linear,<br />
     border-color .25s linear;<br />
   transition:<br />
     color .25s linear,<br />
     background-color .25s linear,<br />
     border-color .25s linear;<br />
}<br />

One argument against a universal transition, and indeed against using the universal selector for CSS resets in general, is that applying a style to every element on the page may slow down page rendering. However, I’ve never found any evidence that this is the case. Anyone know different?

Jason Cranford Teague is the author of more than 13 books on digital media, including Speaking In Styles: The Fundamentals of CSS for Web Designers. For more information on CSS and web typography, check out Jason’s new book, Fluid Web Typography. Follow Jason on Twitter: @jasonspeaking.

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C

There are however, challenges in implementing Ajax functionality on a web page.

In this article we’ll discuss solutions to five of the most common challenges that a developer faces when using Ajax to enhance the content on their website.

Although there is a lot more to discuss and research on all five topics, this post should give beginners and intermediate Ajax developers some solid tips on implementing Ajax functionality in a more user-friendly and accessible manner.

Problem #1: Content Is Not Backwards-Compatible

This problem occurs when a designer has incorporated JavaScript and Ajax enhancements into their website’s architecture without making provisions for browsers that have disabled JavaScript.

Nothing is wrong with planning a website with JavaScript and Ajax; in fact, in today’s market, JavaScript considerations should be integral to the planning process. But you should still ensure that the website is backwards-compatible (or that it degrades gracefully) upon launch.

Solution: Implement Ajax as an Enhancement to an Already-Functioning Website

While Ajax may be integral to your planning of the website’s architecture, ensure that all content is accessible through conventional server-side methods.

Let’s say you have an “Employee Information” page that has a separate link for each employee. Using server-side technology, you could display the content for a particular employee based on a value passed through the query string, like this:

<a href="employees?view=CEO">John Doe - CEO</a>
<a href="employees?view=VP">Frank Smith - Vice President</a>
<a href="employees?view=Accountant">Jim Williams - Accountant</a>

All of the links above point to the same page, the “Employees” page, which changes according to the variable in the query string. Each employee’s information would be loaded from the server, which could be done in a number of ways: via server-side includes; through a database; or even using XML.

Whichever employee link is clicked, the full page would have to load in order for the requested information to be delivered.

So, the content is fully accessible before any Ajax enhancements are layered on top. Then, using JavaScript, the full page refresh could be interrupted and the content loaded instead via Ajax. The clicked link could be identified by an ID or by checking the value of the HREF attribute in the anchor.

Although the content is fully accessible with JavaScript disabled, most users will see the enhanced Ajax-driven version.

The principle of progressive enhancement for Ajax is well known, because it is commonly used for unobtrusive JavaScript techniques and is inherent in CSS, as illustrated by the graphic below:

So, build your website to work without JavaScript, and then add JavaScript as an enhancement, just as you would mark up your content in HTML and then “enhance” it with CSS.

Problem #2: The Browser’s Loading Indicator Isn’t Triggered by Ajax Requests

Almost every browser has a way of visually indicating to the user that content is loading. In current browsers, the indicator appears on the tab that’s loading the content.

The images below show this animated indicator from a few popular browsers.

Internet Explorer’s loading indicator is a solid circle with a gradient that spins while the content loads.

Firefox displays a similar icon of small spinning circles in different shades of gray.

Google Chrome spins a half-circle.

The problem is that Ajax requests do not trigger this “loading” indicator that is built into browsers.

Solution: Insert a Similar Loading Indicator Near Content That’s Loading

The common solution to this is to incorporate a custom progress indicator into the Ajax request. A number of websites offer free “Ajax loading” graphics.

Preloaders.net has a number of fancy, customizable animated graphics to choose from.

Implementing this custom loading graphic, or progress indicator, into your website’s Ajax functionality is simply a matter of showing and hiding it at the appropriate times via JavaScript.

Your Ajax code will include lines of code that tell you if the request is in progress or completed. Using JavaScript, you can show the animated graphic while the request is being processed and then hide it when the action has completed.

Problem #3: The User Doesn’t Know That an Ajax Request Has Completed

This is related to the previous problem but is often overlooked, because the developer might assume that the disappearance of the “loading” indicator suffices to inform the user that the content has completely loaded. But in most cases, definitively indicating that content has been updated or refreshed is better.

Solution: Use a Distinct “Request Completed” Message

This can be done similar to how form submissions are confirmed. After a link has been submitted on Digg, the page lets you know very clearly that your submission has been received:

Although this particular indicator does not point out a completed Ajax request, the principle is the same: the “Success” box appears after the page that submits the form has finished loading, and the box is colorful and distinct.

A similar graphic or indicator could be used at the end of an Ajax request to tell users that content has been updated. This would be implemented in addition to, not instead of, the progress indicator proposed for the previous problem.

A similar but subtler way to indicate that an area of content has been updated is the yellow fade technique. This method is familiar to users, unobtrusive and works well with Ajax-loaded content.

Problem #4: Ajax Requests Cannot Access Third-Party Web Services

The XMLHttpRequest object, which is at the root of all Ajax requests, is restricted to making requests on the same domain as the page making the request. But there are instances when you would want to access third-party data via an Ajax request. Many web services make their data accessible via an API.

Solution: Use Your Server as a Proxy

The solution to this problem is to use your server as a proxy between the third-party service and browser. Although the details of this solution are far beyond the scope of this article, we’ll go over the basic principle at work.

Because an Ajax request originates in the client’s browser, it must reference a file at another location but on the same domain as the source of the request.

Your server, however, unlike the client’s browser, is not limited in this way. So, when the page on your server is called, it runs in the background as it normally would but with access to any domain.

This doesn’t present any security risk to the user because the requests to the third-party service are made on your server. So, once the information has been obtained at the server level, the next step in the Ajax call is to send a response back to the client, which in this case would include the data obtained from the third-party web service.

If you want more details on this powerful method of combining web-service access with custom Ajax, definitely check out other resources, some of which are listed below.

Further Reading:

• Use a Web Proxy for Cross-Domain XMLHttpRequest Calls
• Cross Domain Ajax: a Quick Summary
• Cross domain AJAX querying with jQuery

Problem #5: Deep Linking is Not Available

This is a trickier issue but may not be required depending on your type of website or application. The problem occurs when content is loaded via Ajax and then the “state” of the website is changed without the URL that points to the page being affected.

If the user returns to the page via a bookmark or shares the link with a friend, the updated content will not be automatically displayed. The website would instead revert to its original state. Flash websites used to have the same problem: they did not allow users to link to anything but the initial screen.

Solution: Use Internal Page Anchors

To ensure that a particular “state” on an Ajax-driven web page is linkable and bookmarkable, you can use internal page links, which modify the URL but don’t refresh the page or affect its vertical position.

This simple code demonstrates how this is done:

var currentAnchor = document.location;
currentAnchor = String(currentAnchor);
currentAnchor = currentAnchor.split("#");
if (currentAnchor.length > 1) {
	currentAnchor = currentAnchor[1];
} else {
	currentAnchor = currentAnchor[0];
}
switch(currentAnchor) {
	case "section1":
	// load content for section 1
	break;
	case "section2":
	// load content for section 2
	break;
	case "section3":
	// load content for section 3
	break;
	default:
	// load content for section 1
	break;
}

The above is not a functioning piece of code but rather a theoretical example to demonstrate the main steps involved.

The first two lines of code put the current page location (URL) in a variable. Then the location is converted to a string so that we can manipulate it.

Next, we “split” the string into two parts via the anchor symbol (#) and subsequently check to see if the array that is created from the split is greater than one item. Greater than one item means that the URL has an anchor.

If the URL has only one part, that means no anchor is present. The subsequent “switch” statement loads content according to the value of the anchor. The switch statement has a “default” option in case no anchor is present, which would be the same as loading the page in its original state.

Furthermore, we would apply code to deal with links that point directly to specific content through internal anchors. A link that points to “content2″ would load the content in “content2,” and the string “#content2″ would be appended to the current URL.

This would change the URL by adding an internal anchor, without changing the view of the page but preserving an identifier that indicates the desired state of the page.

This explanation is only theory. The concept works, and it works very well. But I haven’t explained all of the possibilities, drawbacks and other subtleties of building a website or page in this manner.

Follow the links below for a more comprehensive discussion of the topic, or experiment with it yourself. Also, note that this can be tested using content that changes with JavaScript alone, and doesn’t need to utilize Ajax.

Further Reading:

• Deep Linking for AJAX
• AJAX: How to Handle Bookmarks and Back Buttons
• Fixing the Back Button and Enabling Bookmarking for AJAX Apps

This post was written exclusively for Webdesigner Depot by Louis Lazaris, a freelance writer and web developer. Louis runs Impressive Webs, where he posts articles and tutorials on web design. You can follow Louis on Twitter or get in touch with him through his website.

Do you know of any solutions to these or other Ajax challenges? Please share your comments below…

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C

Sometimes it’s the result of sloppy coding from the start, sometimes it’s because of multiple hacks and changes over time.

Whatever the cause, it doesn’t have to be that way. Writing clean, super-manageable CSS is simple when you start off on the right foot and make your code easier to maintain and edit later on.

Here are 11 tips for speeding up the process, writing CSS that is slimmer, faster and less likely to give you a headache.

1. Stay Organized

Just like anything else, it pays to keep yourself organized. Rather than haphazardly dropping in id’s and classes in the order in which they come to mind, use a coherent structure.

It will help you keep the cascading part of CSS in mind and sets your style sheet up to take advantage of style inheritance.

Declare your most generic items first, then the not-so-generic and so on. This lets your CSS properly inherit attributes and makes it much easier for you to override a specific style when you need to. You’ll be faster at editing your CSS later because it will follow an easy to read, logical structure.

Use a structure that works best for you while keeping future edits and other developers in mind.

• Resets and overrides
• Links and type
• Main layout
• Secondary layout structures
• Form elements
• Miscellaneous

2. Title, Date and Sign

Let others know who wrote your CSS, when it was written and who to contact if they have questions about it. This is especially useful when designing templates or themes.

Wait a minute… what’s that bit about swatch colors? Over the years, I’ve found that adding a simple list of common colors used in my style sheets is extremely helpful during initial development and when making edits later on.

This saves you from having to open up Photoshop to sample a color from the design, or look up colors in the site’s style guide (if it has one). When you need the HTML code for that specific blue, just scroll up and copy it.

3. Keep a Template Library

Once you’ve settled on a structure to use, strip out everything that isn’t generic and save the file as a CSS template for later use.

You can save multiple versions for multiple uses: a two-column layout, a blog layout, print, mobile and so on. Coda (the editor for OSX) has an awesome Clips feature that lets you do this easily. Many other editors have a similar feature, but even a simple batch of text files will work nicely.

It’s insane to re-write each and every one of your style sheets from scratch, especially when you’re using the same conventions and methodologies in each.

4. Use Useful Naming Conventions

You’ll notice above where I declared a couple of column id’s and I called them col-alpha and col-beta. Why not just call them col-left and col-right? Think of future edits, always.

Next year you may need to redesign your site and move that left column to the right. You shouldn’t have to rename the element in your HTML and rename the id in your style sheet just to change its position.

Sure, you could just reposition that left column to the right and keep the id as #col-left, but how confusing is that? If the id says left, one should expect that it will always be on the left. This doesn’t leave you much room to move things around later on.

One of the major advantages of CSS is the ability to separate styles from content. You can totally redesign your site by just modifying the CSS without ever touching the HTML. So don’t muck up your CSS by using limiting names. Use more versatile naming conventions and stay consistent.

Leave position or style specific words out of your styles and id’s. A class of .link-blue will either make more work for you, or make your style sheet really messy when your client later asks you to change those blue links to orange.

Name your elements based on what they are, not what they look like. For example, .comment-blue is much less versatile than .comment-beta, and .post-largefont is more limiting than .post-title.

5. Hyphens Instead of Underscores

Older browsers like to get glitchy with underscores in CSS, or don’t support them at all. For better backward compatibility, get into the habit of using hyphens instead. Use #col-alpha rather than #col_alpha.

6. Don’t Repeat Yourself

Re-use attributes whenever possible by grouping elements instead of declaring the styles again. If your h1 and h2 elements both use the same font size, color and margins, group them using a comma.

This:

You should also make use of shortcuts whenever possible. Always be on the lookout for opportunities to group elements and use declaration shortcuts.

You can accomplish all of this:

with only this:

It’s very important that you understand the order in which CSS interprets these shortcuts: top, right, bottom, left. A big clockwise circle, starting at noon.

Also, if your top and bottom, or left and right attributes are the same, you only need to use two:

This sets the top and bottom margins to 1em, and the left and right margins to 0.

7. Optimize for Lightweight Style Sheets

Using the above tips, you can really cut down the size of your style sheets. Smaller loads faster, and smaller is easier to maintain and update.

Cut out what you don’t need and consolidate wherever possible by grouping. Use caution when using canned CSS frameworks as well. You’re likely to inherit lots of bulk that won’t be used.

Another quick tip for slim CSS: you don’t need to specify a unit of measure when using zero. If a margin is set to 0, you don’t need to say 0px or 0em. Zero is zero regardless of the unit of measure, and CSS understands this.

8. Write Your Base for Gecko, Then Tweak for Webkit and IE

Save yourself troubleshooting headaches and write CSS first for Gecko browsers (Firefox, Mozilla, Netscape, Flock, Camino). If your CSS works properly with Gecko, it’s much more likely to be problem free in Webkit (Safari, Chrome) and Internet Explorer.

9. Validate

Make use of W3C’s free CSS validator. If you’re stuck and your layout isn’t doing what you want it to do, the CSS validator will be a big help in pointing out errors.

10. Keep a tidy house

Separate browser-specific CSS to its own individual style sheet, and include as needed with Javascript, server-side code or conditional comments. Use this method to avoid dirty CSS hacks in your main style sheets. This will keep your base CSS clean and manageable.

Written exclusively for WDD by Jeff Couturier

Do you follow these methods when coding your websites? What other techniques do you use to create better code?

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C

The good news is that Chrome is a lot more compatible with web standards than IE 5 and 6. However, Chrome has its own idiosyncrasies and bugs.

No one knows if Chrome is here to stay, but it has already captured a surprisingly decent share of the web browser market in a short period of time.

Here are some tips to get your web pages working in Chrome and hopefully looking the way they were designed to look.

Mac Users

As of February 2009, Chrome is still a browser for Microsoft Windows PCs. If you use a Mac, you will need to run Microsoft Windows through Bootcamp, or one of the virtualization products for the Mac (Sun’s VirtualBox, Parallels, VMWare Fusion). If you are really daring, you can try and get Chrome to run using Darwine. Google promises to have a native Mac version of Chrome available in the coming months.

Vanishing Pop-Ups

Pop-Up blocking is great unless your website really needs pop-up functionality. If you have a web page that must use pop-ups, you won’t see them in Chrome. By design, Chrome only displays the title of a pop-up and minimizes it to the bottom right corner of the browser window. Users will need to click and drag the pop-up’s title in order to view its content.

SSL is Broken?

By design, Chrome will only certify a valid SSL (secure sockets layer) page with the padlock icon if all the elements on the page are served via SSL. In other words, if your page is served via SSL but it calls elements via non-secured HTTP, Chrome will give your page an exclamation point icon indicating that it considers your page to be an inconsistent SSL transmission. To get around this, make sure that all the resources loaded by your web page, including all images, are prefaced with HTTPS.

Declare Encoding First

If your web page text is garbled or otherwise just plain wrong in Chrome, you may need to insert encoding information into the <head> section of each web page. If you already have encoding information, it must come first, before any CSS or Javascript. Otherwise, Chrome will just ignore it. A working example:

<html>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=windows-1251″>
<script type=”text/javascript”>
… your JavaScript code …
</script>
… your CSS code …

Also, Chrome will ignore encoding specified by Javascript. Period. For example, the following would be ignored:

document.write(”<meta http-equiv=”Content-Type” content=”text/html; charset=windows-1251″>”);
Instead of using JavaScript, you must insert your encoding into the beginning of the <head> section of each web page as shown above.

Bookmark Favorites

When users choose to bookmark your web site, you can control the default bookmark name, description, link, and bookmark icon. Just make sure to place your code in the <head> section of your web pages. Here is a working example:

<head>
<meta name=”application-name” content=”Greatest Website”/>
<meta name=”description” content=”The very best on the web”/>
<meta name=”application-url” content=”http://www.superfantasticgreatestweb.com”/>
<link rel=”icon” href=”great-icon_32×32.png” sizes=”32×32″/>
<link rel=”icon” href=”great-icon_48×48.png” sizes=”48×48″/>
</head>

Fixing JavaScript

If your JavaScript is not working properly in Chrome, check Chrome’s JavaScript console, accessible from the Page menu icon -> Developer -> JavaScript console. That should give you some direction as to what you can change.

For the more advanced JavaScript developers, you can also use the JavaScript Debugger, accessible from the Page menu icon -> Developer -> Debug JavaScript. That will allow you to watch variables and set breakpoints.

CSS Image Problems

If you are using images or backgrounds implemented through CSS and they are not rendering properly in Chrome, you might want to convert images between GIF, JPG, and PNG to see if a different image format solves your problems. Although this makes no sense, it sometimes works, especially with random spacing and image formatting problems.

CSS “First” Selector Hack

Chrome can be finicky and unforgiving about CSS and may ignore styles applied to certain page elements. You might try using the “first-of-type” keyword which will be ignored by all other browsers (except for Apple’s Safari). For example, if you cannot get a particular style applied to the <body> section of your web page to work in Chrome, add in something like the following:

body:first-of-type p {color:#ff0000;}

“First-of-type” will simply be ignored by the browsers that are already displaying your page the way you intended.

GiantIsland CSS Hack

Chrome interprets cascading style sheets (CSS) differently than other browsers. Then again, IE 5, 6, and 7 do not even interpret CSS the same! The GiantIsland CSS Hack is a relatively simple CSS markup hack that makes use of square brackets [ ] to target CSS on specific browsers like Chrome. As a bonus, it can also help you conform your CSS to IE 5, 6, 7, Safari, and Firefox, all at the same time. For more details, check it out at http://www.giantisland.com/Resources/LitePacificHackforSafariAndIE7.aspx.

Stay Away from HTML5

Chrome does not try to conform to HTML5 API standards yet, even though Webkit, its rendering engine, does support HTML5. If you use HTML5 features or syntax, you will likely run into problems. Stick with HTML4 standards and you should have an easier time. Chrome will likely support HTML5 in the near future.

Validate Your Pages

Before swearing at Chrome and throwing in the towel, validate your pages to make sure you have not inadvertently used a non-standard HTML call. You can validate any web page at http://validator.w3.org/. Some web browsers allow you to take some shortcuts with web standards, but Chrome is not very lenient.

Try it with Safari

If you can’t get your web pages to look right under Chrome no matter what you try, try your web pages in Safari before giving up. Safari is Apple’s web browser and is available for both Mac and Windows PCs. If you use Windows, you can freely download Safari from Apple at http://www.apple.com/safari/download/. Both Chrome and Safari are built using the open source “Webkit” browser rendering engine. If you can see a rendering error in both Chrome and Safari, there is a good chance that Webkit is the culprit. You can post a bug for the Webkit developers at http://webkit.org/quality/reporting.html.

Aw Snap!

The Chrome developers have provided some funny error messages (if an error can be considered funny). If Chrome gives you the dark grey “Aw Snap!” page which also says “Something went wrong while displaying this webpage,” it might not be your web page at all. Chrome has a tendency to crash on some PCs depending on system settings and other installed applications. Try a few other well-known web pages, and see if they crash. Also try closing Chrome, re-launching it, and then test your web pages again. Some people have found Chrome to be unstable on some PCs. Google intends for Chrome to become more sturdy with each new version.

Bug Reporting

If you find a bug with Chrome’s rendering, report it! You will be making the world a better place. Google maintains a public bug list for Chrome at http://code.google.com/p/chromium/issues/list.

Written exclusively for WDD by Derek Underwood, a professional web designer and software developer. You can read more about Derek and contact him at his website:
http://www.derekunderwood.com

Have you been testing your web pages in Chrome? Do you think Chrome is here to stay? Share your opinions and experiences.

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C

Doing development is something for those programming grunts, those code jockeys, those geeks.

Why should we enter the trenches of development when it’s so nice up here with the Photoshop brushes, afternoon tea, and MacPros? 

Because you’ll be a better designer for it.

Skeptical? Read on and discover 6 reasons why designers should code…

1. Better XHTML

I’ve worked with and known many designers who knew only the bare minimum needed to get their designs out of Photoshop and into a web format. Oftentimes they would make use of a software program or plugin like SiteGrinder. While these programs keep getting better and better at making compliant code, they still don’t match the human-produced variety.

Knowing how to write your own standards-compliant XHTML will make you a valuable addition to any web team (emphasis on the standards-compliant part). With all the fuss about PHP, ASP.NET, Ruby, and many other languages, people tend to forget that everything ends up being HTML in the end, because that’s what your browser has to have in order to render a page. The more you know about the medium you work in, the better you work in that medium.

2. Better SEO

And while we’re talking about standards-compliant code, we should mention SEO. This is a big buzzword, though not quite as much as it has been in the past. However, what this means is that SEO is becoming a much more commonplace idea of what a website should strive for, instead of just an added special feature for big business sites.

If you can learn to write your own code, you’re much closer to being able to list “SEO Compliant Designs” on your sheet of available services. That means you can charge more, and it’s another badge on your hat.

3. Better Accessibility

Better code and better SEO = better accessibility. Part of of the job of any designer is to present information in a clear and coherent manner, and on the web that means not solely in a visual manner. A shoddily-coded website can be a nightmare to navigate if you’re blind, or even if you’re using a mobile device.

Learning the ins and outs of developing code for accessibility not only allows you have that knowledge as part of your production skillset, but it will also help you to better understand the considerations you should take when designing for accessibility.

Accessibility is a mandate for all government websites, nearly all education sites, and businesses are starting to see the value in it as well. The more people you can reach via your site, the more chance you have of accomplishing your goal, whatever it may be. And that has to be reflected in any successful design.

4. Better Left Side

Being a right-brained creative is great, but giving your left side a workout can spur on creativity of a different nature. The motto at the bottom of the WordPress website is “Code Is Poetry”, and this is because translating a written language to something that can be visually seen is truly an art form.

Learning to write your own code opens up whole new avenues of expression. Developing your technical and analytical abilities can improve your information design, developing wireframes, and create a pathway to work with interaction design. And who knows, it may even improve your math skills!

5. Better Communication

It’s easy to get lost in the techno-jargon used by developers, simply because you may not have been exposed to the type of things they are discussing. Digging in and working with code yourself will allow you to become familiar with the terminology that is used when conversing about the construction of a site.

Being able to speak the lingo will help when you need to communicate with a developer or project manager about how a design should be implemented.

6. Better Design

You can only do so much knowing the fundamentals of design. Typography, color theory, composition, etc. are all fantastic and extremely important skills to know (and know well)…but eventually if you want to excel in your creativity, you must learn the tools of the trade. Painters learn about canvas types, paint compositions, and bristle qualities. Web design is no exception. Learn to code: you’ll be better for it.

Written exclusively for WDD by Ryan Burrell.

Are you a designer that codes? Should all designers learn how to code? Please share your comments below.

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C

Although Mac OS X comes with Apache and PHP, you don’t want Apple’s automatic software update to break your development environment by changing your working versions of PHP and Apache. Plus, do you really want to spend time tweaking MySQL?

In this guide, I will show you how to quickly install and configure a working WordPress environment including Apache, PHP, and MySql.

1. Turn off Web Sharing

First, you need to make sure the Mac OS X installation of Apache is not running. Navigate into your System Settings and check the “Sharing” settings. You want to turn off “Web Sharing” if it is currently enabled.

2. Use MAMP

MAMP is a free and ready-to-go install of Apache, MySQL, and PHP for Mac OS X. It is developed by Living-e. They also have a “Pro” version at additional expense. One of the great things about MAMP is that it includes almost every PHP option pre-installed and enabled. As a bonus, it comes with phpMyAdmin to help you work with databases quickly. To get MAMP, open up your web browser and go to http://www.mamp.info/en/download.html. Download MAMP, mount it, and then drag the MAMP folder into your Applications folder. You can safely ignore the “MAMP Pro” folder.

3. Configure MAMP

Go into the MAMP folder and then open the MAMP icon.

The status lights will tell you if Apache and MySQL are running. If the lights are red, click “Start Servers”. Next, modify the ports for Apache and MySQL by selecting “Preferences” and select “Set to default Apache and MySQL ports.” You should end up with port 80 for Apache and port 3306 for MySQL. Next, click on the Apache section and change the Document Root to a location that you can quickly access. All your websites will reside in this location, so you want to pick something that you can navigate into easily. I like to use a root folder called “webspace” that I created in the Finder.

4. Make a Database for WordPress

WordPress requires a MySQL database to store posts and settings. You already have MySQL running, but you need to create a separate database for each WordPress website that you develop on your Mac. From the main MAMP menu, click on “Open start page.” Your web browser should pop open up to a “Welcome to MAMP” page.

Next, click on “phpMyAdmin” to launch the phpMyAdmin web application. Look for the section entitled “Create new database” and name your database. As an example, enter “wp-superblog” and click “Create” to make a database.

5. Make a folder for your website

Within your “webspace” folder, make a new folder with the name of the website that you will be developing. As an example, make a folder called “super-blog” to correspond to the database you made.

6. Install WordPress

The easiest way to download WordPress is to point your web browser to http://www.wordpress.org/latest.zip Unzip the WordPress package and copy everything in the WordPress folder into your “super-blog” folder.

7. Configure WordPress

Navigate into your “super-blog” folder and locate a file called “wp-config-sample.php”. Open that file and change both the database username and password to “root” on lines 4 and 5. Next, make sure the name of your database (“wp-superblog” in our example) is shown on line 3. Save the changes you made to this file and then rename the file “wp-config.php”.

8. Take a Test Drive

Open up a web browser and navigate to “localhost”. You should see a folder for each website you are developing. In our example, you should see a folder named “super-blog”. If you click on it, you should instantly get to your new WordPress website.

9. Turning MAMP on and off

When you are not developing and testing a website, you may want to turn off Apache, PHP and MySQL. MAMP comes with a dashboard widget that will turn your environment on and off instantly. You can find the widget in the MAMP folder.

Written exclusively for WDD by Derek Underwood, a professional web designer and software developer. You can read more about Derek and contact him at his website: http://www.derekunderwood.com

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C

There are many rich-text editors out there. What’s even better than a lot of choices? Many of the best rich-text editors currently in the market are free.

In this article, we present 20 exceptional (and free) rich-text editors.

1. TinyMCE

TinyMCE is an open source (under the GNU Lesser General Public License) rich-text editor released and maintained by Moxiecode. As indicated by the name, TinyMCE is lightweight but highly customizable through an intuitive API. TinyMCE’s plugin system allows you to download themes and plugins to extend the core installation.

TinyMCE | Demo | Download

2. FCK Editor

FCKeditor is another wildly popular open source online rich-text editor (check out some of the websites that use it). It has a “Word clean-up” feature that automatically detects and cleans up text that’s copied from Microsoft Word documents. It has one of the best HTML table editing and creation features, making it very easy for users to create and edit tables for displaying data.

FCKeditor | Demo | Download

3. NicEdit

NicEdit is lightweight, no-fuss cross-platform rich-text editor that emphasizes user-friendliness and simplicity over barraging users with too many features. You can serve NicEdit remotely from the NicEdit website; all you have to do is copy a JavaScript code snipplet and voila – it just works (as well as saving your server some system resources).

NicEdit | Demo | Download

4. BXE

BXE is an XML-based WYSIWYG editor that allows you to change an entire web page. It has been an open source application since 2002 – and with a devout following – you might be able to quickly find some help if you run into any issues in the BXE IRC channel.

BXE | Demo | Download

5. MarkItUp!

markItUp! is a JavaScript-based markup editor built on top of the jQuery library. With markItUp!, you can easily turn any HTML textarea into a fully-featured WYSIWYG editor. It’s lightweight (the script weighs in at only 6.5kb), supports keyboard shortcuts, has a built-in Ajax live preview and many more features that make markItUp! an excellent choice.

markItUp! | Demo | Download

6. WidgEditor

The widgEditor is an open source project of Cameron Adams released under the GNU General Public License. It’s a simple and no-fuss HTML rich-text editing solution that converts regular HTML textareas into a WYSIWYG. Because it’s JavaScript-based and designed to degrade gracefully, users with JavaScript turned off will still be able to use the HTML textarea.

widgEditor | Demo | Download

7. EditArea

EditArea is a free JavaScript source code editor. It’s an excellent solution for weblogs and websites that allow developers to contribute and format their own code.

EditArea | Demo | Download

8. Cross Browser Rich Text Editor (RTE)

Cross-Browser Rich Text Editor (”RTE” for short) is a free rich-text editor released under the Creative Commons Attribution 2.5 license. It’s a work based on the designMode functionality introduced in Internet Explorer 5 and implemented in the Mozilla Rich Text Editing API. It just has basic features, so it’s perfect for individuals looking to add simple rich-text editing support.

Cross-Browser Rich Text Editor (RTE) | Demo

9. YUI Library Rich Text Editor

The YUI Library Rich Text Editor is a UI control that’s part of the YUI Library. It’s a great solution for those already using YUI and individuals that want to save some server resources (since you can serve it directly from the Yahoo! servers). The YUI Library Rich Text Editor also has excellent mobile device support, making it a great web-accessible rich-text editing solution.

Yahoo! UI Library: Rich Text Editor | Demo | Download

10. FreeTextBox

Web professionals using the .NET framework that want to add editing capabilities to their web pages and web applications should check out FreeTextBox: a robust, fully-featured, and extremely popular rich-text editor for ASP.NET. It has a built-in image gallery, a helpful JavaScript API for customization, and a full list of editing controls for constructing tables, ordered/unordered lists, and even spellchecking (using the IE spellchecking engine).

FreeTextBox | Demo | Download

11. Damn Small Rich Text Editor

Damn Small Rich Text Editor (DSRTE) is a lightweight, free rich-text editor built on top of the jQuery library and a PHP backend. It’s plugin-enabled (meaning it’s highly-extensible), has image-uploading capabilities (using Ajax for responsive user interaction), and an HTML cleanup feature to tidy up messy markup.

Damn Small Rich Text Editor | Download

12. Silverlight Rich Text Editor

Silverlight rich text editor is the first rich-text editor for Silverlight. It has many useful features such as “find and replace” to quickly find specific text or to batch-replace them with something else, keyboard shortcuts support, serialization of text input for security, and much more. Note that the original creator has stopped further development (so cross your fingers someone picks up his project).

Silverlight rich text editor | Demo | Download

13. Free Rich Text Editor

Free Rich Text Editor is a free, JavaScript-based HTML rich-text editing solution released under the Creative Commons Attribution 2.5 Generic license. The interface is reminiscent of Microsoft Word 2003’s interface, so users of this desktop application will find it quite familiar. It has everything you’d expect from a robust rich-text editor, as well as a code view to preview and edit the HTML source code directly.

Free Rich Text Editor | Demo | Download

14. Dijit.Editor

The Dijit.Editor is Dijit’s (Dojo’s widget library) fully-featured rich-text editor. Built on top of The Dojo Toolkit (a popular JavaScript library/framework); it’s an excellent solution for those already using the Dojo Toolkit.

Dijit.Editor

15. WYMeditor

WYMeditor is a web-based HTML editor that emphasizes the use of standards-compliant markup. It was developed to output compliant HTML 4.01 Strict Doctype HTML, so it’s the perfect solution for the standards-aware developer.

WYMeditor | Demo | Download

16. Whizzywig

Whizzywig is a free JavaScript web-based rich-text editor. Aside from features you’d expect from a rich-text editor, Whizzywig also has a Spanish and German version, a web-safe color picker to change your text’s colors, and custom-designed UI controls.

Whizzywig | Demo

17. openWYSIWYG

openWYSIWYG is a free and feature-packed web-based content editor that’s perfect for a host of content management systems. It has a very intuitive “table creation” feature to help users construct HTML tables. It also has a wide range of browser support including IE 5.5+ (Windows), Firefox 1.0+, Mozilla 1.3+ and Netscape 7+.

openWYSIWYG | Demo | Download

18. XStandard

XStandard is a highly-standards-compliant rich-text editor. It comes in two versions: XStandard Lite – which is completely free, and XStandard Pro. XStandard Lite has Microsoft Word text cleanup, spellchecking, and the ability to interact with third-party applications.

XStandard | Download

19. Xinha

Xinha is an open source, community-built rich-text editor released under a BSD style license. It’s highly-configurable, extensible, and feature-packed. Xinha emphasizes on community development, and as such, you’ll find many helpful contributors in the Xinha forums.

Xinha | Demo | Download

20. Kupu

Kupu is an open source “document-centered” client-side rich-text editor released by the international association for Open Source Content Management (OSCOM). It features easy integration into a variety of content management systems including Silva and Plone, easy customization and extension, and Ajax saving for an uninterrupted user experience.

Kupu | Demo | Download

What’s your favorite? Do you currently use any of these rich-text editors? Do you use one that isn’t on the list? Share your experiences and thoughts in the comments.

Written exclusively for WDD by Jacob Gube. He is a Web developer/designer and author of Six Revisions, a blog on Web development and design. If you want to connect with the author, you can follow him on Twitter.

If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: H0Oa9C