Advice - HTML

So you want to learn how to write websites, and need some easy to follow advice or some guidance though the minefield of online advice that already exists? This section of my website isn't intended to reproduce what already exists, since that'd be a complete waste of everybody's time, but it ought to provide a framework for understanding some of the information that's available.

HTML (that's Hyper Text Markup Language) is the language used to write webpages (yes you can add non-HTML to HTML to create particular effects, but that's not important now). HTML is a SGML (Standard General Markup Language).

Perhaps the one thing I wish someone had pointed out to me when I was first learning HTML is the need for a decent text editor. A text editor is a programme that allows you to enter and edit text. It doesn't format it prettily - that's what desk top publishing programmes (like Word) do. There are many text editors to choose from; I've chosen Vim (emacs is another popular one) and though they all do slightly different things they make life much easier eg. by providing syntax highlighting (ie. your code is displayed in a different colour to your content) which helps by making it easier to spot errors in the code.

Once you have a text editor you feel comfortable with, you can move on to reading through a couple of HTML tutorials - I used Getting started with HTML, but here the important thing is to find one which you like. You should now be in a position to start trying out some of the code you've learnt.

A couple of tutorials will give you enough of a grasp of the basics to be going along with - the rest you can pick up by dipping into the published grammars (grammar is a technical term for the documents that list all of the elements and attributes (in as non-technical language as I can get, 'element' is something that forms part of the structure of the document eg. <p> and 'attribute' is something that can be applied to an element eg 'border="1"') of SGML languages). I found this XML (Extensible Markup Language) FAQ very helpful in understanding how SGML, HTML + XML all fit together; along with an explanation of 'parsing' - a term I'd heard but not understood for months.). The HTML grammars can be found on the WC3 site. While they are most useful for dipping into when you've tried to validate code and discovered errors in it, you will also need to use them to select the Doctype (the very first thing in an HTML document) and the right code for the character set you're using (again something that comes fairly early on in an HTML document).

Ensuring your code validates to a published grammar is common courtesy (even if it's one routinely ignored by many); it's just like making sure you capitalise the first letter in a sentence and end it with a full stop. If your HTML is not valid it may well not work as you intend in browsers (programmes used to look at webpages, like Internet Explorer, Lynx and Mozilla). As an author you don't know what browsers (also called User Agents in the W3 documentation) your audience will be using, so it makes sense to ensure that your code is valid and should therefore work in all browsers.

Write yourself a couple of pages and check them against one of the validators (see my links page for a link) - don't expect your code to be perfect first time round. This is a learning process and it won't always be painless. In the beginning you are likely to find the validator's explanation of errors somewhat confusing - it is at this point that it can be really helpful to find people you can ask for some assistance (again go to my links page for details of an appropriate newsgroup, or email me and I'll do my best to help.

At this stage it's helpful to know how to 'escape' your HTML; this means writing what appears to be the code without your browser interpreting it as code, and it's helpful when you want to use any of the characters that are used in HTML for some other purpose or if you're asking someone for help with it. See the WC3's Character Entity Reference for full details.

Now that you've got the basics down, it's time to turn to two other important concepts - the first is Cascading Style Sheets. These are the modern way to control layout/presentation in websites and are highly recommended. They're not necessarily the easiest of things to learn, but the effort is more than worthwhile, since they are so much more versatile than tables - with CSS you can provide suggestions for appropriate presentation for a whole variety of media - palm devices, aural browsers and braille readers to name a few. They also allow you to have consistent and easily alterable presentation between your pages. Information on CSS can be found in the same place as information on HTML, along with another handy validator. Again, find a tutorial you like and work through it before trying to create your own CSS. Do remember that CSS 2 is not fully supported by Internet Explorer 6 - which isn't a reason for not using it, just a reason for making sure your pages display acceptably in it.

The other important concept is that of accessibility - as I've just indicated, not everyone views webpages in graphical browsers; many people cannot and many others choose not to do so; therefore, as an author, your aim is to make your content accessible to everyone regardless of which type of browser they are using. Making accessible pages is not really much more difficult than making 'normal' pages, providng you design in accessibility from the outset eg. one of the requirements is not using 'click here' as link text, since many people browse pages by tabbing between the links in a page - if the links don't make sense out of context then the pages aren't accessible to them. It's obviously much easier to design pages that don't use 'click here', than it is to go back and correct the whole site afterwards! Using tables to control layout is extremely bad from an accessibility point of view, since speech readers will read out the content of each cell in order, forcing an individual to listen to the same presentational information every time they access a new page on your site - but you should already be ahead on that one, since you'll have used nice CSS for your layout. For full details on how to make websites accessible start with the WC3's Web Accessibility Initiative. Do be aware that some of their guidelines have changed since the documentation was written and that it's a good idea to check the archives of the mailing lists for the initiative as well as the guidelines themselves. Links to other resources can be found on my links page.

On to something slightly more advanced now....it's often the case that you'll want all of the pages in your site to include the same code ie. a navigation bar, and that it'd me much easier for you to be able to edit that navigation bar once and not have to edit each individual page when you add new pages to the site. The answer to this is Server Side Includes or SSI (see links page for an up to date link) - something else I wish I'd known about, a month before I did:-)

Another way in which you can create dynamic content (ie content generated at the time the page is loaded, rather than static content that is always sitting on the server) is via JavaScript. I'm kind of boring and don't like things like mouse overs (where the text changes when the mouse is over it) or scrolling news tickers because I find them distracting. It does, however, have some uses - view JavaScript to see what I've done with it. Please just remember that just because you can do something doesn't mean you should ie. pop up windows are not appreciated by viewers, neither are links that open in new windows (if someone wants a link to open in a new window they're likely to have the technical ability to do it themselves). Also note that JavaScript is unlikely to be accessible to those not using graphical broswers, so make sure you provide an alternative means of presentation for the information.

Advice
Index