Lou Montulli was one of the first people to write a text-based browser, Lynx. The Lynx browser was a text-based browser for terminals and for computers that used DOS without Windows. Lou Montulli was later recruited to work with Netscape Communications Corp. but nonetheless remained partially loyal to the idea of developing HTML as an open standard, proving a real asset to the HTML working group and the HTML Editorial Board in years to come. Lou's enthusiasm for good, expensive wine and his knowledge of excellent restaurants in the Silicon Valley area were to make the standardization of HTML a much more pleasurable process.

Early 1993: Dave Raggett begins to write his own browser

While Eric Bina and the NCSA Mosaic gang were hard at it hacking through the night, Dave Raggett of Hewlett-Packard Labs in Bristol was working part-time on his Arena browser, on which he hoped to demonstrate all sorts of newly invented features for HTML.

April 1993: The Mosaic browser is released

In April 1993, version 1 of the Mosaic browser was released for Sun Microsystems Inc.'s workstation, a computer used in software development running the UNIX operating system. Mosaic extended the features specified by Tim Berners-Lee; for example, it added images, nested lists, and fill-out forms. Academics and software engineers later would argue that many of these extensions were very ad hoc and not properly designed.

Late 1993: Large companies underestimate the importance of the Web

Dave Raggett's work on the Arena browser was slow because he had to develop much of it single-handedly: no money was available to pay for a team of developers. This was because Hewlett-Packard, in common with many other large computer companies, was quite unconvinced that the Internet would be a success; indeed, the need for a global hypertext system simply passed them by. For many large corporations, the question of whether or not any money could be made from the Web was unclear from the outset.

There was also a misconception that the Internet was mostly for academics. In some companies, senior management was assured that the telephone companies would provide the technology for global communications of this sort, anyway. The result was that individuals working in research labs in the commercial sector were unable to devote much time to Web development. This was a bitter disappointment to some researchers, who gratefully would have committed nearly every waking moment toward shaping what they envisioned would be the communications system of the future.

Dave Raggett, realizing that there were not enough working hours left for him to succeed at what he felt was an immensely important task, continued writing his browser at home. There he would sit at a large computer that occupied a fair portion of the dining room table, sharing its slightly sticky surface with paper, crayons, Lego bricks, and bits of half-eaten cookies left by the children. Dave also used the browser to show text flow around images, forms, and other aspects of HTML at the First WWW Conference in Geneva in 1994. The Arena browser was later used for development work at CERN.

May 1994: NCSA assigns commercial rights for Mosaic browser to Spyglass, Inc.

In May 1994, Spyglass, Inc. signed a multi-million dollar licensing agreement with NCSA to distribute a commercially enhanced version of Mosaic. In August of that same year, the University of Illinois at Champaign-Urbana, the home of NCSA, assigned all future commercial rights for NCSA Mosaic to Spyglass.

May 1994: The first World Wide Web conference is held in Geneva, with HTML+ on show

Although Marc Andreessen and Jim Clark had commercial interests in mind, the rest of the World Wide Web community had quite a different attitude: they saw themselves as joint creators of a wonderful new technology, which certainly would benefit the world. They were jiggling with excitement. Even quiet and retiring academics became animated in the discussion, and many seemed evangelical about their newfound god of the Web.

At the first World Wide Web conference organized by CERN in May 1994, all was merry with 380 attendees - who mostly were from Europe but also included many from the United States. You might have thought that Marc Andreessen, Jim Clark, and Eric Bina surely would be there, but they were not. For the most part, participants were from the academic community, from institutions such as the World Meteorological Organization, the International Center for Theoretical Physics, the University of Iceland, and so on. Later conferences had much more of a commercial feel, but this one was for technology enthusiasts who instinctively knew that this was the start of something big.

At the World Wide Web conference in Geneva. Left to right: Joseph Hardin from NCSA, Robert Cailliau from CERN, Tim Berners-Lee from CERN, and Dan Connolly (of HTML 2 fame) then working for Hal software.

