A belated continuation of my Web of Information series.
A Brief Recap
The web was created to make access to information easier by placing it in a structured/organized format (HTML). When the web became popularized, primarily through the invention of a graphical interface for the web, the focus changed to user experience. HTML documents became cluttered with presentation logic and the actual information with HTML documents became secondary. This is how things went wrong.
Purpose
There are no HTML police. Nobody to say what is right and what is wrong. We are allowed to do with HTML as we see fit. If I want 100 nested font tags that are never closed, so be it. What I want to do here is show that you don’t need font tags, or any other tags used only for presentation. They don’t belong in an HTML document and I want to cover why this is from both a practical and academic point of view. Furthremore, purposely not using presentation tags actually helps you to build a more well-structured HTML document. And the ultimate prize: with the wide support of CSS, you can have a single point that defines the presentation of your HTML structured information for all your HTML documents. Your HTML documents become smaller and easier to manage and, when done right, much more compatible with the large number of World Wide Web clients that are out there. Everyone benefits.
Just a note that my next post will focus on the how, which will discuss what I refer to as well-structured HTML documents. First we need to figure out why we want to create well-structured HTML documents.
Academic Perspective
HTML documents are structured information. That structure makes the meaning of the information more explicit and easier to interpret by a client (whether that’s a computer application or a user). So when we look at HTML documents and why presentation tags don’t belong, we have to think about meaning.
What meaning does a font tag provide to its contents? For a graphical interface it means how the text is to be rendered. This could be done in a manner to boost or take away importance of the text within the font tags. To any non-graphical client, however, the font tag is meaningless. How does a screen reader convey the difference between “Times New Roman” and “Helvetica”? It doesn’t. The font tag is ignored.
Another, more in-depth, example is looking at the differences between strong and b(old) tags. What meaning can I derrive from a b tag? Not much, if any. I know that b will make the text bold, but that’s about it. And while you might infer that bolded text should be given more importance over any surrounding text, that’s only an inference. The inference only works for visual-based HTML document processors, such as a graphical web browser. A screen-reader would get no meaning from a b tag, because there is no visual manner to bold the text. B is a strictly visual, presentational tag. Meaning added to the content wrapped inside b tags can only be inferred.
Strong, on the other hand, carries more than just a visual instruction. Strong explicitly tells the client that the content within the tag has a higher importance. How that higher importance is interpreted or rendered is up to the client and not a concern of the HTML document’s author. Visually, a strong tag is typically handled the same way a b tag, that is, the textual content of the tag is bolded. But now a screen-reader has a non-visual tag that it can do something with, such as increase the volume of the voice reading back the text.
The difference between b and strong may seem small, but it’s a very important difference. B is a cue to the client on how to visually render the content wrapped within. There is no added meaning to that block of content, just a change in how it is rendered. Whereas a strong tag explicitly tells the client that the content within is of higher importance. Strong adds meaning to the content it wraps. It is not a visually-oriented tag, it is a meaning-oriented tag.
The same discussion could be had on the differences between i and em. Subtle (to us users of graphical interfaces) but very important differences. And this is why I title this section “academic perspective”, because at the end of the day, the target audience of most HTML documents is a human operating on a graphical interface. To this audience, the difference between strong and b is pointless. But to HTML document authors, it should mean quite a lot.
There is a simple rule of thumb to go by that carries all of this thinking with it: There should be no information within an HTML document that is medium-dependent. That would have to include inline stylesheets and possibly embedded stylesheets as well. It’s a good rule but it can certainly be broken, so long as you have a specific purpose in mind for doing so. The practical perspective will give better reasons to support it.
Practical Perspective
This section will probaby carry more weight than the previous. Afterall, if a b tag is going to get the job done, who cares about the “academic” issues? If it works, it works.
Imagine you have a nearly infinite number of HTML documents on your website. Each page contains various font and b tags. Then one day you decide (or the decision is made for you) that the font type needs to be changed. You must now edit thousands of HTML documents to do so. A mass search-and-replace application might do the trick, but will it catch everything? What if the changes required were more complex; outside the scope of any searc-and-replace application? You’ll be handling each document by hand; a very tedious process.
Enter stylesheets. Create documents without any font tags. Allow for a single link tag in the head of the document which points to a stylesheet. That stylesheet then defines the fonts and colors and other presentation logic used to display all of your thousands of documents. When asked to change the size of a particular heading, or font type, a simple edit to that single CSS file instantly propagates out to all HTML documents.
The only caveat to this approach is that any documents with inline or embedded stylesheets, as well as documents with any presentation tags, may still need to be edited by hand to either remove or work around those particular instances. But if you remove all presentation tags and embedded/inline stylesheets, you won’t have to worry embedded presentation logic mucking up your global stylesheet. Thus I refer to the rule given in the last paragraph of the previous section.
I’m over-simplifying things a bit here because I want to move on. Chances are if you’re reading this you already have a good idea of the power of global/external stylesheets. But the caveat with embedded presentation logic, and thus why you shouldn’t have any, is something I want to cover a bit more first.
Embedded Presentation Logic
Let’s say you have a particular group of pages, among your thousands of HTML documents, which have blue-colored headings. To achieve this you’re using any manner of embedded presentation logic. By “embedded presentation logic”, I mean anything that dictates how a page is to be rendered that is local to the document, whether it be inline stylesheets via the style attribute, embedded stylesheets via the style style tag inside the head block, or font, b, i or other such presentation tags.
So you’ve got your blue headings, while the rest of the site uses the standard black-colored headings. Then you have to convert all your pages to red headings. This isn’t so bad, a quick addition to your global stylesheet to make all headings red and you’re good to go.
Not so fast.
Your embedded presentation logic is going to take precedence over anything you’ve placed inside your global stylesheet. Now you may start thinking about using the !important CSS directive, however you want to stay away from !important as much as possible. It overrides every other stylesheet value that exists, including any user-defined stylesheets. User-defined stylesheets are a bit new so they aren’t given too much thought, but a UDS can be used to give a color-blind user or a user with poor sight a chance to view pages in a color scheme or font size that makes it easier for them to read. If you override that, you’re degrading their experience and may even be blocking their ability to read the site at all. So let’s stay away from !important.
Even if you were to use !important, it still submits to the heirarchy of the document. If the heading color is set with !important but there’s a font tag inside that heading tag, your !important color becomes meaningless.
Your only recourse is to edit each HTML documents by hand to remove the conflicting embedded presentation logic. Had you refrained from embedded presentation logic, your life would have been a bit easier. So what else could you have done besides embedded presentation logic? In this example you could have simply created a .blue CSS class. This class could simply set the font color to blue. Now apply that to your headings and you’ve got blue headings. When you make your move to red headings, you could negate the .blue class for all headings.
Aside: Perhaps not the best approach from a CSS design standpoint. Maybe you call the class “specialHeadingOne” or something else that describes why there is a different color for the heading, rather than just the name of the color. That way your CSS doesn’t have a .blue class which has a red color definition in it. But that’s a whole separate topic entirely.
Motivation
Hopefully you can start to see the advantages to keep embedded presentation logic out of your HTML documents. I’m a bit strapped for time on writing this post up and I want to get it up ASAP so I apologize for any grammar/spelling errors.
In my next post I’ll talk about how you structure HTML documents without embedded presentation logic and utilize stylesheets to easily manage how your information is rendered to the user.
The Forgettable Mister Ruthsarian 