HTML & CSS: Versions of HTML and CSS
In this tutorial we're going to be talking about the different versions of HTML and CSS, as well as doctypes.
Up until this point we've talked a little bit about the different versions of HTML and we've glossed over some differences between them. We sort of decided that there are two main different versions of HTML - "normal" HTML, and XHTML (and we've also talked about HTML5, which at the time of writing this is the latest version of "normal" HTML). XHTML stands for eXtensible HyperText Markup Language, and is basically just a strict version of HTML which utilises more aspects of XML (a strict markup language which has been around for some time now). The big deal about this is that a browser can interpret XHTML using an XML-reader (technically called a parser) instead of using a custom HTML parser. The general idea was to make a more "flexible" version of HTML with the benefits of XML, and hence XHTML is generally considered a very neat version. This is somewhat in contrast to the more forgiving "normal" HTML, which lets you "get away with" certain things, including the indication of empty tags by using a slash before the ending bracket.
The elements in HTML 4.01 and XHTML 1.0 (two versions created around the same time) are essentially the same, but what really differs is the way things need to be written in order to be valid. There are many differences like this between HTML 4 and XHTML versions, for example XHTML element names must be written in lowercase, however we are not going to go over too many differences in this tutorial - if you're interested there are many articles and specifications online that can help you learn the different features of the different versions. Both specifications have their faults, and the bottom line between choosing one or the other for a project is down to personal choice. If you prefer the syntax of one over the other, for example I personally like the restrictive rules that XHTML offers, then choose one over the other. Before you make a choice on which version you might use for a project though, consider that there is another main version to keep in mind, HTML 5, which we'll talk about in a minute, and that there are also three subsets of both XHTML and HTML 4.
As I alluded to in the previous paragraph, HTML 4 and XHTML 1 each have three different subsets (sub-versions) - transitional, strict, and frameset. Transitional is just as it sounds, it's basically for the transition between HTML 3.2 (the basic oldest version of HTML) and HTML 4+ - the main point of it is to allow presentational elements and attributes that were introduced in HTML 3.2, in HTML 4. So if your document is using HTML 4 Transitional (which remember would be shown in the doctype at the top of the HTML document - we'll go over these in a minute), you can use things like the center
element (a horrible, messy element which is basically just the same as text-align: center;
) and the bgcolor
attribute (a horrible, messy attribute for setting background colour). As you can tell, I'm not too keen on presentational elements and attributes as I believe having the styling and structure separated via HTML and CSS documents is a very good thing, but if you really needed to use those elements you could use HTML 4 Transitional. The second version is strict, this is much better (in my eyes), and strictly sticks to the HTML 4 specification, so you can't use HTML 3.2 things that have been deprecated (removed from the specification) - no presentational elements or attributes for you (Thank the lord!). If you're using the strict type, it's expected that you should be using CSS for styling. The third type is frameset - this is identical to transitional, however also allows for the use of things called frames (which I'm not going to talk much about, but should generally be avoided). These subsets are basically the same in XHTML (with transitional being extremely lax and allowing for old elements, strict meaning you have to strictly stick to the specification, and frameset being transitional with frame allowances).
With all these out of the way (We'll learn the actual doctypes for each of them in a minute), we can finally learn about the version favoured in the eyes of many web developers (including myself) - HTML 5. HTML 5 is, at the time of writing, the future of HTML - it came around after W3C (the people that do all the specifications) decided to stop work on XHTML 2 and instead push forward with the "normal" HTML path, but with an all new version which would be much better. At the time of writing, HTML 5 is a really hot buzzword - many people are switching their XHTML websites over the HTML 5, and us web developers are getting very excited over the new specifications including a bunch of new attributes and elements (very exciting stuff!). I'm not going to talk too much about why HTML 5 is awesome or the new elements it introduces, but basically, if you have the choice of what version of HTML to use, in my opinion, use HTML 5. It's got a childishly simple doctype, it has many new elements which allow for more semantic markup (markup with meaning), and the only real downside to using HTML5 at this point (note that it's often written without the space between "HTML" and "5") is that some older browsers don't fully support it. Browsers like Internet Explorer, typically hated by developers (at least the older versions), which don't automatically update, simply don't have support for some of the new gadgets and gizmos that HTML5 has to offer. The solution to this, if you wish to maintain support for these older browsers (sometimes dropping support for some versions of IE is the right decision), is to use what is called a polyfill.
There are many HTML 5 polyfills available at current which use JavaScript to make certain features work in older browsers, notable ones include html5shiv, which uses JavaScript to make older versions of IE recognize and style HTML5 elements, and HTML5-progress-polyfill, which allows for usage of the progress
element in older browsers. This series of tutorials was never meant to introduce you to all the available elements and how to use them, but is instead more about learning key techniques in both HTML and CSS, and being able to create good websites through this. For this reason, I'm not going to be covering any advanced HTML5 elements in these tutorials (and probably won't mention every single element in the HTML 4 specification either), however will leave it to you to research the elements you think may be of use to you, and you should have a very good idea of how to use and style these from the knowledge provided by these tutorials.
So now you know about all the different versions of HTML, it's up to you to make an educated decision (likely on a project-by-project basis) about what version you want to use. Once you've decided this, you can use the appropriate doctype at the top of your document (even before the opening html
tag) - the list of doctypes are below (some of them are quite complex).
HTML 4 Doctypes
- Strict:
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
- Transitional:
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
- Frameset:
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
XHTML Doctypes
- Strict:
1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
- Transitional:
1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- Frameset:
1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
HTML5 Doctype
- The HTML 5 doctype, isn't it beautiful?
1
<!DOCTYPE html>
So HTML versions done and dusted, hopefully you should know which version you want to use -- let's talk a little bit about CSS versions...
Unlike HTML versions which need to be specified to the browser in order to read the file correctly, CSS syntax (the way CSS is written) has remained exactly the same throughout all the versions. This means if you write in CSS1, it should also be completely valid CSS2 and CSS3. The only real differences between the versions are different properties and selectors. In a similar sense to HTML5, CSS3 is a hot buzzword at the time of writing this as it introduces many new properties which make things that were previously impossible, easy. You should be safe using CSS2 for a massive proportion of web browsers (those who wouldn't support it probably aren't even supporting any styling at all - you really are safe using CSS2), however downsides with support are certainly present with CSS3. For this reason people usually go one of two routes. They either write completely in CSS2 so their website will look exactly the same in virtually all web browsers, or they do what I do, which is write whatever CSS is needed to accomplish the job (including nice CSS3 properties which can make things look nice), but then also make sure that browsers that don't support CSS3 display the website fine. A usual use case is using CSS3 for special properties such as box-shadow
(which does what it sounds like it does) and border-radius
(which creates rounded corners) - these properties add a styling flare to the website, however if a browser doesn't support CSS3, it's certainly not the end of the world if a few shadows and rounded corners are missing.
While we're talking about CSS3 properties - we should end this tutorial on a note about vendor prefixes. The specifications of HTML5 and CSS3 are still being written, this means that some properties only exist in theory while it's being debated whether they should be in the specification. This is all well and good (and makes complete sense), however because browsers want to be ahead of the game, some try to implement these properties in an experimental fashion before the final release of the specification for that property. This makes sense, after all - why wouldn't browsers want to get ahead of the game? The issue is that because the implementation is completely experimental, the browsers implement it with their own variation of the property -- this prevents the havoc that might be caused by the behaviour of the experimental implementation where the strict specification behaviour was expected by the web developer. Browsers usually do this by prefixing the properties with what is called their vendor prefix. Webkit based browsers (Safari and Chrome) use the -webkit-
prefix, Gecko based browsers (Firefox) use the -moz-
prefix, and there are a whole bunch of other vendor prefixes for other browsers too (Opera, Internet Explorer, etc.).
The idea of these prefixes makes complete sense, however it does mean that if you want the CSS3 properties you put in your stylings to be supported by as many browsers as possible (including perhaps older browsers which only have the experimental implementation), you need to write multiple lines of CSS which are essentially doing the same thing. You might need five lines of code, for example, simply to make a box-shadow
work in the various browsers your website is supporting. This can make your code messy, and if you don't include the property without the vendor prefix, which may not be understood by any browser at the time of publishing, then browsers in the future that phase out the experimental implementation and only understand the proper CSS3 property will not follow your vendor prefixed property. A number of issues and pieces of hot drama have sprung up around vendor prefixes, including the plugin "-prefix-free" by Lea Verou which uses JavaScript to automatically vendor prefix properties, although leaves your website dependent on JavaScript (which is generally considered a bad thing because some users will likely have JavaScript disabled), and the idea that some browsers might implement -webkit-
prefixed properties despite them not being webkit browsers (which would create a huge mess).
Overall, looking at the different versions of HTML and CSS is important, and the different specifications are constantly growing while hot drama continues to arise around different matters. My advice: get involved! You have a chance to shape the future of the web, do it!