One fear organizations often have when they consider moving to a CSS-based approach is whether doing so will alienate these users. The reality, though, is that a properly implemented web-standards method of web development will actually make your site more accessible to users with older browsers. You see, in the first era of web development (which lasted throughout the ’90s), we were forced to make hard choices about which browsers we would support. The vast differences between browsers meant we needed to rewrite most aspects of each site for each one, and this was only practical to do for a few choice browsers.

Plaque commemorating the creation of Mosaic web browser by Eric Bina and Marc Andreessen, new NCSA building, University of Illinois at Urbana-Champaign.

Netscape Navigator was later developed by many of the original Mosaic authors; however, it intentionally shared no code with Mosaic. Netscape Navigator’s code descendant was Mozilla.

Modern web development (using web standards), on the other hand, allows us to support all browsers—at least in some capacity. And when we refer to all browsers, we mean all. This includes the version of Mosaic released in the early ’90s all the way up to today’s browsers, browsers on alternative devices (cell phones, PDAs, game consoles, etc.), and even browsers that haven’t been imagined yet and that will show up on the devices that reach the public in 2009. Whether to exclude a browser is not a choice we have to make.

Instead, we need to consider what “support” actually means. In the past, people have taken “support” to mean “everybody gets the same thing.” Support does not mean that everybody gets the same thing. Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web. In fact, requiring the same experience for all users creates an artificial barrier to participation. Availability and accessibility of content should be our key priority.

If we support Internet Explorer 6 and Netscape 4, then the site will look virtually identical in both browsers—and so on. Thus, web designers and developers learned to use a “lowest common denominator” approach, using only the features of XHTML, CSS, JavaScript, and so forth that worked well in the oldest, poorest browser they’d chosen to support. But this thinking is flawed in that it offers benefits to no one.

Consider television. At the core: TV distributes information. A hand-cranked emergency radio is capable of receiving television audio transmissions. It would be counterproductive to prevent access to this content, even though it’s a fringe experience.

Some viewers still have black-and-white televisions. Broadcasting only in black-andwhite—the “lowest common denominator” approach—ensures a shared experience but benefits no one. Excluding the black-and-white television owners—the “you must be this tall to ride” approach—provides no benefit either.

An appropriate support strategy allows every user to consume as much visual and interactive richness as their environment can support. This approach—commonly referred to as progressive enhancement—builds a rich experience on top of an accessible core, without compromising that core.

Nate Koechley — A Senior Web Developer at Yahoo!

Broadcast television offers full color. It offers Dolby Pro Logic surround sound. It offers high-definition resolution and clarity. If your television supports these technologies, you get the richest TV experience possible. If it doesn’t, your experience will not be enhanced—but you will still get the core content of the television program. This is very much the same approach the web standards movement applies to the Web.

All browsers, no matter what device they’re on, how old they are, or how technologically inferior they are, ought to get the core content of the page (in most cases, this means text, images, etc.). The latest and greatest browser will get the richest experience. Everything else will be somewhere in between.

Development Browser

Deciding which web browser you will use as you develop CSS-based sites is a significant choice. Although different schools of thought exist, most web designers agree that developing in a solid, reliable, standards-compliant browser (such as Firefox or Safari) is best. This lets you focus on doing things the “right” way through most of your development. Then, you can go back after the fact and provide workarounds for less-ideal browsers (such as Internet Explorer). Trying to develop to the lesser browsers as you go tends to result in more workarounds than necessary and code that is less clean.

Your mileage may vary, but we recommend using Firefox as your primary development browser, not only because of its great standards support, but also because of the many great extensions available for web developers.

Use this navigation and jump directly to content :

{JPG} {GIF} {PNG} {Combination and Acquiring Images} {Creating and Editing Images with Effects and Filters} {Background Images} {General}

JPG—Did you:

1. Save photographs and other continuous tone images as JPGs, unless the images need transparency or animation?

2. Export JPGs at the lowest compression that still looks reasonably good on a web page?

3. Minimize JPG file size by adding a small amount of blur?

4. Avoid saving over the original (master) JPG?

GIF—Did you:

1. Save line-based images with areas of solid color (such as cartoons, line art, and graphic text) as GIFs?

2. Select an appropriate GIF palette, either a web-snap or a non-safe adaptive palette?

3. Explore transparent image backgrounds so that images no longer appear to be rectangles?

4. Turn on dithering if there are more than 256 colors in an image?

5. Specify interlacing, when appropriate?

