Controlling HTML Layout

One of the most important aspects of template design is the ability to control your HTML layout. It's all very well to have knowledge of HTML programming, but you have to be able to use that knowledge in a coherent pattern so that your code is easily maintained and readable by other developers.

There's no doubt that times are changing fast and with the introduction of HTML 4.01, new web components such as CSS (Cascading Style Sheets) are being drafted in to shift the balance of how we looking at controlling HTML.

During the early stages of web development, everything was contained in HTML. Font stylizing, image formatting and table settings were provided as attributes to your basic tags. As CSS became popular, we began to look at the prospect of splitting the formatting side of development and separating it from the minimal structure of a layout.

Inevitably, CSS has become the standard for creating themes and controlling the way that content displays on a page. We no longer declare descriptive attributes in the HTML tags themselves, and instead use what's known as a CLASS tag to point to the relevant definition in a CSS file.

What does this have to do with controlling HTML layout, you ask? The process simply narrows down what we're required to include in the HTML itself. Global style sheets are perfect for making site-sweeping changes without going in to every last page and editing each tag. You don't particularly want to be doing editing thousands of documents on a sizable website, to make one small change.

CSS has also recently developed in to an alternative for how we assemble the layout itself. The use of tables to arrange content is slowly giving way to the new CSS method. This transition looks inevitable with XHTML waiting on the horizon as the standard bearer for all web developers in years to come.

Currently however, tables are still by far the most popular method for controlling a layout. We can use a single large table to contain all of the content on our webpage, but you should carefully consider the implications of doing so.

The problem with tables is that they can be extremely awkward once you have them in place. The nature of dividing a page in to columns and rows means that modifying an area of the site can have a knock-on effect. Another issue is screen resolution. How big should your tables be?

A table which fills up a 1024—768 screen resolution is going to display somewhat inconveniently on a 640x400 monitor. There is, however, a way for us to negotiate this problem and regain control over our HTML layout. By setting the TABLE WIDTH and TABLE HEIGHT attributes to percentages, the table will automatically resize itself to suit the user's browser. This is a great way of making your code portable across multiple platforms, but you should be aware that if you use images, the cells will automatically adjust to accommodate them. Expandable layouts are the best kind, but it isn't always easy to make your graphical design function in the same manner as you'd have hoped, tables can be very messy to work with and one slight alteration can throw the entire page in to a scramble heap.

Visual development tools are extremely helpful for controlling HTML. By using a designing suite such as Macromedia Dreamweaver, you can control your webpage with a graphical interface that's capable of displaying the actual page as you modify them. Indeed, with Dreamweaver you can make direct changes to the visual interpretation and the code will regenerate to reflect them.

While the assistance of layout tools is certainly welcome to a developer's aid, the rewards of manual coding are obvious. Not only can you go in and edit outside of your third party developing environment, but you don't have to deal with the ugly "scrap code" that programs like Dreamweaver are capable of producing.

The subject of scrap code brings us to one of the most important displays of etiquette from a web developer; HTML presentation.

More often than not in the commercial world, you'll be designing a website for a client who'd ideally like to be able to read the code once you've finished with it! What if the client needs to make edits several months down the road and your code is presented in such a mess that it's impossible? More to the point, what if YOU need to go in to your code and make a change?

HTML, despite its simplicity in comparison to other programming languages, is not always easy to read. Commenting and indenting your code is an absolute must if you're working on a large scale. Comments are displayed in the source code and can be viewed only by those who open your page in an editing environment. They're a polite form of annotation which you should get in to a habit of using on a regular basis to make your code readable.

You can implement a comment in the way shown below:

You can also use multi-line commenting with asterisks to write several lines of annotations.

Indenting is just as important if you expect anybody to be able to read your page or go in to maintain the layout. Be sure to indent to the right with every new table, or every new subset of a tag. There's no fixed requirement for how you should indent, as long as your page is clearly readable. But a separate indentation for every level of code is widely considered to be the recommended practice.

Controlling HTML layout is an important skill to master and one which will prove valuable in all aspects of web development. No matter what programming language you're using, HTML is ever-present on the web. Understanding the workings of the language and how it can be molded to suit your needs will go a long way towards designing a perfect website.