We are all used to reading web pages. Ordinary web pages are written in HTML, which is displayed by web browsers. RSS is similar to HTML, but is much simpler. An RSS page, known as an RSS feed, is a distilled and condensed version of the website, perhaps containing just links to new pages and their headlines, perhaps as much as the entire text of all the new articles. You don’t view RSS in an ordinary browser. Instead you view it via an RSS aggregator, a program or service that combines the RSS feeds you specify, and displays them in a way that you find convenient. Aggregators take many different forms. Some combine the RSS feeds into one personalized webpage. Others display RSS feeds like email, with a list of unread ‘messages’ sorted into different ‘mailboxes’. The RSS aggregator in recent versions of the Firefox web browser converts an RSS feed into a list of bookmarks.

Why should I use it?

Suppose you check the headlines on several news websites every morning, say BBC News, The Guardian, and MSNBC. You could visit each site and scan the home page for items of interest, and this is how you probably do it. For two or three sites this is not a problem – but what if you had to check a hundred sites every morning? And imagine some of those sites were updated every few minutes, and others were updated only every few weeks. It quickly becomes impossible to keep up. This is where RSS comes in. If each news site provides an RSS feed you can use your aggregator to view all the updates in one place. Finding new news is done automatically by your aggregator, and it takes you only a few seconds to see what has been updated.

How do I use it?

To view an RSS feed, you need an RSS aggregator. Many Windows users find SharpReader is suitable, but you can also Google for "rss reader" to find others. Having chosen your aggregator, you will then need to find some RSS feeds. Most web pages that have a corresponding RSS feed have a link to the feed somewhere on the page – usually it says “RSS Feed” or "XML Feed", or something like that. Subscribing to an RSS feed depends on the RSS aggregator you use. Normally you have to right click on the RSS link and select "Copy URL" or "Copy Shortcut" to copy the URL of the feed to your clipboard. Then you past this URL into your aggregator.

Why should I publish it?

Bottom line: an RSS feed makes it easier for people to find and use the information you publish on your website, which will make your site more successful. Even if you don’t have a news page on your site, and RSS feed of site content can still be useful. Have an online catalog? Publishing it as an RSS feed as well as a webpage can put your catalog closer to the fingertips of your clients, making it easier for them to order from you. Publish an email newsletter? Consider sending it out as an RSS feed too. Because of the increasing problem of spam, people are reluctant to give out their email address. Sending your newsletter as RSS means people can subscribe to it without giving you any personal details at all. This means more people will subscribe.

Of course, the vast majority of people who use the web don't know about, say CSS, client side XSLT, content negotiation, or even simple HTML. (And there's nothing wrong with that. I have no idea how a bus works, but that doesn't stop me getting one in to work every morning.) If you are an ordinary user, why should you be using Firefox for web browsing? Why make the switch from whatever you are currently using?

Take a look at this screenshot, taken on my faithful Windows 98 PC

I've got three websites open in one window here. Each of the websites is open in a different tab, or sub window. I can switch between the websites by clicking on the tabs, or by pressing CTRL + Page Up / CTRL + Page Down.

This looks like its just a gimmick, and to be honest until I started using it, I thought it was just a gimmick. Almost as soon as I started using it I fell in love with it. Being able to open links in new tabs makes it much easier to have several websites open at the same time. You don't end up with dozens on windows cluttering your desktop. If you don't think this is useful, ask yourself this: when was the last time a link opened in a new window and you were pleased?

Reason 2: Popup control

Links opening in new windows can be frustrating, but they are nothing compared to those annoying little popup windows that appear unrequested, especially popup windows that spawn other popup windows, taking over your screen in an effort to get you to buy something.

There are lots of popup blockers out there, and they are something you could practically expect to have in a modern browser. What is so good about Firefoxes popup blocker? Easy - it always lets you know when it has blocked something. As you can see from the following screenshot, when Firefox blocks a popup, it adds a clear message to the top of the page, complete with a clickable link that allows you to change your popup blocking settings - invaluable when you are looking at a site that has to use popups.