6. Keep in mind the file size implications of excessive colors, vertical stripes, anti-aliasing, gradients, dithering, and textures?

7. Store a photograph as a GIF only if it needs transparency or animation, and then use a 256-color adaptive palette with dithering turned on?

PNG Images—Did you:

1. Use PNG format if you have a flat color image that needs more than 256 colors?

2. Remember that alpha transparency increases fi le sizes and may not be supported by all browsers?

3. Specify interlacing, when appropriate?

4. Store a photograph as a PNG only if it needs transparency or animation, and then use an appropriate palette with dithering turned on?

5. Use only compressed PNG files (not native Fireworks PNG files) on the web?

Combination and Acquiring Images—Did you:

1. Avoid combining GIF-appropriate and JPG-appropriate art in a single image?

2. Use stock photos and clip art when appropriate?

3. Scrupulously obey copyright laws?

4. Use screen capture software to acquire screen prints?

5. Scan photos at the appropriate resolution?

6. When possible, convert scanned images to vector format before resizing?

7. Use a digital camera rather than a fi lm-based camera, as appropriate?

Creating and Editing Images with Effects and Filters—Did you:

1. Use anti-aliasing correctly, to avoid halos?

2. Match colors across software packages?

3. Use dingbat typefaces for ornaments, bullets, and icons, and for smoother small shapes?

4. Use effects and filters appropriately to embellish the page while avoiding effect overkill?

5. Make sure that the light source for all 3-D elements on the page is at the same angle?

6. Test your effects on a lower-end computer system?

7. Contemplate using posterization, feathering, rounding, or putting an edge of some sort on a photo?

Background Images—Did you:

1. Create background images that are subtle and of low contrast, so that foreground elements are the focus and are legible?

2. Plan foreground elements so that they show up well, even with a high-contrast background, either by locking them on appropriate areas of the background or by outlining them?

3. Create a background tile of appropriate dimensions so that seams don’t show?

4. Use full-screen background images judiciously, and plan them to be relatively small files?

5. Create a large background image so that it looks complete on small screens while, at the same time, avoids tiling on the larger ones?

6. Specify the image as scrolling or fixed, depending upon which effect you want?

7. Consider wrapping the “background” image in a table or <div> so that it is positioned where you want it on the page, without tiling?

8. Consider using table cell background colors to mask the background image in content areas?

9. Think about using table cell and <div> background colors to provide a colorblocked look without the use of background pattern at all?

General—Did you:

1. Avoid gratuitous graphics?

2. Use an appropriate format: GIF, JPG, or PNG?

3. Reuse graphics throughout the site, whenever possible?

4. Crop or downsize images so that they display at the smallest reasonable size on the screen?

5. Use height and width attributes appropriately?

6. Use an alt attribute on each image?

7. Use visual echoes by repeating shapes, colors, and mood?

8. Avoid web clichés?

9. Think about the alternatives for image borders?

10. Name images by function, rather than by visual attributes?

11. Avoid animation unless to draw attention to the area you want to be the focus for your visitors?

12. Choose an appropriate animation format?

Don’t forget to look at if you already didn’t see “All In One Design Checklist” and “Checklist for Better Forms” after this article.

Clip from a print test showing where the break is between rgb(107, 107, 107) and rgb(128, 128, 128).

Now the reason why the browser vendors have made this assumption is fairly obvious: printing light text on what is almost always white paper is largely unreadable, and it is sadly very rare that web authors will take the time to style their pages for print using an alternate print style sheet (if they ever style it for print at all). Furthermore, printing in pure black, devoid of any complex color mixing, can make printing much faster, because the printer doesn’t have to mix in any red, green, or blue ink and can focus on getting the task done. But what is maddening to the designer trying to achieve accurate color representation in print from their web pages is that all of the major browsers assume that they are smarter than you, and recolor the text based on their own inconsistent algorithms. If you wanted a string of text to appear very light gray in Firefox, too bad. You are getting black whether you like it or not. Let’s look at some of the problems you might encounter.

In Safari 3 (on the left-side), gray colors print fine up until rgb(107, 107, 107). After that point there will be a strange conversion to a light gray shade, arguably the lightest gray you can get in text on Safari, between rgb(108, 108, 108) and rgb(127, 127, 127). At rgb(128, 128, 128), the text color then jumps to black and as you ascend the values toward an expected white color, Safari yields a progressive amount of additional lightness to the text until it finally winds up at around rgb(171, 171, 171), where it should be 255 for all values.

