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.

Words: read and interpreted. Type: seen, read, and interpreted.

Designer as Typographer as Interpreter

The designer is not just the obedient deliverer of a message but,

1. an interpreter where interpretation is central to the idea of communication.

2. a visual communicator

   1. to make information more attractive, more noticed, more read

   2. to enhance the tone of a message

   3. to make the message more legible, more readable

   4. to improve comprehension, retention

   5. to achieve emphasis of key points in a message

3. a problem solver

   1. employing the appropriate typeface and weaving it into a design well suited for the message, media, and audience

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.

Some of the “nondesigned” typography will have been made with commercial or political intent, some will be serendipitous, or simply caused by neglect. In older districts, the pedestrian can often find ad hoc remnants of businesses from previous generations, providing clues of past political and/or industrial upheaval. Most urban communication will have been the result of optimism: “a good idea,” something new, exciting, and worth shouting about.

In all towns and cities a range of wayfinding signs, locational identity signs, and situational, ad hoc messages can be seen. Some of the signs are rule-governed brandings: corporate logo, name, and associated livery. Other signs are bespoke, one-off signs on fascias and vans, hand-chalked menus, and sale offers.

Effective and attractive handwritten example.

The amateurs’ hand-drawn notice or sign attracts attention because we seem to be naturally drawn to anything different or unexpected. However, signs must attract for the right reason and certainly, in the urban commercial environment, the public are highly attuned to the way messages are relayed to them. A hurriedly drawn (informal) price sign on a market stall will not be perceived to represent a lack of concern by the stallholder for the quality of his fresh fruit, quite the opposite, because immediacy and impermanence are both qualities appropriately associated with fresh food. However, if a permanent (formal) sign, displaying the stallholder’s name for example, is hurriedly (and ineptly) done, its informality will be perceived to be inappropriate. Typography, when bad, is easy to recognize, but difficult to get right.

The long-established department store generally offers a more formal persona (even if it prides itself on friendly service). A less formal method of conveying information can still be initiated for short-term events such as a sale, but this material must be disposed of the moment the event is over, so as to enable the formal presence of the business to be restored.

People understand the effort involved (if not the process) in the production of notices and signs. Something that requires time to plan and then paint or carve, print or build, will generally be considered more formal because it has gone through a process of design, making, and/or manufacture, and is already clearly intended to be in place for a considerable time. The materials chosen are very important in reflecting this. Letterforms bought “off the shelf” and fixed DIY style, either by authoritative organizations or by the individual business entrepreneur, are notorious disasters: M and W mixed up, S upside down, but more commonly, poor spacing.

In the context of hand-lettered signs, newsbills are an anomaly. Until very recently, newsbills were a hand-drawn form of public advertisement for daily newspapers sold on the city streets. It is remarkable that hand-drawn newsbills should have remained in existence for so long, especially because their function was to advertise the products of a highly sophisticated, technology driven, newspaper media industry.

The point, of course, is that the newsbill offers urgent and topical information. The earliest specimens, dating from the beginning of the nineteenth century, contained more than 20 lines of closely printed type in various styles and sizes. Over the years, however, the tendency developed toward shorter, ever more dramatic handwritten headlines that were attention grabbing and readable at a glance. Contemporary newsbills, although printed, have retained the underline and are, in this way, reminiscent of the earlier, handdrawn newsbills.

The need for semi-permanent information, often hurriedly improvised in urban streets, is generally considered to be visual clutter. In an emergency, we are reassured to see order reestablished, usually in the form of standard temporary signs, access inhibited by tape, vehicles with flashing roof lights, and uniformed personnel. Coordination in all these elements is important in providing a sense of order and authority. Disorder is stressful because change to our daily routine forces us to think about activities that we can normally take for granted. It makes us think about what we are doing! Order allows us to form our lives into patterns, to make assumptions, to plan ahead, and use our time efficiently. When a book is opened, the reader is looking for patterns for the very same reasons.

Traffic diversion signs are unpopular because they inevitably represent a disruption or breakdown of a planned journey. However, if such signs are coordinated in their appearance and placement, then they will be perceived to represent a coordinated response to a scheduled event. The driver will assume that this is a planned reroute, rather than an ad hoc, hurried, and perhaps illconceived emergency-induced event. Ad hoc signage is both celebrated and despised, depending on the viewers’ circumstances.

