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!

#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.

But sometimes —like here— that natural order doesn’t make sense, and we might need to violate it. We would want the visitor to progress vertically down the left column before going to the top of the right, as in EXAMPLE B.

We can dictate this non-default tab order by assigning a tabindex value for each affected form element, like this:

<input type="text" tabindex="n" name="homeAddress" id="homeAddress" />

When the page loads, the cursor is initially positioned on the control with the lowest tabindex value greater than zero. The cursor then progresses through the remaining controls in order by ascending tabindex. Elements lacking a tabindex or with a tabindex of zero come last in the tabbing order, in order of their location in the document’s HTML source code. (In Internet Explorer, a negative number removes the item from the tabbing order entirely.)

HTML for the “column first” tabbing order of EXAMPLE B, with the surrounding layout table, formatting, and irrelevant attributes removed for the sake of simplicity.

Non-Standard Tabbing Order, EXAMPLE B, HTML

<form>
    <p> Street Address
      <input type="text" tabindex="1" value="1" />
      Street Address
      <input type="text" tabindex="5" value="5" />
    </p>
    <p> City
      <input type="text" tabindex="2" value="2" />
      City
      <input type="text" tabindex="6" value="6" />
    </p>
    <p> State
      <input type="text" tabindex="3" value="3" />
      State
      <input type="text" tabindex="7" value="7" />
    </p>
    <p> Phone
      <input type="text" tabindex="4" value="4" />
      Phone
      <input type="text" tabindex="8" value="8" />
    </p>
  </form>

Even if you don’t need to specify a non-standard tabbing order, you can still set focus to a specific control where you want the visitor to start initial data entry. For instance, when a visitor opens Google, the cursor is automatically positioned in the search input area, ready and waiting for the visitor to type in a search phrase. Automatically setting focus to the first form control illustrates how some thoughtful coding can save the visitor an unnecessary keystroke or mouse movement.

To set the focus upon initial page load, add the following onLoad attribute to the <body> tag, substituting your own form and field names for formName and fieldName:

<body onLoad="document.formName.fieldName.focus();">

The data-gathering capabilities of FQL are identical to many of the API calls. However, before dismissing FQL as redundant, it is important to recognize that FQL does have some notable advantages over API access to Facebook, including the following:

1. FQL is more efficient. When you retrieve data using the API, you bring back all of the field data for a given record. However, with effective use of the select clause in an FQL statement, you can specify only those specific fields you want to have included in the result set. In fact, FQL does not even support selecting all records in a table with select * statements.

2. FQL can reduce the number of server requests for complex requests. When you are retrieving data, you often find yourself making an initial request, working with the results, and then making a second request for more specific information. For instance, suppose I need to get the name and status of all members attending an event. Using the API, I would call events.getMembers to get all members attending a specific event. Next, I would take that array of members and use users.getInfo to get the name and status for each of them. In contrast, with FQL, these two requests can be done inside a single complex query (using the in clause for a subquery).

3. FQL is Web-language neutral. The Facebook API has several versions, each of which is written for a particular programming language, such as PHP, Java, or Ruby on Rails. Therefore, if you work in multiple programming environments, your Facebook code must be specific to each one. In contrast, because FQL is programming-language independent, you can use the same FQL statements anywhere.

The API calls are actually wrappers around lower-level FQL calls. In the end, even if you prefer to spend most of your time working with the API, you may find specific occasions in which you want to take advantage of the efficiency of FQL.

Making An FQL Statement

To make an FQL query, use the fql.query API method. Its syntax in PHP looks like this:

$result_set = $facebook->api_client->fql_query("select name from user where uid=634164579");

The fql_query method sends the FQL query string to Facebook for processing. The results are returned to the PHP client as an array. Note that you can also return results in XML and JSON format as well for other clients. The array result set you’d get back in PHP would be:

(
	[0] => Array
	  (
	    [name] => Mert TOL
	   )
)

You can then work with the result set just like you would with an array obtained from a Facebook API call. And note that because Facebook manages the database connections for you, you do not need to open and close databases as part of your application.

Differences Between SQL and FQL

Although FQL is based on SQL syntax, the two are not the same. SQL is designed to be a flexible query language in a variety of contexts. FQL, on the other hand, is a query language for a specific, very targeted data set.

Therefore, FQL has some limitations compared to SQL that you need to be aware of, particularly if you already know SQL. These include the following:

1. select * is not allowed. You need to specify all the fields by name in which you want to include in the result set.

2. The from clause can only include a single table.

3. At least one field in the where clause must be classified as indexable.

4. join is not supported (though in subqueries are).

5. The groupby, order by, count, and limit keywords are not supported.

6. The between and like operators are not supported.

7. Because you have read-only access, you obviously cannot use keywords like update, delete, insert into, or create table.

Faster Websites

CSS makes HTML pages smaller in file size, thereby speeding page download times.

World Wide Web Consortium (W3C) Recommendation

CSS is one of the W3C’s core recommendations, so your CSS-styled site will comply with the current standards. Moreover, most HTML formatting tags are being deprecated by older browsers and aren’t even supported in XHTML code, so you have no good reason not to use CSS for most, if not all, of your content styling and positioning needs.

Easy To Edit

CSS is infinitely editable, giving you the flexibility of changing the look of your pages as often as you like without ever altering the content.

Easy To Control

CSS helps separate presentation (how the page looks) from content (what’s on the page) by moving all the page-styling instructions into a centralized location. That location can either be in-line with the code or internal in the head area of the Web page, or in an external CSS document to which all the pages on a site are linked, the latter being the most useful method for working with CSS. The benefit of having an entire site’s style information contained in a single external CSS file is that doing so allows for instant site-wide style updates.

Always Will Be Trend