This problem also occurs in the red, green, and blue colorspaces. If we fix red at 127, about halfway between the minimum value of 0 and the maximum value of 255, we get a dead zone between rgb(127, 100, 100) and rgb(127, 127, 127). The same ratios happen starting at rgb(100, 127, 100) and at rgb(100, 100, 127). Finally, Safari renders rgb(0, 255, 255), rgb(255, 0, 255) and rgb(255, 255, 0) inconsistently from their adjacent color values.

Gecko browsers such as Firefox (before version 3), Camino, and Flock print the entire gray space in black. You cannot specify a light gray such as rgb(127, 127, 127) or anything else. It will always default to pure black whether you like it or not. If you fix a color bucket at 0, you will get semi-accurate color for the rest of the gamut, but the other color combinations will trend toward black text the lighter it gets. The exception here is Firefox 3, which will print your color exactly as specified. As of this writing, Firefox 3 is the only browser I’ve tested that gets the color matching between screen and print relatively correct.

Interestingly, the marker (the little bullet to the left of each list item) will display the correct color value in print for Firefox and Safari, even though the text itself won’t match! So at least here you can use the markers to see what the color was supposed to be…

In Opera 9, gray shades render accurately up until rgb(185, 185, 185), and then higher values default to black. In the points tested, the same conversion to black happens in various other colorspaces at different points. For instance, color values higher than rgb(127, 211, 211), rgb(255, 156, 156), rgb(87, 255, 255), rgb(209, 209, 0), rgb(193, 193, 127) and rgb(177, 177, 255) will stop rendering their expected colors and just print black instead, thank you very much.

IE7 never gets any lighter than rgb(108, 104, 102) for grayscale, and the rest of the color spaces don’t seem to allow anything lighter than a midrange hue equivalent in any given color range.

Since all the major browsers have made the assumption that you’ve neglected to pay appropriate attention to your print output with regard to color and contrast, you have to live with that and deal with some fairly tricky constraints. One argument is to give in and just go for all black text on all white paper, and certainly there’s an argument for that in terms of readability and performance. But for that argument we should all be designing white web pages with black text too and just toss out all our assumptions about color theory, design, and inspiration. We know clearly that the primary function and goal for printing a page is for reading purposes, but what if you wanted to do something else. Something more artistic, perhaps? For truly accurate printing from the Web, you may want to stick with PDF or similar output. But there’s still plenty we can do with print using plain-old HTML and CSS, and it can be an interesting academic exercise to try to design within these constraints. Think of it as a challenge that will make your professional world that much more interesting!

SVG style property/value pairs may be presented directly within the content of the markup as attributes. At the same time, SVG style properties may be treated as part of style sheets in the same way CSS works.

Here are some more property options to help you code your next work of art, along with a brief description of the intent of each property’s function:

1. alignment-baseline: A text property that specifies alignment with respect to its parent element.

2. baseline-shift: Repositions the baseline of text relative to its parent element, usually resulting in a subscript or superscript effect.