During the course of that week, awards were presented for notable achievements on the Web; these awards were given to Marc Andreessen, Lou Montulli, Eric Bina, Rob Hartill, and Kevin Hughes. Dan Connolly, who proceeded to define HTML 2, gave a slide presentation entitled Interoperability: Why Everyone Wins, which explained why it was important that the Web operated with a proper HTML specification. Strange to think that at least three of the people who received awards at the conference were later to fly in the face of Dan's idea that adopting a cross-company uniform standard for HTML was essential.

Dave Raggett had been working on some new HTML ideas, which he called HTML+. At the conference, it was agreed that the work on HTML+ should be carried forward to lead to the development of an HTML 3 standard. Dave Raggett, together with CERN, developed Arena further as a proof-of-concept browser for this work. Using Arena, Dave Raggett, Henrik Frystyk Nielsen, Håkon Lie, and others demonstrated text flow around a figure with captions, resizable tables, image backgrounds, math, and other features.

A panel discussion at the Geneva conference. Kevin Altis from Intel, Dave Raggett from HP Labs, Rick `Channing' Rodgers from the National Library of Medicine.

The conference ended with a glorious evening cruise on board a paddle steamer around Lake Geneva with Wolfgang and the Werewolves providing Jazz accompaniment.

HTML 4.01 was a large shake-up to the HTML standards that arrived in April 1998. The HTML language you have learned is constantly evolving to meet the needs of a growing Internet. Things get added, some things get taken away and still more elements are asked to fade out gracefully. These changes ensure that designers have the freedom and power available to create increasingly complex websites and can achieve this efficiently.

It only happens every few years, and the changes are made by the » World Wide Web Consortium (W3C), who is HTML’s governing body, as it were. They convene and design the specifications that we all work with when creating websites (CSS was designed by the W3C too). They look for weaknesses in HTML that are holding the web back and sort them out, which makes creating compelling websites easier for everybody.

The standard we were all working with before this was HTML 3.2. That was used for a while before the W3C decided to step it up another notch a few years ago. They released HTML 4. Sometime later, when some minor errors in the specification were uncovered, they fixed these and called the final specification HTML 4.01. As of now, HTML 4.01 is the accepted standard, and the majority of web users do have browsers that support it fully. Some of the more peripheral new elements have yet to gain full support in the latest round of browsers, but they’re on the way. Modern browsers will generally have no problem with anything in these specs.

If you have used any software you will have undoubtedly noticed how every few months it advances its number. I used to use Firefox 2 until they improved it and it became Firefox 2.1. Adding a decimal to the version number signifies a minor change to the original. When major changes are made to a software project, they will move up a whole number to version 3. This is the same way most dynamic things work. As you can see, the original HTML 3.0 spec was revised to version 3.2 before the big change to 4, and a minor change to 4.01.

There was some confusion when HTML 4 started being discussed, as at the time version 4 browsers like Internet Explorer 4 were making their appearance and people thought there was some connection. In reality, the two separate things had just reached those versions simultaneously, not because of each other. As you know, browser technology has advanced to version 7 stages and beyond by now, and HTML is still at level 4. So there’s no real connection; though, that said, it was in the version 4 browsers that HTML 4 started being incorporated properly. Glad that’s cleared up.

A few months after HTML 4.0 was released, its documentation was updated to correct some minor problems, and its version number was bumped up slightly. So the final final version of this standard is HTML 4.01.

DOCTYPEs Ahoy

Nowadays the Document Type Declaration (DTD) at the top of your document is very important if you want the browsers to render your page correctly. Without it, browsers might interpret your code more loosely, and you may have display errors. The HTML 4.01 DTDs are below. Take your pick.

Use the strict DTD if you’re using pure, structural code with no hacks:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

The transitional DOCTYPE, below, is the most commonly used, and still permits you to use certain old elements that we will eventually stop using altogether. It is probably the best choice until you’ve gotten to know HTML really well. Once you’re ready, you can start using the stricter DOCTYPE above.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Finally, for frameset pages, use the frameset DTD:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

Simply add this line of code to the very top of your HTML pages (before the opening tag), and you’re away. You will also need to specify the character encoding of your page. The best encoding to use is called Unicode and allows you to type almost any character you want (like punctuation, letters with accents, etc.) directly into your content. Add this element in between your page’s <head> and </head>:

<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">

Once you have added your DOCTYPE and encoding, run your page through the  HTML validator to see if you’re obeying the rules.

The New Elements In HTML 4

<abbr>

This is used to show an ABBReviated version of a word, and to offer the full version. When a reader leaves their mouse on the word, the full version pops up.
The code would be <abbr title="abbreviation">abbr.</abbr>

<acronym>

Similar to the one above, this is used for special abbreviations called acronyms (initialed abbreviations that can be spoken as a word themselves). It works the same way.
<acronym title="North Atlantic Treaty Organisation">NATO</acronym>

<bdo>

Most text is read from left to right, but some languages are the opposite, like Hebrew for example. This new tag allows the browser to display your page correctly if you use one of these languages, and allows you to pull off cool effects like this: cool effects. That’s typed in normally in the source code, but the tag changes its direction. RTL means ‘Right To Left’.
Code: <bdo dir="rtl">crazy text</bdo>

<button>

This is a simple way of adding form buttons to your pages. What’s more, you can now format the text and put images and other elements on the button.
<button><b>click</b> me</button>

<colgroup>

A table tag that allows you to affect the attributes of an entire column with one line of code. 

<del>

Wrapping this around some text creates a strike-through effect to signify DELeted text, so you can show readers what once existed without cutting it out altogether.
<del>waffle</del>

<fieldset>

This allows you to group buttons and things together, giving you a framed container to hold them in. It works together with the tag below.

<frame>

Strangely, this has only been made part of the official specifications now, despite it having been in use for years. It has been given new style attributes but overall it’s the same as the tag before. 

<frameset>

This tag is in the same boat as its friend above. Nothing’s really new.

<iframe>

Once a proprietary Internet Explorer tag, this was such a smart idea that it has been assimilated into HTML proper. 

<ins>

This stands for INSerted text. It works in conjunction with the tag, and the inserted text appears with an underline.
<del>waffle</del><ins>quality literature</ins>

<label>

This allows you to give form elements a label. Clicking the label functions like clicking the element (a radio button, for example) itself. This improves Forms Accessibility.
<label for="choice1">Choice 1</label>
<input type="radio" id="choice1">

<legend>

When using a fieldset element, this element must come first before any other content inside the fieldset. It gives the title of the group. 
<fieldset><legend>Contact Info</legend>
Email:<input type="text">
Address:<input type="text"></fieldset>

<noframes>

Another part of the frames umbrella is being formally added to HTML 4. 

<noscript>

The same as above, this is for people who can’t do JavaScript.

<object>

This is set to become the do-it-all tag for inserting multimedia into your page and is supposed to take over from img, ismap, applet, script and any others.
<object data="picture.gif" type="image/gif"></object>

<optgroup>

With this tag, you can group together many elements which are part of a select field, and give the groups titles.

<param>

This tag is used to set PARAMeters for ActiveX, Applets and objects. It existed before HTML 4.01 but now is official code.

<span>

This tag was brought in specifically to work with stylesheets in applying classes and ids. It does nothing on its own, but it is great for applying your styles to text.

<tbody>

A new table tag that allows you to give attributes to a block of cells with this one tag. 

<tfoot>

Allows you to add a footer to the part of your tables.

<thead>

This allows you to add a header to the part of a table. It comes before, while comes after in the code. 

<q>

If you’ve ever used the blockquote tag, you’ll know it’s a big tag. How many letters are in that, ten?! This is much more like it and is suitable for shorter quotations. Plus, it adds in the quotation marks for you. It will not add in the line breaks you get with blockquote.

The new Attributes

These new attributes are here to allow stylesheet implementation, with two more reflecting the new international concerns that the W3C has taken on board in this new draught. They can all be applied to any element.

class

This is how you give your page elements and text their es from your stylesheet. 

dir

This is the attribute that is used mostly with the new tag above. Your possible values are rtl (right-to-left) or the default ltr (left-to-right).

id

ids are just like classes but can be used with JavaScript and DHTML. 

lang

This attribute sets off a block of text as text typed in a foreign LANGuage, so that search engines and browsers know, and don’t just take it as badly spelled English. It will not translate anything for you, it’s just some behind-the-scenes help for things other than readers.

You can denote the text using the span tag, like

<span lang="fr">Bonjour!</span>.

If you’re going to use it, have a look at the common language codes.

title

This is one of my favorite things that came with HTML 4.01. It allows you to add in tooltip text, like the attribute; but now you can add it to absolutely anything. You can give table cells titles, add extra information to your links, and even hide jokes in your code that will only appear when a reader is on a specific word or sentence in your text.

Deprecated Elements

A deprecated element is on the way out, but one which has been given a few more months to live before its life fully ends. There are much better elements than these available now, so your usage of them should be downscaled as much as possible.

<applet>

Used to add Java applets. Use the new <object> element instead.

<basefont>

Used to affect text on the whole page. Use stylesheets instead.

<center>

Used to center elements. Use <div align="center"> or stylesheets.

<dir>

Used to make lists. Use s instead. Lists tutorial.

<font>

Ah, the classic font element. Still good for small things, but stylesheets have taken over. This is one element you should really try to avoid using.

<isindex>

Just use the input tag.

<menu>

Another type of list that is redundant thanks to the ul element.

<s>

Creates strike-through effects. Use the stylesheets again, or the new del element.

<strike>

Same as above, use style.

<u>

The underlining element, use stylesheets or ins instead.

Dead Elements

These are the elements that were so useless that they’re out on their asses for good. Never use these, you can’t guarantee the browsers will continue to support them. All three of these elements have been replaced by one new element — so you can see how they were useless.

<listing>, <plaintext>, and <xmp>.
Use pre instead. This creates PREformatted text (text which follows its layout in your code).

XHTML Explained

HTML began as a simple way to transfer data between any computer across the Internet; designed for scientists and researchers with no publishing experience. Over time the web became mainstream entertainment and new tags were brought in by the browser companies that didn't go along with this original aim — presentation became hugely important and structure and compatibility started to take a back seat. This meant that some pages were not accessible for people with the 'wrong' browser or computer setup.

Thankfully, the use of much of the extraneous presentational tags has receded in use in recent times, mainly due to the innovation of CSS code. Ideal HTML would be purely structural, with every element concerning how a page is displayed being controlled by a stylesheet. The  W3C (HTML's overseers, whom you should know something about by now) have spearheaded this desire with XHTML.

Further to all that, in recent times the Internet has begun to be accessed through new devices other than the classic computer and web browser arrangement. Things like PDAs, phones, and, er, fridges with Internet access are going to become common soon. There's an estimate going around that sometime soon, 75% of Internet viewing will be carried out on one of these many new platforms. The custom-made browsers used in these systems need to be small for cost-effectiveness. For every markup error that a browser has to deal with, more code has to be added to the program. XHTML is a very, very strict way of coding, which means the system makers don't have to accommodate for bad markup.

What is XHTML?

Before I describe XHTML, it is probably best to understand where it has come from. All web Markup languages are based on SGML, a horrendously complicated language that is not designed for humans to write. SGML is what is called a metalanguage; that is, a language that is used to define other languages. To make its power available to web developers, SGML was used to create XML (eXtensible Markup Language), a simplified version, and also a metalanguage.

XML is a powerful format — you create your own tags and attributes to suit the type of document you're writing. By using a set group of tags and attributes and following the rules of XML, you've created a new Markup language.

This is what has been done to create XHTML (eXtensible HyperText Markup Language) — which is why you'll see XHTML being called a subset of applications of XML. The pre-existing HTML 4.01 tags and attributes were used as the vocabulary of this new Markup language, with XML providing the rules of how they are put together.

So, using XHTML, you are really writing XML code, but restricting yourself to a predetermined set of elements. This gives you all the benefits of XML (see below) while avoiding the complications of true XML; bridging the gap for developers who might not fancy taking on something as tricky as full-on XML. As you're coming under the guise of XHTML, all of the tags available to you should be familiar. Writing XHTML requires that you follow the rules of conformant XML, such as correct syntax and structure. As XHTML looks so much like classic HTML, it faces no compatibility problems as long as some simple coding guidelines are followed.

If all of this sounds a bit heavy, don't worry. Transitioning to XHTML is quite a simple process, with only a few rules to remember.

Benefits of XHTML

The benefits of adopting XHTML now or migrating your existing site to the new standards are many. First of all, they ensure excellent forward compatibility for your creations. XHTML is the new set of standards that the web will be built on in the years to come, so future-proofing your work early will save you much trouble later on. Future browser versions might stop supporting deprecated elements from old HTML drafts, and so many old basic HTML sites may start displaying incorrectly and unpredictably.

Once you have used XHTML for a short time, it is no more difficult to use than HTML ever was, and in ways is easier since it is built on a more simplified set of standards. Writing code is a more streamlined experience, as gone are the days of browser hacks and display tricks. Editing your existing code is also a nicer experience as it is infinitely cleaner and more self-explanatory. Browsers can also interpret and display a clean XHTML page quicker than one with errors that the browser may have to handle.

A well-written XHTML page is more accessible than an old-style HTML page and is guaranteed to work in any standards-compliant browser (which the latest round have finally become) due to the insistence on rules and sticking to accepted W3C specifications. As mentioned above, XHTML allows greater access to configurations other than a computer and browser. This interoperability is another aspect of XHTML's greater accessibility.

XHTML Coding

The first thing you need to know about changing over to XHTML as the new standard is that there really isn't much new to learn. No new tags or attributes have been added into your repertoire, like HTML 4 (although a few have been deprecated); this is just a move towards good, valid, and efficient coding. XHTML documents stress logical structure and simplicity and use CSS for nearly all presentational concerns. It just means you have to change the way you write code. Even if you always wrote great code before, there're a few new practices you need to add.

What's even more quality about it though, is that a page written entirely in XHTML will still work fine in the current generation of browsers, so you shouldn't have any problems migrating your site across.

XML Declaration

An XML declaration at the very top of your document defines both the version of XML you're using as well as the character encoding. It is recommended but not required; as a few old browsers will choke on a page that begins this way. For this reason, I advise against using the correct line:

<?xml version="1.0" encoding="UTF-8"?>

and instead of using a meta tag in your document. If you're using  Unicode,

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

And if you're using the more common ISO-8859-1 encoding, use

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />

XHTML DTDs

Whether you use the XML declaration or not, every XHTML document must be defined as such by a line of code at the start of the page, and some attributes in the main tag, which tell the browser what language the text is is in. The opening line is the DTD (Document Type Declaration). This tells your browser and validators the nature of your page.

A DTD is a file your browser reads with the names and attributes of all of the possible tags that you can use in your markup defined in it. Newer browsers will usually have the latest specs written into their DTDs. The official XHTML Strict DTD is available for you to attempt to read. Declare it by putting this at the very top of your code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

That DTD is the one you use if you're committed to writing entirely correct XHTML code. Strict XHTML dispenses with a whole lot of presentational tags and attributes and is indeed very strict.

If you choose to use it, you're going to have to become close friends with the  W3C validator. You won't be permitted to use the font tag at all, nor will attributes like width and height be allowed in your tables. You won't be able to use the border attribute on images and will have to use the alt attribute on all images if you want to validate. You get the idea — almost all presentational attributes are restricted in favor of wider CSS utilization, so unless you know your stuff in this regard, it'd be best to use XHTML Transitional below.

If you're going to hover between HTML and XHTML use the next DTD, which is a bit looser, and if you're putting together a frameset page, use the last one.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

Most people will opt for XHTML Transitional, as changing straight to Strict can be a daunting prospect. If you feel you're able to work within Strict's constraints, by all means, go for it.

A correct DTD allows the browser to go into standards mode, which will render your page correctly, and similarly across browsers. Without a full DTD, your browser enters ‘compatibility’, or ‘quirks’ mode, behaving like a version 4 browser, including all of their associated quirks and inconsistencies. Also, these declarations are all case-sensitive, so don't change them in any way.

Finally, you need to define the XML Namespace your document uses. Don't stress about this — it's simply a definition of which set of tags you're going to be using, and concerns the modular properties of XHTML. It's set by adding an attribute to the tag. While we're at it, we specify the language of our pages too. Modify your tags to this:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

</html>

XHTML Coding Practices

And now the moment you've been waiting for — the different styles of coding used by an XHTML author compared to the old HTML methods. You shouldn't have any problems adopting these new techniques, so long as you work carefully. It should be noted, even if it is an obvious point, that you really must hand code to be able to write valid XHTML. No current visual editor comes close to the compliance required.

source tip: Even though your code is changing, your filenames won't have to — you end your files with .html as always.

1. Tags and attributes have to be lowercase
Whereas before it used to come down to preference whether you used <B> or <b>, now all of your tags and attributes have to be in lowercase. This is because XML is case-sensitive — i.e. a tag in capitals is a different tag to one in small letters.

2. All tags must be closed
Now all of those once-optional </p> and </li> tags are essential for your XHTML documents to validate. Even empty elements like img, hr, and br must now be closed. You can use a standard forward-slashed end tag, or just add in a forward slash to the end of the tag.

<br /> or <br></br>

It's recommended that you use the former method here, and leave a space before the slash so older browsers aren't confused. They'll just ignore the trailing slash as an unrecognized attribute.

3. Documents must be well-formed
'Well-formedness' is a dream that you were meant to try and make real from the start, but many coders write badly-syntax code. You have to open and close tags correctly in XHTML and nest them properly.

Bad: <p>My coding is <b>bad</p></b>
Good: <p>But my coding is <b>good</b></p>

Remember the simple rule you should have been taught at the very start: The first tag you open is the last tag you close.

4. Attribute values must be quoted
Back in HTML, you could leave out the quotes on a number value, like HEIGHT=3, but now all values have to have quotation marks around them, so that would become height="3".

5. Attribute Minimisation
Some HTML tags had one-word attributes, like HR's NOSHADE. You can't use these anymore, and must add the attribute in as its own value, like so:

<hr noshade="noshade" />

Any browser compatible with HTML 4.01 shouldn't have a problem with markup like this.

6. Internal Links
Internal links in HTML were made using a combination of the <a> tag and the attribute. In XHTML, to go along with XML, you use the attribute to make these links instead of the attribute. For a while, you should probably include both so that your links still work on older browsers, but this will be the method used in the future. The attribute has been deprecated.

<a href="#section">link</a>
<p id="section" name="section"></p>

Since all tags can take the attribute, you can now make links to any element on your page. Most helpful if you add the link to a heading or specific paragraph.

7. Alternative text in images
While it has always been good practice to add the attribute to your images, now you must add some alternate text to every image on your page. If your image is purely decorative you can give it a null alt attribute with space:

<img src="header.gif" alt=" " />

You could also try adding the attribute to as many elements as possible. It's a good accessibility aid, especially on links.

8. Ampersands in URLs
Ampersand characters are frequently used in page addresses to carry variables, like in PHP. When coding these addresses into your XHTML, you must escape them using the entity value &. They'll be displayed as ampersand characters (&) on screen, of course.

<a href="reviews.php?page=27&style=blue">link</a>
becomes
<a href="reviews.php?page=27&amp;style=blue">link</a>

9. Content must be wrapped in a block-level element
In XHTML Strict, when you add text to your page, you can’t add it directly into the body element. All text needs to be within a suitable containing block-level element, such as a p, a ul or a div.

HTML5

After HTML 4.01 and XHTML 1.0, the guys who were in control of HTML’s direction got sidetracked working on a new proposal for XHTML 2. At the same time, clever web developers were innovating constantly, hacking new functionality into websites and browsers. The path that XHTML 2 was taking started to look both boring and unrealistic, and it became pretty clear that a new approach was needed.

It was around this time that a bunch of pragmatic web technology fans, browser programmers, and specification writers started building something of their own, outside of the usual W3C procedures. They called themselves the Web Hypertext Application Technology Working Group (WHATWG) and developed a new spec. After some soul-searching, the W3C decided that HTML was still the future of the web. XHTML 2 was discontinued and HTML5 became the new specification that everyone’s effort should be poured into.

HTML5 is designed for the web, both now and in the future. This is the specification that we will be working with for the next decade at least, so the process of its development is relatively slow and considered. Many parts will be familiar, but there’s also plenty of new elements, attributes, and abilities to get excited about. You can check the latest version of the spec if you want all the detail. A full tutorial on HTML Source about the changes in HTML5 is forthcoming.