An example of permanent typography.

“Typographic detritus or chance art” is the way that improvised urban information… The interference by people making alternative, spontaneous additions or alterations (disregarding the best intentions of the designer) is both inevitable and a necessary aspect of urban life. Such ephemera may sometimes be ugly, but its purpose is generally to provide a valid source of information, even if it is only for a select few. Small, entirely insignificant information, the detritus of urban life, is just as valuable—more valuable some would argue—to social historians than the results of grand-scale city planning.

It is a very good idea to consider how a text will be perceived (and read) in 10, 20, or 100 years’ time. “Decay is the most powerful medium for the improvement of cities… Decay, not architects, adds the last touches, blackens and peels the stone, applies lichens and cracks, softens the edges, elaborates elaboration, and the hand of man works even better than the forces of nature…” Similarly, a scuffed, well-thumbed book with creased page corners is the consequence of a well-used and truly useful document.

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 0000A. 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: "HelloAworld."; }

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: "HelloAboy."; }

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: "Hello0000Aboy."; }
#example:before { content: "HelloA 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.

Rhetoric is concerned with those factors that attempt to ensure a predetermined interpretation of factual information. Language is regularly manipulated to achieve such a function and typography can, indeed should, reflect and reinforce the arguments within a given text. For this reason, there is a commonly held prejudice that pejoratively associates rhetoric specifically with deceit and seduction. However, if one believes that language is invariably about debate, upholding a point of view, or simply explaining the facts as one understands them, rhetoric must also be concerned with imagination, with form-giving, and with appropriate use of language to facilitate all forms of social interaction.

In fact, it is difficult to imagine any information that does not involve some degree of interpretation. Our contemporary distinction in typography between information and persuasion reflects historic concerns about the merits of plain and ornamental styles of presentation. Because of this, many typographers believe that information can be presented without ever referring to modes of persuasion. Yet all communication, no matter how prosaic, has interpretable, stylistic qualities that go beyond the stated content of the message, and therefore become ornamental.

Even the choice of typeface, for instance, a decision that is unavoidable, must add something to the reader’s perception and therefore could be described as ornamental. Consequently, the issue that typographers must face relates not to persuasion or the lack of it, but rather to the intentions behind it. So, typographers must question the purpose, the function of the given text, before any typographic decision is made.

Legible typographic design comprises a codirectional concatenation governed by a reader profile that relates to style or visible rhetoric. The profile results from analysis of comprehension levels on age, education, and culture. The term kinetography defines the combined verbal/visible, rhetorical function of typography in technological environments.

The typographer must take three distinct actions to achieve legibility:

1. Analyze and comprehend author’s and editor’s intent.

2. Translate the intention through symbolic reference into typographic signs.

3. Arrange the typographic signs into recognizable and comprehensive gestalts.

Typographic legibility contains the properties of text/images that symbolically represent readability. It forms an integral part of the design algorithms of visible language. Thus, legibility results from an interpretation of readability: a property of text that results from developing verbal language in an easily understandable rhetorical style (verbal language). It requires the expert consideration of a set of infinitely adjustable, concatenated, multivariate, overlapping, geometric modules and complexes that constitute typographic style (visible language).

Typographic designers must possess knowledge of the human elements that relate to the communication process plus the skills that enable them to use electronic tools. The knowledge and ability to interpret readability into legibility derive from a comprehensive education and training in typography and type design. It does not derive as a by-product from using electronic tools.

Almost all human reasoning about facts, decisions, opinions, beliefs, and values is no longer considered to be based on the authority of absolute Reason, but instead, is seen to be intertwined with emotional elements, historical evaluations, and pragmatic motivations. In this sense, the new rhetoric considers the persuasive discourse not as a subtle, fraudulent procedure, but as a technique of ‘reasonable’ human interaction, controlled by doubt and explicitly subject to extra logical conditions.

Umberto Eco — Italian Scholar and Semiotician

So, designing the appearance of any typographic layout involves a degree of rhetoric. The effectiveness of typography depends on the use of marks, symbols, or patterns that are familiar and pertinent for a given audience. A functioning message is one that succeeds in connecting with the habits and expectations of its audience. A conscious rhetorical approach to typography would be one which accedes that all design has social, moral, and political dimensions, that there is no sphere of “pure” information, and accepts the challenge to design typography that is functionally and conceptually appropriate for its purpose.

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