CSS styles your content semantically, which means that it requires fewer styles than the old HTML formatting tags. For example, CSS allows designers to redefine the presentation of content contained inside particular tags, such as automatically adding a particular color and font face to any content marked up with H3 tags or applying the same background color and border attributes to any tables on the site.

No Need For Extra Codes

CSS can be used to style the look of text, images, and objects as well as to position objects on a Web page. This feature alone drastically reduces the amount of code required to display objects on a page. For instance, objects contained in div tags can be absolutely positioned on a page with CSS. Before, to place something in an exact spot on a page required code hacks involving the use of tables with empty table cells and spacer gifs. All that extra code goes away with CSS.

Other code hacks involve the unorthodox and creative use of HTML, CSS, JavaScript, and other code to manipulate objects on a Web page and/or work around existing limitations of the Web to achieve a desired visual effect.

Easy To Update

CSS is a more affordable solution for styling content because it takes less time to implement and update than the older styling techniques did. With the old way, even simple changes might require the hand-editing of all the individual pages on a site. With CSS, one change there can update a style across an entire Web site.

After you begin styling your content with external CSS, you’ll probably never want to go back to using the old tags for styling.

Related Resources

W3C Web Style Sheets

W3C Schools – CSS

HTML Dog – HTML and CSS Tutorials. And Stuff

A List Apart – CSS

CSS Dog

Recent CSS Bookmarks on Delicious

SitePoint – CSS Reference

The Web Standards Project – Learn

RSS feeds are defined as an XML document, using a standardized schema.

History Of RSS

Ramanathan V. Guha, an engineer for Netscape, created the first version of RSS, which then stood for RDF Site Summary, in 1999 as an extension for the My Netscape portal, an early attempt at creating a news and information Web site that users could personalize. Another developer named Dan Libby revised the RSS standard shortly thereafter, renaming it in the process as Rich Site Summary. In 2002, the meaning of the acronym was formally changed to Really Simple Syndication, and a version 2 was released after several years of open development. Another group continues to develop a slightly different standard based on the original RDF format, which is currently in version 1. That same year, the New York Times began offering an RSS feed of its headlines, and the technology took off from there.

Today, most major news sites have followed the New York Times’s lead and offer RSS feeds, as do almost all blogs, many e-commerce sites, and others.

Subscribing To And Reading RSS Feeds

In the early days of its adoption, several specialized RSS readers or aggregators were available. An RSS reader is merely an application that understands and can correctly parse a document written to the RSS schema. As the technology has become more widespread and popular, the ability to read RSS has been integrated into more and more applications, including most major browsers, many major e-mail clients, and other applications.

Microsoft Windows Vista, the latest incarnation of the Windows operating system, includes an RSS reader in its Sidebar, a set of gadgets always visible on the side of the user’s screen. Each of these programs gives users the ability to subscribe to the feed, allowing them to receive updates to the feed’s data automatically as it is made available.

Atom

Atom represents the third branch of RSS development and was developed in an attempt to reconcile several issues with the RSS 2 specification. This group is now a part of the Internet Engineering Task Force, one of the major Internet standards organizations. Atom is generally considered to be more extensible than the RSS formats,
but as the newer format, it is not as widely supported by aggregators.

As a developer, you simply need to decide which standard you will use. Most RSS readers have sidestepped the standards issue altogether and simply support all three, so the problems of having three competing versions are transparent to the end users and most developers. Note that Atom is not an acronym but is instead merely the name of the standard.

The RSS Syntax

Regardless of which RSS standard you choose to rely on, you will be creating an XML document. The only real differences between the three standards are in the actual elements used.

RSS 1 Syntax

RSS 1 documents use a root rdf element with, confusingly, an rdf namespace. The first child element will be channel, used to describe the basic information about your feed, including a title and a link to the home page from the site serving the feed. An optional image element for a feed logo follows, and then a series of item elements. Each item element will contain a title element for the specific item, a link element with the path to the item’s page, and a description element that provides a brief summary of the item. These item elements will make up the bulk of your feed.

RSS 2 Syntax

RSS 2 uses a root rss element. Its first child will, like RSS 1, be a channel element, but unlike the version 1 standard, the channel element on most feeds will actually contain the rest of the feed, almost becoming a second, nested root element, although it exists for this reason because advanced users can create separate channels within the same document. The channel element will contain a title element for the feed, a link element to the feed’s main page, a description or summary of the feed, a language to define the base language used in the feed, a pubDate and last BuildDate, which are used by aggregators to know if the feed has been updated, and then some general information such as docs, generator, managing Editor, and webMaster elements.

Following these elements, RSS 2, like version 1, has a series of item elements for the actual data. These item elements will contain a title, link, and description, along with a pubDate and guid element, the latter providing a unique identifier for the item.

Atom Syntax

Atom uses a very different syntax from the two RSS formats. The root element of an Atom document is feed. Its child elements are title, subtitle, link, updated, author, and id, which describe the feed as a whole, just as in RSS 1 and 2. The main body of the document will be a series of entry elements, which will contain title, link, id, updated, and summary elements.

The RSS Logo

When Mozilla first added RSS feeds to their Firefox browser, they developed a logo to represent feeds and released the logo under the GNU General Public License. The logo is a small orange square with white radio waves radiating from the bottom-left corner. In 2005, Microsoft announced that they were adopting the logo to represent RSS feeds in Internet Explorer and Outlook. Opera soon followed, making the little orange square the recognized standard for RSS. Web developer Matt Brett developed a Web site, Feed Icons at www.feedicons.com, to provide the logo in a variety of formats and colors and help facilitate its widespread use.

File Extensions

There is no agreed-upon file extension for RSS feeds. The most commonly used are .rdf, .rss, .atom, or .xml.