3. clip-path: Points a URI to another SVG graphic to be used as a clipping path. This can be an ID reference (such as #someClippingPath) if the SVG is embedded within the same document.

4. clip-rule: Takes one of three values: inherit, evenodd, or nonzero (default). Without getting too deep into the details, imagine two concentric circles, with a clip-rule applied to the outermost circle. With nonzero, both circles would be filled. With evenodd, the inner circle would not be filled, resulting in an annulus.

5. color-interpolation: Specifies which color space interpolation should occur in, with auto, sRGB (default), and linearRGB as possible values.

6. color-interpolation-filters: Similar to color-interpolation but applied to filter effects.

7. color-profile: Defines a color profile description. Can be used like an at-rule (@color-profile) or as a property.

8. color-rendering: Tells the user agent to optimize speed or quality using the optimizeSpeed or optimizeQuality property.

9. dominant-baseline: In typography, used to determine the baseline of the script with the dominant run. Values could be alphabetic for Western contexts, mathematical for math formulas, and ideographic for the East Asian scripts Chinese, Japanese, Korean, and Vietnamese.

10. enable-background: Describes how backgrounds are accumulated, using the property new or accumulate, or an x/y offset value.

11. fill: Paints the interior of a given element.

12. fill-opacity: Sets the opacity of the fill color.

13. fill-rule: Similar to clip-rule, using evenodd or nonzero (default) to set the fill behavior.

14. filter: Can set a URL to point to a filter that would be applied to an object.

15. flood-color: Indicates a color value to use to flood a filter subregion.

16. flood-opacity: Sets an opacity value to flood a filter subregion.

17. glyph-orientation-horizontal: Controls glyph orientation when the inline-progression direction (set by writing-mode) is vertical relative to the reference orientation.

18. glyph-orientation-vertical: Controls glyph orientation when the inline-progression-direction (set by writing-mode) is horizontal relative to the reference orientation.

19. image-rendering: Tells the user agent to optimize speed or quality using the optimizeSpeed or optimizeQaulity property. (Look at color-rendering.)

20. kerning: Adjusts length between glyphs.

21. lighting-color: Defines a color for light sources that can be applied against SVG’s and elements.

22. marker: Shorthand property for marker-end, marker-start, and marker-mid.

23. marker-end: Defines a marker or an arrow at the end of a path.

24. marker-mid: Defines markers at all vertices except for the beginning and end markers.

25. marker-start: Defines a marker or an arrow at the beginning of a path.

26. mask: References a element to implement a path used for generating a mask effect.

27. opacity: Sets the opacity of an object, using decimal values from 0 (fully transparent) to 1 (fully opaque). A value of 0.5 would be 50 percent opacity.

28. pointer-event: Controls under what circumstances an object can become the target of pointer events.

29. shape-rendering: Tells the user agent to optimize speed or quality using the optimizeSpeed or crispEdges property.

30. stop-color: Sets a color to use at a gradient stop.

31. stop-opacity: Sets an opacity used at a gradient stop.

32. stroke: Describes the stroke effect applied to an object.

33. stroke-dasharray: Sets pattern of dashes and gaps in a stroke.

34. stroke-dashoffset: Sets how far into a stroke the dash pattern will begin.

35. stroke-linecap: Sets the shape used at the end of open subpaths, using the values butt, round, and square.

36. stroke-linejoin: Sets the shape of corners, using the values miter, round, and bevel.

37. stroke-miterlimit: Sets a limit on the ratio of the miter length to stroke-width.

38. stroke-opacity: Sets the opacity of the stroke.

39. stroke-width: Sets the width of a stroke.

40. text-anchor: Aligns text to a specified point, using the values start, middle, and end.

41. text-rendering: Tells the user agent to optimize speed or quality using the optimizeSpeed or optimizeLegibility property.

42. writing-mode: Determines which direction text flows; left to right, right to left, and/or top to bottom.

Browser Support

SVG enjoys at least partial native support in modern versions of Gecko-based browsers such as Firefox, WebKit-based browsers such as Safari, and the Opera line of browsers since version 8. As you probably guessed, there are no versions of Microsoft Internet Explorer, including version 8, that support SVG.

SVG and Microsoft Internet Explorer

Fortunately for the IE users, there are excellent plug-ins that provide support for SVG.

As of 19 March 2009, Internet Explorer 8, the latest release of Windows Internet Explorer, is the only current major browser not to provide native SVG support. Internet Explorer requires a plug-in to render SVG content. There are a number of plug-ins available to assist including:

1. Adobe SVG Viewer from Adobe Systems plugin supports most of SVG 1.0/1.1. Zooming and panning of the image are also supported to enable viewing of any area of the SVG lying outside the visible area of its containing window, but scrolling is not supported. Adobe SVG Viewer is available for download from Adobe Systems free of charge. So, on 1 January 2009, Adobe Systems discontinued support for Adobe SVG Viewer. However, their motivations for discontinuing support included the fact that better options existed in the marketplace and that most browser vendors (save for the one big one) already feature native support for SVG.

2. Google Chrome Frame from Google can support all web elements supported by Webkit, including SVG 1.0 and partially SVG 1.1.

3. RENESIS Player 1.0 for Internet Explorer from examotion GmbH, first released on April 2008, supports SVG 1.1 on IE 6.x and 7.x and is available for download free of charge.

4. Ssrc SVG Plugin from Savarese Software Research Corporation is a plug-in for rendering SVG in Microsoft Internet Explorer (MSIE) versions 6, 7, and 8 on Windows XP, Server 2003, Vista, and Server 2008. In addition, the plug-in enables Internet Explorer to load Mozilla XUL applications.

5. Corel SVG Viewer.

6. Batik, a widely deployed Java plugin.

7. Bitflash, an SVG viewer intended for mobile devices, which can be installed as an IE plugin.

8. Ikivo, an SVG viewer intended for mobile devices, which can be installed as an IE plugin.

9. GPAC, targets SVGT 1.2.

Related Resources

W3C – Scalable Vector Graphics (SVG)

W3C – Scalable Vector Graphics (SVG) 1.1 Specification

SVGweb SVG Web is a JavaScript library for Web developers, targeted at Internet Explorer and dependent on the presence of an installed Adobe Flash plugin on the client machine. SVG Web provides partial support for SVG 1.1, SVG Animation (SMIL), Fonts, Video and Audio, DOM and style scripting.

SVG.org – Bringing the SVG Community Together

Planet SVG

Mozilla SVG Project

Google to slip SVG into Internet Explorer

#example:before { content: "3 < 5"; }

would result in a pseudo-element whose contents are the five characters (including spaces) < and not a broken HTML start tag. Similarly, this rule:

#example:before { content: "<"; }

results in a pseudo-element whose contents are the four characters < and not an HTML-escaped lessthan glyph. This tells us that the < and & characters are not treated specially by CSS string parsers, even though they are characters with special meaning in SGML-derived languages like HTML and XML.

Within CSS strings, the only character with any special meaning is the backslash (\). This character delimits the beginning of an escape sequence, a sequence of characters used to collectively represent a different character, in much the same way as the ampersand (&) does in HTML code.

Escape sequences are useful because they allow style sheet authors to represent characters that would normally be ignored or interpreted differently by traditional CSS parsing rules. The most obvious example of this is representing a literal backslash in a CSS string. At first, you might think that the following CSS rule would produce a backslash at the start of every paragraph, but you’d be mistaken.

p:before { content: "\"; }

When a CSS parser reads the declaration in this rule, it thinks that the backslash is the start of an escape sequence, and so it ignores it. Next, it encounters a straightened double quote and, since this character is not a legal component in an escape sequence, it recognizes it as the end of the string value and returns. The result is an empty string, sans backslash: "".

To get the backslash to appear, we therefore need to escape it, or “undo” its special meaning. This is simple enough. We merely prepend the backslash with another one, like this:

p:before { content: "\\"; }

This time when a CSS parser reads the declaration in the rule, it finds the first backslash, switches into its “escape sequence mode,” finds a literal backslash character as part of the string value it is parsing, and then finds the end-of-value straightened quotation mark. The result is what we were originally after, and the value that the CSS parser returns to the renderer is a single backslash: “\”. Note that CSS makes no distinction between single-quoted or double-quoted strings, so in either case two backslashes are needed in code to output one.

A similar situation exists if you wish to produce a literal double-quote within a double-quoted string. Instead of writing """; you would write "\""; to tell the CSS parser to treat the second quote as part of a value instead of the end-of-value delimiter. Alternatively, you could use single quotes as the string delimiter (content: '"';).

After the starting backslash, only hexadecimal digits (the numerals 0 through 9 and the English letters A through F) are allowed to appear within an escape sequence. In such escape sequences, these digits always reference Unicode code points regardless of the character set used in the style sheet itself. As a result, it’s possible to uniformly represent characters in a style sheet that are not possible to embed directly inside the style sheet itself.

Accented characters (like the “é” in résumé or café) is an example of one class of characters that would need to be escaped in a CSS string if the style sheet were encoded in plain ASCII instead of, say, UTF-8.

One useful application for this is to embed line breaks into generated content. The Unicode code point for the newline character is U+00000A. In a CSS string, this can be written as \00000A. In a way similar to the way a hex triplet for color values can be shortened, escape sequences can also be shortened by dropping any leading zeros from the code point, so another way to write a newline is \A. Here’s a CSS rule that separates the two words “Hello” and “world” with a newline, placing each on their own line.

#example:before { content: "Hello\Aworld."; }

Something to be careful of when using escape sequences in CSS strings is ending the escape sequence where you intend to. Observe what happens if our “Hello world” text changed to “Hello boy.”

#example:before { content: "Hello\Aboy."; }

Now, instead of a newline (code point \A), our escape sequence is a left-pointing double angle quotation mark, or (code point \AB). Our generated content now reads “Hello«oy.” This happens because the “B” in “boy” is interpreted as a hexadecimal digit. The escape sequence terminates at the next character, the “O,” because that letter isn’t also such a digit.

You can explicitly conclude an escape sequence in one of two ways. First, you can specify the sequence in full using all six hexadecimal digits (including leading zeros, if there are any). Second, you can append a space. The following two CSS rules are therefore equivalent:

#example:before { content: "Hello\00000Aboy."; }
#example:before { content: "Hello\A boy."; }

Knowing this, we can now split our earlier image caption example across two lines just where we want to. Pay close attention to the addition of the white-space: pre; declaration. Since we’re generating whitespace characters and in most situations all whitespace in HTML gets collapsed to a single space, the white-space declaration is needed to interpret the newline literally (as though all the generated content were inside a <pre> element).

img[title]:before {
    content: attr(title) "\AImage retrieved from"
    attr(src);
    white-space: pre;
    display: block;
}

Translations

Spanish (elwebmaster.com)

FBML embraces the Facebook Platform and enables your application to become part of Facebook itself. IFrames, on the other hand, enable your Web application to function inside Facebook without coding an interface that works only inside a single context (Facebook).

The reasons for using FBML include the following:

1. Has a consistent look and feel. When you use FBML, your application styles and controls automatically take on a Facebook look and feel, making it look identical to other Facebook apps. This consistency reduces the learning curve for your users and gives them instant familiarity and comfort with their surroundings.

2. Uses FBML elements. FBML is filled with several tags, controls, and “widgets” that enable you to develop a rich app interface in minimal time.

   Want to add a dashboard navigation menu? With FBML, you simply need to add an fb:dashboard tag. With IFrames, you need to code and style it all yourself.

3. May offer improved performance. Facebook claims that performance is improved when you use FBML. However, that claim probably depends on the specifics of an application and is not necessarily a blanket statement.

On the other hand, reasons you should consider using an IFrame approach include the following:

1. Enables existing apps to get up and running quicker. If you have an existing Web app, you usually need to do very little to integrate into Facebook using an IFrame approach. Your application can perform, more or less, as is within the confines of the IFrame. If you port to FBML, you are going to have to rework a lot of the presentation code.

2. Makes it easier to maintain a common code base. When you use FBML, you will probably need to branch your code base so that you can maintain a Facebook version, a stand-alone version, and perhaps a version that fits into another network, such as Bebo or OpenSocial. However, if you use an IFrame approach, you will not need to replace more generic HTML with Facebook-specific FBML.

   Having said that, if you are going to integrate into various social networking environments, you need to be realistic. Some platform-specific presentation code must be performed, regardless of whether you use FBML. Therefore, the IFrame approach is not necessarily a cure-all for portability.

3. Avoids JavaScript limitations. The Facebook Platform does provide scripting support, but it is more restrictive than a native HTML environment. As a result, with IFrames, you are not bound to the same restrictions for using JavaScript as you would be using FBML.

The decision you make will depend on your circumstances. If you can write suggest or advice, go ahead.

As you know, when you view a web page you’re asking your web browser to fetch a document. This document is just a text file that happens to be constructed in a special way. It’s constructed according to the syntax and grammar of a particular markup language so that all the content it contains is represented in a structured format.

It turns out that this structure has some remarkable similarities to human languages. Put simply, when we construct sentences in human languages we often use a grammatical structure that begins with a subject, followed by a verb, and that then ends with an object.

Markup languages also have rules of grammar. There are elements, each a building block or component of the larger whole. An element can have certain properties that further specify its details. These properties are often attributes, but they can also be the element’s own contents. Finally, an element has a certain position within the document relative to all the other elements, giving it a hierarchical context.

That markup languages contain rudimentary but powerful grammars in three major forms: which elements are being used, which attributes and attribute values those elements have, and the hierarchical context of elements in relation to one another. The ability to nest one element within another creates implicit relationships between different elements, but is structurally limiting. If elements are required to be nested to reference one another, neither the document itself nor the rest of the Web can be flexibly structured.

RDFa adds a fourth grammatical form by allowing one element, via an attribute and value pair, to reference any other element anywhere else on the Web by way of its unique web address or URI. Rather than referring to a document, now the reference actually refers to an object—a person, idea, place, event, book, or some other thing. The attribute used to do this is the about attribute. For instance, given a transcript of a speech we can now explicitly refer to and describe it without requiring that the two pieces of markup be structurally attached to one another.

<blockquote cite="http://example.com/myspeech" id="my-speech">
	<p>Once upon a time {...}</p>
</blockquote>

By giving this speech an explicit id attribute and unique value, we then use this value in a different element’s about attribute:

<p>
	The speech was written by
	<a about="#my-speech" property="dc:creator"
		href="http://www.example.com/~McFerrin/">
		Bobby McFerrin
	</a>
</p>

Here, we’ve described the speech as being created by Bobby McFerrin. RDFa gets its name from the fact that it borrows a concept from the W3C’s Resource Description Framework (RDF) called a triple, itself merely a way of describing two objects (two “things”) with a relationship to one another. In the prior example, the quoted speech is one object (the subject), Bobby McFerrin is the other (the predicate), and the fact that Bobby wrote the speech (that is, he is the creator) is the relationship. The only magic here is that the meaning of a “creator” has already been defined by a vocabulary we’re referring to as “dc” (short for Dublin Core).

In addition to the attributes already present in XHTML that RDFa makes use of such as rel and rev, RDFa adds the following attributes:

1. property: Specifies a URI (or CURIE, simply a more compact URI) that references a particular term in a given vocabulary; the marked-up content is then known to be that “thing.”

2. about: Optionally provides an explicit reference to a second object that the current element describes.

3. content: Optionally used with the property attribute to provide an explicit, machine-readable interpretation of the content of an element. For instance, an element such as <span property="dc:date" content="2009-11-30">Nov 30, 2009</span> reads to humans as “Nov 30, 2009″ but reads as 2009-11-30 to machines.

4. datatype: Optional CURIE that specifies the data type of text specified for use with the property attribute (for example, string or integer, useful for ensuring data integrity for machine processing).

5. typeof: Optional CURIE value that declares a new data item.

6. resource: A URI or CURIE, which expresses the resource of a relationship.

It’s this flexibility with the RDF triple and the extensible, highly specific capabilities that RDFa brings to markup languages that distinguishes it and makes it infinitely more scalable than the microformats initiative. Some might consider these two technologies in competition, but really they are not; both are simply differing approaches to solving the same challenge of having a more semantic and understandable markup framework on the Web. Some crossover exists, but both microformats and RDFa can coexist within the same markup.

Related Resources

Wikipedia – RDFa

A List Apart – Introduction to RDFa

A List Apart – Introduction to RDFa II

Unlike the development of traditional GUI systems, which were created behind the closed doors of academic institutions like Xerox’s PARC and later developed further by products such as Apple’s original Macintosh, the Web evolved in an open and, for lack of a better term, amateurish fashion. Although we can debate the benefits of one form of evolution over another, few argue that the Web isn’t a platform for incredible innovation, proving that either evolutionary method can push the development of such technologies in interesting and useful new directions.

As with all technologies, CSS is designed to solve a particular use case: separating the presentation of content from the structure of the content itself and reforming it to new presentations easily. However, CSS is not the only technology designed to solve this same use case. One notable competitor is XSL-FO, heavily used in the publishing industries for print layouts.

XSL-FO is a self-contained, unified, presentational markup language. This means that an XSL-FO document does not require external style sheets, scripts, or other apparatus to work as expected, and it is not considered semantically structured the way HTML or XHTML is. It is most often used to create print documents and is specifically tailored for paged media. A typical workflow involving XSL-FO would look something like this:

1. The XML document (such as DocBook, used in publishing contexts) is created.

2. The XML document is passed through an Extensible Style Sheet Transformation (XSLT) to convert the XML into XSL-FO.

3. The XSL-FO is passed through an “FO Processor”—software intended to convert the presentational document to another (potentially binary) format. The usual output is some press-ready format, such as PDF or PostScript.

XSL-FO contrasts with CSS in that it is a markup language, and all of the presentational data is contained within element attributes. It is not semantic at all, nor is it modular. It is a transition format between XML and some other format, and isn’t intended to be worked with by itself without some sort of programmatic capabilities on either end of the process (such as XSLT and software to convert to PDF).

The question is at what point in the advancement of CSS does XSL-FO become obsolete? With improvements in the specification around web fonts and print media, all the components for a full-featured print styling mechanism are coming into place. All that remains is a parser to convert your markup into a press-ready format such as PDF or PostScript. Printing your markup directly from a CSS style sheet instead of doing all that XSL-FO transformation means one less step in the process, and it leverages the opportunity to use external style sheets and skills that you already know to write manually, if that is needed or desired.

Another open question among web technologists concerns the CSS selection model. In CSS3, the ways in which elements can be targeted by CSS rules has been extracted into its own module called CSS3 Selectors. As you know, CSS’s notion of selectors originated in the first version of the specification, first published in 1996. However, in 1999 the W3C standardized a similar technology intended to be used to address parts of an XML document that provided much more granular control over which parts of the document were selected. This technology is called the XML Path Language, or XPath.

Today, the earliest versions of XPath still give XPath authors greater specificity over which parts of an XML document they wish to address than even the latest CSS3 Selectors draft. Many developers wonder, then, if such a precise language exists already, why is the CSS3 Selectors draft not incorporating more of it?

Some believe that XPath’s syntax is too complicated. A common selection such as “all <p> elements” is extremely intuitive using CSS (the selector is simply a p) and in XPath it is not (to achieve the same effect, the XPath expression you need to use is //p).

On the other hand, with new CSS constructions such as div#content — div:not(p:nth-of-type(3)a[href]), CSS Selectors can become frustratingly complex as well. What is an appropriate balance between simplicity and power? This is a debate that rages on to this day.

Other parts of CSS are taking the opposite route; rather than developing their own syntax and capabilities, they are taking on the behavior and terminology of other technologies. At the time of this writing, the proposed CSS3 modules for CSS Animations and Transitions was accepted to the standards track by the W3C. These modules incorporate SVG-like capabilities. More to the point, they are so similar that they can be thought of as a CSS interface to SVG graphical capability. Of course, CSS can be applied to SVG markup, so clearly there is some opportunity there for web authors to leverage their CSS skills in SVG elements.

In this case, the ubiquity of CSS is helping to promote and standardize the capabilities developed by other technologies. Since there are so many more knowledgeable CSS developers than there are SVG developers, it makes sense to utilize your existing familiarity to push the envelope of what is technically possible.

However, this path is not without its concerns. Although some would argue that creating more than one way to do something is a good thing, others argue that creating too many different ways to accomplish the same task fragments a standard and undermines its usefulness. Since many modern browsers support SVG today, the question becomes why not promote its use as is?

A further question that comes up is related to the technicality of the implementation itself. SVG is, a “thing” that can be referenced and re-purposed as a form of content. It is ultimately a language that describes building blocks of visual things. When you put the pieces together, you can create ever more complex graphical objects. On the other hand, CSS requires the use of a different thing; by itself, a style sheet doesn’t do anything.

These examples are the product of nothing more magical than developers like you playing around with the building blocks that we have today; such academic experimentation is the best thing you can do to expand your skills. When you run into a problem, ask yourself if you can use an existing building block—a CSS property or particular browser feature—to solve it, or if you need a new building block altogether. If you do need to create something new, since you’ve now imagined what it might be, tell other people what you need or, if you can, build it yourself.

If you do feel the need to include a Reset button, use it with caution, and at least be sure to use JavaScript to capture the reset event in order to ask, “Are you sure…?”, thus double-checking the visitor’s intention before he or she does something irreversible.

Submit and Reset buttons should be easy to see, and should be close to their related form controls. In any circumstance where the user has to choose between two or more action buttons, like Submit and Reset, be sure to position the safer or more positive action on the left, and the riskier or more negative action on the right. Also make sure default focus lands on the safer of the two actions, in case the visitor hits Enter without paying attention to the offered choices.

Any time there could be irreversible consequences for a visitor’s action, be sure to confirm that the action is what was actually intended. For example, never delete an account, submit an order, or change critical data in the database without first asking, “Are you sure you want to …” (fill in the blank, of course, with a description of the critical action).

After a form has been submitted to the server, visitors are reassured if the server sends back a response page that re-displays the entered information. That way, they can double-check that the information they intended to provide was not only entered properly but also received correctly by the web site.

We’ve all seen web pages that warn the visitor not to click a Submit button twice. Unfortunately, if the submission takes more than just a second or two, the visitor is left wondering if the click actually registered. At the same time, she’s afraid to click a second time—after all, she’s been warned of dire consequences if he clicks that second time. Just how long does the visitor wait in a case like this?

There are two user-friendly ways to avoid causing our visitors this kind of angst:

1. Immediately reassure visitors with feedback that the form is in the process of being submitted, often done with some type of small animation. This is a great way, under any circumstances, of reassuring visitors that something is indeed happening.

2. Use JavaScript to disable the Submit button after it’s clicked, thereby preventing a double submission.

   Add the following to the <form> tag:

   onsubmit="this.submitButtonName.disabled=true"

   Be aware that you might have to trace a hierarchy of path names to get to the button, if it’s embedded within other elements like a table, and that the page would need to be reloaded completely to re-enable the Submit button. Getting this to work might be a bit trickier than it appears if you’re unfamiliar with JavaScript and the Document Object Model (DOM).