Reason 3: Secure connections are more obvious

Everybody knows about secure connections. Firefox has a neat way of alerting you to them. As well as showing you the little padlock at the bottom of the window, it highlights the address bar by giving it a yellow background. Making secure connections so clear makes life a little bit easier when buying things on the Internet.

Reason 4: Extensions

It's impossible to write software that does everything for everybody. However, it would be nice to have software that did everything you needed to do. Firefox doesn't try to be the browser that does everything. It does try to be easy to customise though. Don't like the default right-click menu? Try downloading RadialContext, which gives you a very nice circular right-click menu. Want to make your mouse more useful when surfing? Install Mouse Gestures, which let you control Firefox by moving the mouse.

Reason 5: Graceful failure

When I'm developing something, I want my browser to explode in my face if something is wrong. That way I catch mistakes before they end up on a live website. When I'm just surfing however, I don't really care about JavaScript errors. They are somebody else's problem. Firefox doesn't choke on broken JavaScript, it just ignores it. Given that JavaScript error boxes can be even more annoying than popup windows, this is a Good Thing. And what do I do when I'm developing in Firefox? Well, then I use the web developer toolbar that, among other things, politely explodes in my face when I make a mistake.

<p class="intro">Hello World! I am <em>Andrew</em></p>

There are two elements (a p-type and em-type), one attribute (class="intro"), and four tags (<p class="intro">, <em>, </em>, </p>).

In XML, the tags are the things delimited by `<' and `>', the attributes are the name-value pairs inside the opening tags, and the element is the whole thing - running from the start of the opening tag right the way through to the end of the closing tag.

A couple of days ago, a colleague asked my advice about appropriate alt text for an image - in this case a head and shoulders portrait accompanying an online bio on a web page. I suggested that he used the empty string as the alt text. He reacted with mock horror: "Blank alt text? You can't have that!"

"Do not specify irrelevant alternate text when including images intended to format a page, for instance, alt="red ball" would be inappropriate for an image that adds a red ball for decorating a heading or paragraph. In such cases, the alternate text should be the empty string ("")."

The best way to understand the alt attribute is to think of the img element as an element which has two, equally important, attributes: src, which gives the URI for the image itself, and alt, which provides a short text equivalent for the image. alt and src should describe the same thing, but in different ways. alt is not supplementary to src: it is equivalent to it. alt should be the empty string when everything the image says is said elsewhere in the document, or the image doesn't really say anything. Have a look at Guideline 1 and its checkpoints on the Web Content Accessibility Guidelines 1.0. Guideline 1.1 in the Web Content Accessibility Guidelines 2.0, which is at the draft stage at the time of writing. The empty string alt attribute covers the "Non-text content that does not provide information or functionality is marked such that it can be ignored by assistive technology" requirement.

How do you know whether or not everything the image says is said elsewhere? Imagine you are reading the webpage to someone over the phone. Would you feel you had to describe the image? That description would be an appropriate value for the alt attribute. In the case I mentioned at the start of this article, I wouldn't describe the head and shoulders portrait in any detail. In fact I'd be inclined to ignore it completely, because it didn't add anything to the bio except some visual impact. That's why I suggested the empty string for the alt attribute.

If you are going to enter the empty string for an alt attribute, why not just leave it out together? Think about the difference between the following two examples.

<img src="foo.png"/>

and

<img src="foo.png" alt=""/>

The first says "There is no text equivalent provided for this image". The second says "This image does not need a text equivalent in its current context".

title and longdesc

There are another two useful attributes for the img element: title and longdesc. The first is kind of like a brother to the alt attribute. According to the specs, title "offers advisory information about the element for which it is set" - in other words, for images it offers additional information about the image: additional, that is, to the information that alt and src both communicate.

Suppose you had a detailed image which provided essential information for the page. The alt attribute just takes a string of text. You can't structure the information in any way. This makes it impractical to use the alt attribute for detailed images. The specs provide an additional attribute - longdesc - for use in these circumstances. The value for the longdesc attribute should be the URI of a webpage that has a longer description of the image. The longdesc should be a supplement to the alt.

