<link rel=stylesheet href=basic.css>
<h1>This is a simple demo</h1>
Indented <font class=special>text.</font>
<i>Jukka K. Korpela</i>
spanfor content to appear inline (inside a paragraph or other block),
divfor content to appear as a block.
supthat have varying and inconsistent effects on rendering.
fontis OK when you just wish to set the font of a word or inline phrase different from the surrounding text. But it’s more practical to use the
classattribute and CSS than to use the
faceattribute, because you should normally list several fonts.
<font color=#f66>, is OK when used for individual elements. It’s wise to use CSS instead when there is something to be gained that way, like uniform styling within a document or across pages. If you would e.g. use the same color twice, CSS is preferable, but you can still use
fonttags (if the text isn’t already marked up as an element), e.g.
<font class=red>♥</font>to produce ♥.
h2, etc. by the hierarchic level. Here we accept bad default rendering (too big font size), because heading markup is relevant to search engines, assistive software, etc.
br), but you can use them inside headings if needed.
divelement, if no default spacing above and below is desired.
pelement instead, or the
blockquoteelement if indentation is preferred.
ulfor a bulleted list (see The difference between
olelements in HTML)
olfor a numbered list
divor your own tag, like
divtags for each item, when no list markers are desired (typical for a navigation menu for example); however, for accessibility, you may consider using
tablefor a list where list markers are part of the content, as well as for a list of records to be shown in a tabular manner, including a list of form fields and their labels
dlfor a list of “name/value” pairs where the “value” appears under the “name” as an indented block
<!doctype html>, because it is the simplest way to avoid Quirks Mode.
<html lang=en>tag next, replacing
enby the ISO 639-1 code for the content language of the document.
<td>can always be omitted. But do not omit the “optional”
</p>tag, since it prevents some oddities in browsers.
It is easy to exaggerate the pragmatic principle so that the author considers only the visual effects of tags, using whatever makes things look good. It is the total effect that matters. The total effect includes functionality and impression on users.
Authors have used the
fieldset element to create
a block with a border that has rounded corners.
This used to be the only convenient way to produce such rendering;
nowadays CSS (
border-radius), though still with
somewhat limited browser support.
does not normally cause changes in functionality, but assistive
software may announce the element to the user as a fieldset.
This may confuse the user to think that there are some form fields
So it is better to use
only according to its defined meaning, for grouping form fields.
Besides, most browsers nowadays do not even use rounded corners for fieldsets
textarea element has fairly often been used
just to create a scrollable area of text. In the early days of HTML, this
was the only way to create such an area. Nowadays, there are better
ways in CSS, and even the
iframe element could be used.
The main reason for avoiding such use of
that it creates a presentation that most often indicates a text input
area. Thus, using it for mere presentation of text
may confuse users, at least mildly.
Use different markup for elements that might conceivably be styled differently. For example, foreign-language phrases such as fait accompli might be rendered as normal text, or in italic, or maybe even in some special color. Similarly, there are several conceivable styles for a term when a definition is given: “By tactile we mean…” Contrast this with a scientific species name Homo sapiens or a quantity symbol like designation like m for mass in physics; these expressions are to appear in italic by the conventions of biology and physics.
<i class=foreign>fait accompli</i>
<i>m</i> = 2,4 kg
Thus, if you decide that italic is the
best default rendering for all
of these cases, use the
i tag by all
means, but distinguish the cases by using suitable class names.
The cases where italics is the only correct rendering do not
class attribute, unless you have some special
use for it (in, say, client-side scripting).
This way, you are prepared to requests like
“show the defining occurrences in normal text style but
with a yellow background“
Then you would not need
to go through all of your markup to find your
i elements and decide which of them are
to be styled that way. You would just add one style sheet rule,
padding: 0 0.2em;
Why not use
dfn for the defining occurrence?
It would be “semantically correct” by the specifications,
but then the default rendering would be italic on some browsers,
normal text in others. (The risk for getting normal text is small,
but why not use the safer tag?)
The three list elements
dl are often convenient tools for setting
up bulleted, numbered, and description lists,
respectively. Use them when they serve such purposes,
but do not think that any list must be written
using one of them.
It does not make much sense to use
and then consider how to get rid of the bullets.
ol gives you simple browser-generated
numbering. If that’s fine, use it; if you need some
more complicated numbering, forget
It might be argued that list elements are partly functional. A speech browser may announce a list by saying something like “a list of fifteen items“, and this may help the user. It may distract, too. A speech browser could also have a command for skipping an entire list. There are many things that could be done with markup, and some of it is actually being done in some software, but it would still be pointless to require that every list be marked up using specific HTML elements.
<td id=content>Content proper
Use tables for tabular data and, when appropriate, for layout.
Tables are the most reliable and robust way of putting elements in columns in the broad sense.
Complicated layout is messy and risky, but the solution is to simplify things, not to complicate them
by using to loads of
div elements placed with CSS positioning.
The most vulgar forms of the anti-table-movement tend to attack undeniable tabular data too, requiring tag soup approaches (
span, with loads of tricky, kludgy, and unreliable CSS code) to them as well.
In the more educated circles, there are endless debates of what is a “real table” or “tabular data”. What you call a table tells more about you than the data. This makes the vulgar form somewhat reasonable. Why waste time on cutting hairs when you can spend it on coding?
It's usually pointless to debate against the anti-table-movement, in any of its form. Just as it is pointless to debate on religion or to fight against superstitions. People change convictions, but debates don’t tend to prevent rather than cause that.
Many sites that use tables for layout have serious problems, but they are caused
by complexity of design, designing for some specific window width
requirements on pixel-exactness. In most cases, the
div + CSS
school has just made the situation worse. They keep repeating dogmas they learned from somewhere, without ever stopping to cite any factual evidence. The most honest of their dogmas is
“layout tables are outdated”.
For simply placing an element on the left or right of other content, consider using
align attribute or the
float property in CSS.
However, that makes the other content “flow” around it, and if you want a different setup,
you probably want a table.
If you expect to need to essentially vary or modify the layout without changing the markup,
div approach is better than tables.
IE (at least up to IE 9) does not let you change the basic rendering
In order to style tables, use primarily CSS, simply because it is easier
and offers more possibilities than presentational HTML attributes.
However, for example, for a column of numeric data, consider using the
align=right in each cell; this
works even when CSS is off.
People often get tired of writing or even reading markup like
instead of simple
It’s not just a matter of convenience of coding. If you need deeply nested elements, it gets difficult to keep track of
</div> tags. Take a large HTML file and try to find out which major
constructs are terminated by each of such tags.
Well, HTML5 drafts contain new elements like
for such reasons.
However, HTML5 does not let you use the tags you like. It just adds
a set of tags, selected largely to reflect
values that authors seem to use frequently.
In practice, you can still use your own tags. Instead of
clumsy markup like
you can use
You can combine blocks (paragraphs, headings, etc.) into larger units using your own descriptive markup, e.g.
This improves the readability of the markup and makes it is easier to associate end tags with start tags.
There are some problems, though:
commentis a good tag name, think again: it causes some versions of IE to ignore all of the contents of the element!
These problems, except for the last one, relate to new HTML5 tags, too (though the second last is only marginally relevant).
So it’s your call—maybe. Your boss, your client, or your partners may have a word to say on using tags, and in education and training, you will probably be told to use the Right Markup, whatever it might be this week. But if you can choose, the benefits of “custom tags” probably outweigh the risks.
You could also use custom attributes, as in
and corresponding attribute selectors in CSS, e.g.
While this works on modern browsers, there is not much to be gained in comparison with
using classes, and class selectors are better supported in old browsers.
Remember that a
class attribute value may contain several class names
(well supported in browsers), e.g.
class="employee male important".
I was an advocate of semantic HTML markup for nearly 20 years. After much frustration, I was converted. A decisive event on the road to admitting the defeat of semantic HTML and drawing the conclusions was Ian “Hixie” Hickson’s message dated Sun Feb 12 13:25:52 PST 2012, with the title The blockquote element spec vs common quoting practices in the public WHATWG Working Group mailing list. He wrote, among other things: “The use case for most of the ‘semantic’ markup is [just] easier authoring and maintenance, in particular for selectors in CSS.”
Perhaps authors will use the new HTML5 tags widely, according to HTML5 rules, making the markup easier to read and modify to coworkers or others who work on the same markup. But I don’t see this as a big issue. And it is not realistic to expect (though admittedly possible) that browsers will do anything special with these elements (except render them as blocks and not inline elements) or that search engines will get enthusiastic about them.
I have intentionally written mostly about tags here. I know the difference between tag and element quite well. I even know that confusing them with each other can cause real trouble. But for the purposes of this presentation, tag is suitable. After all, we talk about tag soup, not element soup.