mysql>pager [pagername] 

command. See the MySQL commands page.

eg

mysql>pager less

makes mysql use less.

There are several current versions of HTML, including

• HTML 4.01 Strict
• HTML 4.01 Transitional
• HTML 4.01 Frameset
• XHTML 1.0 Strict
• XHTML 1.0 Transitional
• XHTML 1.0 Frameset

Which is the right one to use?

Unless you are doing something that requires XML, it is hard to make a case for using XHTML 1.0 over HTML 4.01. As it happens, I prefer the XHTML empty element syntax over the HTML way, but that is purely personal preference. It can even be argued that serving XHTML as text/html is harmful because that means it is processed as old-style HTML and you lose the benefits of XML's lack of error tolerance.

HTML allows various forms of SGML markup minimization, such as certain end tags being optional. Using these techniques can cause problems for some browsers. XHTML, being XML, doesn't have any markup minimization. This is something in XHTML's favour, but any HTML document on the web should be fully normalised anyway. More of that in a moment.

CSS works better - or at least more predictably - with XHTML 1.0 than HTML 4.01. CSS works best when there is a clear parse tree [1]. XHTML, being XML, doesn't have any of the fun markup minimization options that HTML does. This makes the parse tree much clearer to the author, and hence the CSS is easier to write. XHTML 1.0 Strict and HTML 4.01 Strict work better with CSS than their transitional counterparts because the transitional counterparts have all sorts of presentational guff in them. These presentational things interact strangely with CSS.

The real fun in CSS starts when you are applying CSS to invalid HTML. The browser has to guess what was meant, and hence the parse tree is unpredictable.

Just as with an HTML 4.01 document, you can put divs and spans more or less anywhere in the body of an XHTML document, and every element can be styled using classes, ids, or (shudder) the style attribute [2]. What you should always do with HTML is mark up the document according to its logical structure, regardless of how it looks. You should then style the page with CSS. If you get the structure right - which may require some divs and spans [3] - you may even be able to get away with a stylesheet that uses only contextual selectors. Which is so cool nitrogen condenses on it.

I've mentioned markup minimization and normalization. They deserve some further explanation. In SGML it is possible to specify that some start tags and some end tags are optional; they can be inferred unambiguously from the context. The classic example is:

<html>
<head><title></title>
<body>

There is no closing head tag, but the head element is closed, because the DTD makes it clear that the body element cannot be a child of the head. There are plenty of other similar things as well, including my personal favorite, the NET enabling start tag and the null end tag (or NET). Basically,

<foo/bar/

is exactly equivalent to

<foo>bar</foo>

An SGML document is normalized if all the markup minimization has been removed. Normalizing a document can be done completely automatically, using the sgmlnorm utility in the OpenSP suite.

Combining these, we can make a really short HTML 4.01 document:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"><title//<p//

There might be a small prize for the first person to describe what elements are present in that document and why.

The more extreme forms of minimization - like the above - confuse all mainstream browsers. The more normal markup minimization - such as the 'missing' </head> above - probably don't confuse modern browsers, but they should be avoided anyway because most browsers are very bad at coping with anything even slightly complex.

[1] Except in Netscape 4, where CSS works best when it is turned off.

[2] There is only one time when it is acceptable to use the style attribute in production code: when the building is on fire and you must finish the page before evacuating but you cani't open a second editor to add an id selector to the stylesheet and the flames are lapping round your keyboard. Even the you must remove the style attribute as soon as you reach a place of safety. The style attribute is more evil than the font element and the center element combined, and using it makes maintenance a nightmare, and don't get me started on debugging pages with style attributes and style sheets. In fact if you are the kind of person who uses the style attribute in production code it was probably me who set the building on fire when you were inside.

[3] The average number of spans per page should be much less than one. Whereas there is no way other than the div element to group block elements, grouping inline elements (or splitting them) can normally be accomplished by using a more appropriate element.