Troubleshooters.Com and Linux Library Present:

Using Bluefish to Make Web Pages

Copyright (C) 2013 by Steve Litt. All rights reserved. No warranty, material provided as-is, use at your own risk.

CONTENTS:

• Introduction
• Bluefish Is Here To Stay
• Bluefish Can't Do It Alone
• Bluefish Hello World
• A Structured Document
• CSS Hello World
• More CSS
• A Word About Productivity
• CSS: A Discussion
• HTML Refresher
• Creating and Debugging Multilevel Lists
• Getting An Assist From Bluefish
• Bluefish Isn't Perfect
• A Few Final Words

Introduction

I used Notepad to write a couple websites in 1995. When the first 25 pages of Troubleshooters.Com were written in the summer of 1996, MS Frontpage was my tool of choice. Because it was WYSIWYG, it was much, much easier, faster, and less error prone than a text editor. By January 1997, WYSIWYG Netscape Gold was the Troubleshooters.Com HTML editor of choice.

As time went on, and Troubleshooters.Com migrated from Windows to Linux, and then bounced between Linux distributions, the chosen web editor progressed through various descendants and forks of Netscape Gold: Netscape Composer, Mozilla Composer, Nvu, Kompozer. Then came the great WYSIWYG HTML editor drought of 2013.

Ubuntu dropped Kompozer. I switched to Bluegriffon, an "I'll show you" type fork from one of the original authors of Nvu or Kompozer. But my laptop OS, OpenSuSE, didn't have Bluegriffon, it still had Kompozer. For how long, nobody knows. And of course there was the fact that Bluegriffon couldn't do certain things I was used to doing. And given the fact that the entire reason I used WYSIWYG HTML authoring tools was speed, and the fact that Bluegriffon was slowing me down, what the heck was I doing?

Before going on, let me explain why I used WYSIWYG editors for sixteen years, in spite of the fact that most of my technologist friends urged me to edit HTML directly. I'm a production man. Words per day is vital to the way I write, and the way I do business. Typing out tags is slow -- remembering which codes to type out, and they're syntax, is a lot slower. Slow enough to make me forget my train of thought while writing. Totally unacceptable.

So even though WYSIWYG HTML editors routinely spit out bad, nonstandard HTML that is only renderable though the largess of overly permissive browsers, I used them to speed my work. Even though, after 16 years creating content for Troubleshooters.Com, I was still only moderately literate in HTML, I used them to speed my work. Then the WYSIWYG HTML editor drought of 2012 forced me to go to a text editor.

So why did I bore you with my personal story? It's so you understand, without doubt, that I'm a WYSIWYG fan due to speed, and when you read this document about using Bluefish, you're reading the words of a production man, not an HTML aficionado. If HTML authoring is a substantial part of your business, you can't afford to author at anything less than your typing speed. This document will teach you how to do that in Bluefish.

And, as you learn to make yourself a content fountain in Bluefish, you'll come to realize the side benefits of Bluefish: Your HTML is pure, test-passing HTML. Your appearances are created by CSS, not by mechanically placing <center> and <font> tags all over the place, and trying to remember how you formatted the last instance of what you're doing now. And you'll know that if a browser doesn't render your stuff, it's the browser that's nonstandard, not you.

So kick back, relax, and enjoy life as you learn how to use Bluefish to whip out content as fast as you can type.

Bluefish Is Here To Stay

Bluefish is here to stay. It's been around since 1997. It's always done the same thing: Edit text while giving help with syntax. During Bluefish's life, Netscape Gold, Netscape Composer, Mozilla Composer (except the Seamonkey variation), Nvu and Kompozer have all come and gone, but Bluefish has kept on keeping on. There's no reason to think it won't be around ten or twenty years from now. This is your justification for taking the time to learn Bluefish.

Bluefish Can't Do It Alone

This document illustrates using Bluefish to be as productive as with a WYSIWYG editor, but it isn't done with Bluefish alone. A text editor needs other features to achieve the productivity, of, let's say, Kompozer. No problem, these features are easy to come by or make.

Firefox Auto Reload Addon

You can make Bluefish almost WYSIWYG by viewing your work in a Mozilla Firefox browser equipped with the Firefox Auto Reload extension, available at https://addons.mozilla.org/en-US/firefox/addon/auto-reload/.

What this addon does is that every time you save your document in Bluefish, the browser viewing the edited page automatically updates. You open Bluefish on one side of your screen, and Firefox on the other, and it's pretty darn close to WYSIWYG. You don't get vertigo wondering where you are or what you need to do next, or what the structure of your document is. If you accidentally used an <h1> instead of an <h2>, you'll see the problem instantly and correct it. And when you're tweaking your CSS to get *just* the right appearance, The Auto Reload Addon makes it quick and convenient.

Tidy

Tidy is mainly a pretty-formatter for HTML, so why the heck am I using it? I hate indentation in HTML. Start indenting, and the next thing you know you'll be confused as hell. And of course, proper indentation is almost impossible to maintain over time. And it makes your text walk off the right side of your editor. And all these pretty formatters -- they all have a different idea of what "proper" formatting is than you do.

Me, I just start all paragraph like stuff flush left, and put character style like stuff, <span> for instance, inline. I place a blank line and a prominent 1 line comment before each <h1>, separate <p> paragraphs with one blank line between them, and everything's pretty neat and understandable. So why do I need Tidy?

Here's why:

tidy -e myfile.html

With its -e option, Tidy becomes an HTML syntax checker. It finds those missing angle brackets or extra doublequotes that browsers merrily interpret in whatever way they can, often misrepresenting your content. For each error or warning, it gives a line number. That line number is the same as the line number in Bluefish, so you can go right there and fix it. When you get down to zero errors, you can be pretty sure that you have a valid HTML doc that will display the way you intend it to display.

Label Maker

One wonderful thing about every WYSIWYG HTML editor is that it makes id labels for you. So when you make an <h1> line with its text title, the WYSIWYG automatically inserts a relevant, HTML correct id. For instance, if your title were to be "My Wonderful Summer", the WYSIWYG would make something like this:

<h1 id="my_wonderful_summer">My Wonderful Summer</h1>"

That id, of course, is what you use for cross references and your page's table of contents, so it's important that it remind you of the heading's title, and that it be valid HTML, and most importantly, that it happen fast, with no thought on your part. If you need to think about your HTML, you forget about what you're writing.

So I used the Lazarus clone of Delphi to make a tiny program that converts titles to ids, including the id=", so that you literally just convert and paste. So, once I've made my title, I highlight it, press Ctrl+C, start the labelmaker with 2 keystrokes, Ctrl+V to copy, hit Tab twice, Ctrl+C to copy the highlighted id code, Alt+Tab to get back to Bluefish, cursor just between the 1 and the >, and press Ctrl+V to copy. Bang, I'm done.

I read back that prior paragraph, and my first thought is "oh my gosh, that's a ton of work, I'd rather just type it in." But you wouldn't. Because typing it in pulls your mind off what you're writing about. In contrast, the twelve keystrokes listed in the preceding paragraph are just muscle memory. You can do them in your sleep. You can do them without one bit of conscious thought, and therefore, without losing track of what you're actually writing.

Because it's written in Lazarus, I'm not going to Open Source my Label Maker. If I get enough requests, I might make the executable available free as in beer, for the express purpose of serving as a prototype so someone can rewrite it in a language more accommodating to Open Source.

Table of Contents Maker

No HTML editor has this. No WYSIWYG, no text editor. Which is too bad, because it's such a timesaver. In 10 seconds, my Table of Contents Maker (TOCM) can read an HTML file, gather the id and text from every <h1>, and format them into an unordered list of bolded links. The table of contents in this document was made by my TOCM.

If lots of people want my TOCM, I'll be glad to slap an Expat license ( http://www.gnu.org/licenses/license-list.html#Expat ) on it and make it available on Troubleshooters.Com. It's a simple little Python script that doesn't handle edge conditions and right now can handle only output from Bluefish, but with a little ruggedizing of a few regexes in the program, it would be pretty universal.

Bottom Line

The bottom line is this: When you add a few tools to Bluefish, you get a highly productive web authoring tool.

Bluefish Hello World

Have you noticed that up until now, I've talked about everything except Bluefish? Let's fix that right now.

Run Bluefish on your Linux or BSD box (I have no idea if it works in Windows). Size its window so it takes up the left half of your screen. Then run Firefox, equipped with the Auto Reload feature, in the right half of the screen. Use hello.htm as your URL, and it will give you a not-found message. No problem. Read on...

You'll notice that Bluefish has presented you with a blank document in a blank screen. Very unhelpful. No problem. Do this:

1. From the menu, Dialogs->General->Quickstart. A big dialog box comes up.
2. Keep the DTD at HTML 4.01 strict, or whatever its default in the version you use.
3. In the Title blank, put in Hello World.
4. Click the OK button. You're now back in Bluefish, with a bunch of your document's <head> section ready to fill in.
5. DANGER WILL ROBINSON! Bluefish's "save as" facility is sticky, at least by default, so when you save this file, you need to be very careful to get the intended directory.
6. Save the file as hello.html, in the same directory as Firefox currently has in its URL. In other words, you're saving it to the URL that Firefox tried and failed to find before.
7. You'll notice that in Firefox, the "not found" message disappears and a blank document, whose titlebar title is "Hello World", replaces it. Of course, this will happen only if you installed the Auto Reload addon. If you haven't installed this addon, you'll need to refresh the page to see the new content (or in this case, lack thereof).
8. Inside the doublequotes denoting the value of meta name "author", place your own name. Feel free to fill in any other values, as long as you do it within the proper doublequotes so you don't mess up the HTML.
9. Place your cursor on a line between the <body> and </body>
10. Type the letter p, then press Shif+Ctrl+Enter. Notice that an opening and closing paragraph tag is created, with the cursor between the tags, ready for you to type.
11. Type Hello World!
12. File->Save
13. Notice that, in Firefox, the phrase "Hello World!" appeared in the document's body soon after you saved the document. This is Firefox's Auto Reload addon at work. If you don't have Auto Reload installed in Firefox, you'll need to refresh the page. If you haven't yet installed Auto Reload, I suggest that if at all possible, you do it now.

You've completed your Hello World. You've created a simple document in Bluefish. You've seen the power of Firefox's Auto Reload addon. And you've seen Bluefish turn the letter p into an open-close tag pair, with the cursor between them, ready to type. Do you think that might save you some time? You better believe it!

The creation of a tag pair from a single letter plus press of Shift+Ctrl+Enter is the tiniest example of something called Zencoding. With Zencoding, you type out the tag as a word, without the angle brackets, and then press Shift+Ctrl+Enter, and it makes a tag pair with the cursor between, ready for you to type. Better yet, if you were to type p.myclass and then Shift+Ctrl+Enter, it would fill in the paragraphs class="myclass" part of the tag. If the tag has a specific id=, you type p#myid and then press Shift+Ctrl+Enter. Bluefish is full of Zencoding. It's all about Zencoding. Zencoding is what makes Bluefish so darned quick to develop. At your leasure, you can begin to scratch the surface of Bluefish's Zencoding by clicking on the Zencoding menu item in its menu bar. But right now, we have bigger fish to fry on your way to becoming the Potentate of Production. Read on...

A Structured Document

If you write content the way I do, it has headings, subheadings, third level headings, and the like. HTML gives us <h1> through <h6> with which to do that. Do the following:

1. Open your hello.html document in Bluefish, and manually change the "Hello World!" text to all uppercase. This is your on screen title.
2. Insert a blank line below that line, and then on the line after the blank, type h1 and Ctrl+Shift+Enter to create a tag pair. Type the phrase "My First H1", save the document, and look at the result in Firefox. The heading you just typed will be much bigger and bolder than your title. We'll make the title much bigger in another exercise. The thing to notice here is that formatting your heading took less time in Bluefish than it would have taken to type, reach for the mouse, highlight, and click the H1 button in a WYSIWYG editor.
3. Open a blank line below the heading, and type "Body of my first H1. Save the doc and note the effect in Firefox.
4. Open a blank line below that text, then another blank line, and on the second blank line type h2 and press Ctrl+Shift+Enter to create a tag pair. Type "This is my first H2 under my first H1. Save and observe the effect in Firefox.
5. Open a blank line below that, type p, and between the created tags, type This is the body of H2. Save and observe the effect in Firefox.

Lessons Learned

You once again saw Zencoding up close and personal, creating tags for h1, h2, and p. You typed in content. You saw your content formatted as structural headings h1 and h2

But the result wasn't very rewarding, was it? The body of the H1 was closer to the following H2 than it was to the H1 to which it belonged. Both the H1 and H2 lines were physically bigger and bolder than the onscreen title.

When I used WYSIWYG editors I just fingerpainted sizes and colors as if I were using Microsoft Word. But with Bluefish, I have something better. CSS. Read on...

CSS Hello World

Keep open or reopen the document you created in the A Structured Document article. Notice once again how pitifully small the onscreen title is. It looks like just any other text. This is clearly inexusable, and you'll fix it, the right way, using CSS. Do the following:

1. Open up several blank lines just above </head>.
2. In the center of those several blank lines, type the following CSS code exactly as you see it here:
   

   <style type="text/css">
   p.title{
    font-size: 300%;
   }
   </style>
   

3. File->Save and note the effect in Firefox. The effect is zero. Read on...
4. In Bluefish, go to the actual title, and within its <p> tag, place your cursor between the p and the closing angle bracket.
5. Type a space and then the letters cla. Notice that a little prompter opens up, showing class="". When you see that prompt, press the Enter key, and your cursor will be between the doublequotes.
6. Type the phrase title
7. File->Save, and notice the changes within Firefox. Is the onscreen title big enough for you now? It should be three times the size of normal font in this document, which makes it huge. If not, go back and make sure you typed in the CSS exactly how it was stated in this document, complete with every colon and every semicolon.
8. Contemplate that what just happened is that you defined p.title, and that definition governs any <p> whose class is "title". So when you set the title's paragraph open tag's class to "title", the CSS you'd typed in governed the title, and the title's size was increased by 300%.

Lessons Learned

You just changed the appearance of the title. You did that by:

1. Changing the class of the title's <p> tag from nothing to "title", and
2. Within the <head>-</head> area, defining a CSS style for class "title" of <p>.

Congrats, you've just used CSS to change an element's appearance, the right way.

More CSS

In the preceding exercise you changed the title's appearance to make it big enough to be a title. Is it just me, or is that insufficient to make the title look like a title. To me, a title has the following properties:

• It is bold
• It is centered
• It is closer to the top of the document so it doesn't waste so much space.
• Your mileage may differ, but personally I like my titles dark red.

If you remember, within the head area of the HTML you put the following:

<style type="text/css">
p.title{
 font-size: 300%;
}
</style>

Now you'll add some more code to make it centered, bold, dark red, and closer to the top of the document. When adding this code remember that every CSS property looks like this:

property_name: property_value;

See the colon and semicolon? Those are part of the syntax. They are vital. If either is missing, your CSS breaks, probably silently, and you just wonder why your CSS has no effect. So *always* check and doublecheck to make sure your colons and semicolons are in place.

So, right under the line that sets the font size to 300%, add the following lines:

<style type="text/css">
  font-weight: bold;
  text-align: center;
  margin-top: 0ex;
  color: #990000;

So the finished product looks like this:

<style type="text/css">
p.title{
 font-size: 300%;
 font-weight: bold;
 text-align: center;
 margin-top: 0ex;
 color: #990000;
}
</style>

Save the document. If everything's been typed in correctly, your title will now be bold, dark red, centered, and much closer to the top of the document.

A Word About Productivity

At 3:15pm, I'd written about 2800 words of content in this document, according to a Lynx text dump piped into wc. I started this document at 10:45, meaning I'd spent 4.5 hours to write 2800 words of content. This is productivity on a par with my work in Kompozer and LyX -- it's excellent productivity.

Especially when you consider that I'm brand new to Bluefish. A week ago I'd never used it except for the occasional 15 minute test-drive. And I can also tell you the feeling I get using it is like the feeling I get using Kompozer or LyX -- I'm thinking about content, not about the program I'm using.

Is Bluefish as productive as a WYSIWYG product? Certainly not for the person brand new to it. And probably it will always be slightly less productive than a WYSIWYG editor. Slightly! For the most part, what you lose in needing to type in a few codes, assisted by Zencoding, you gain by other Zencoding gains and reduced reliance on a mouse. Bottom line, Bluefish is plenty productive enough.

Better yet, if I know the way things work on the Internet, I'll be deluged by Bluefish fans telling me the reason I'm so slow (2800 in 4.5) is because I failed to use this shortcut and that shortcut. And once I learn those shortcuts, who knows, it might become faster than Kompozer.

So you can feel free to use Bluefish with no fear of losing productivity, at least once you've had a week's experience with it.

CSS: A Discussion

Take a look at the document you're now reading. Notice that every <h1> level item is very dark blue instead of black, not enough to hit you in the face, but enough to make it subconsciously stand out. I wrote that property once in CSS, and now every <h1> level header implements it.

Notice that source code portrayed in this document is also very dark blue, plus of course monospaced font and slightly smaller than the rest of the print. One CSS definition did that. Did you notice consecutive paragraphs have quite a bit of whitespace between them? I defined <p> to do that, because my belief is that readers get less tired and less lost if paragraph delineations are clear at a glance.

Then there are the more subtle things. Notice that this document's <h1> and <h2> headings are much closer to the text they head than to the text above them. My CSS definitions of <h1> and <h2> did that.

The Two Kinds of Formatting

In any document that's basically content, there are two kinds of formatting possible:

1. Fingerpainting
2. Styles Based formatting

Fingerpainting is the mark of the rank amateur and to a lesser extent WYSIWYG products user, although with care you can use styles in WYSIWYG. Fingerpainting means that you format each new text chunk on the fly. You try to remember how you fingerpainted a similar situation the last time you encountered it, but you really don't have time to go back and research it.

With fingerpainting, if you decide to change the appearance of each and every <h2> heading in your document, you have to search for each one, and then change the code surrounding it. Invariably, formatting inconsistencies creep in, and those inconsistencies subtly detract from the reader's understanding of the meaning of your content.

Some fingerpainters fingerpaint with zest and gusto, and you can spot their work a mile away. Have you seen those websites that use seven different typefaces with all sorts of sizes, weights and slants, seemingly unrelated to the situation? The kind of web pages making you say "ouch, my eyes!" This is fingerpainting at its most exuberant.

By the way, if you have the slightest suspicion that the content you're writing might ever end up as a flowing text eBook format such as ePub, do not fingerpaint. Doing so leads you down the path to perdition.

Oppositely, with Styles Based authoring, the author doesn't insert formatting in the content, but merely identifies the style of each content element, and separately define the formatting properties of each style. Define the style once, use it a hundred times in the document. Or, if your style is a separate file, use it in hundreds of different files. Sure, it's harder to define a style than to fingerpaint, but you only do it once for each situation. And, if you change your mind about how some situation, let's say emphasis, should look, you change the definition, and all implementations of the style instantly change their appearance. If you want your content to look consistent and professional, Styles Based authoring is the only way to get there.

The way you do Styles Based authoring in HTML is to use CSS.

HTML Refresher

Bluefish prompts and even teaches you HTML and CSS as you go, but life is easier if you know the rudimentary basics, so here are the rudimentary basics...

CSS and HTML Tag Syntax

Here's the anatomy of a simple HTML tag:

<tagname>Content</tagname>

Here are some examples of simple tags:

<p>This is my paragraph</p>

<li>This is my list item</li>

Many tags have attributes, which are enunciated in the open tag:

<tagname attribute1="value1" attribute2="value2">Content</tagname>

Here are some examples:

<p class="myemph">I'm emphasizing this text</p>

<h1 id="my_h1_heading" class="mystandard">My H1 Heading</p>

When making your tags, always remember that styles-based authoring demands that any attributes be about the tag, not about the tag's appearance. The tag's appearance comes from a CSS definition of the tag's class. This means the following are contrary to styles-based authoring, so don't do them:

<p align="center">Don't center like this. Use CSS instead.</p>

<font size="3" color="red"><p>Soooo 1998. Specify font attributes with CSS instead.</p></font>

<b><tt><big>
You're kidding, right?<br>
<br>
This is ugly even by WYSIWYG editor output standards.<br>
<br>
Use CSS instead.<br>
<br>
<big><tt><b>

CSS Basic Syntax

CSS is in the <head>/</head>section, between a <style type="text/css">/</style> tag pair. Here's the basic syntax:

tagname{
 tagattribute1: value1;
 tagattribute2: value2;
}

And the following is a specific example that makes the document's paragraphs' text green, with a large (5x) bottom margin so paragraphs have lots of white space between them:

p{
 color: green;
 margin-bottom: 5ex;
}

Green print? Yes, one can silly aesthetic mistakes with CSS too. The difference is, if you did it with CSS, then when your readers tell you how lame green print is, you can change it by deleting that one line, instead of erasing font tags throughout the document.

There are many different kinds of paragraphs in a document. There are generic paragraphs. There are paragraphs expressing stories. Paragraphs expressing quotations. All sorts of specialized paragraphs, and each can be given its own class. For instance, the following might be the CSS for paragraphs expressing stories, which I always do in all italics, with more than normal indentation:

p.stories{
 margin: 1ex 6em 2ex 6em;
 font-style: italic;
}

Then, when you want to invoke some "stories" paragraphs in the body of the HTML, you do it like this:

<p class="stories">Paragraph text</p>

The following three paragraphs are formatted in the stories paragraph (yes, I really put that style in this document):

Lorem ipsum dolor sit amet, consecteteur adipiscing. Sit nisl imperdiet nostra, eget nullam ac suscipit. Justo rhoncus ipsum. Vulputate mollis a integer platea, donec, pharetra adipiscing vivamus hac.

Lorem velit vitae viverra sodales nisi sollicitudin pulvinar fusce. Phasellus, ultrices lobortis quisque hymenaeos dis erat arcu. Commodo ve nullam euismod pretium tellus eu. Per, nisl pede.

Platea augue condimentum urna diam porta massa. Velit, ve sociis vulputate neque pede enim nullam mattis. Dapibus dis, ut enim rutrum eros, ac pellentesque odio etiam enim natoque tellus. Ad. Quisque fusce ac odio, porta lacus condimentum arcu.

Of course, in reality, you'd probably do the preceding not with three class stories paragraphs, but with normal paragraphs inside a <div>/</div> container tag pair, and assign CSS to that tag.

CSS For Tags Inside of Tags

This gets a little more complicated, but the results are so darn cool you just have to know it exists, even if this isn't the time to master it. You can CSS-redefine any tag, for use inside a specific tag pair (container, for HTML cognoscenti), so that it adopts the new appearance only inside that tag pair. Here's an example of a container tag pair <div class="danger">/</div>, which implements a centered box, with loud colors, warning the user of a danger. This is more complex than the CSS you've seen so far in this document, but it's so darn handy you should know it exists. Here's the CSS involved:

div.danger{
background-color: #fff0f0;
width: 60%;
border-style: ridge;
border-width: 8px;
margin-left: auto;
margin-right: auto;
margin-top: 2ex;
margin-bottom: 2ex;
text-align: center;
}

div.danger p.title{
font-size: 200%;
font-weight: bold;
color: #99ffff;
background-color: #cc0000;
border-style: ridge;
border-width: 4px;
text-align: center;
margin-left: 0ex;
margin-right: 0ex;
}

div.danger p{
font-weight: bold;
color: black;
text-align: left;
margin: 0ex 0.5em 1.5ex 0.5em;
}

In the preceding, div.danger is the container. Its border and background color make it show up as a brightly, almost gaudily colored centered box, guaranteed to attract attention. Now notice the following CSS syntax:

div.danger p{propnames: propvalues;}

The fact that p follows the div.danger, separated by a space, means that this definition applies to any <p> found within a <div class="danger">/</div> tag pair, but does not apply to any other <p> paragraphs in the document. Once you start using this, you'll wonder how you ever got along without it.

Before concluding basic syntax, there's one other way to specify a specific class of, or more accurately, a specific situation of, a given tag. You can specify the format for a normal tag that appears inside a specific type of (container) tag.

Important Tags

HTML tags are numerous as grains of sand on Venice Beach, but most of your work will probably involve a sparse subset.

Paragraph tags

If you're anything like me, the good old <p> tag will be your most used. Every paragraph needs a <p> tag.

Because most documents have many different types of paragraphs (such as quotations or stories), you must define different paragraph types in your CSS. The three ways to do this are:

1. p.myattribute
2. mycontainer.mycontainerattrib  p
3. mycontainer.mycontainerattrib  p.myattribute

#2 is especially convenient because, when you use it in the document body, it involves much less typing, and Bluefish's zencoding and autocompletion are set up to do it without any cursor-keying.

Heading Tags

HTML defines six special types of paragraphs for use as structural headings in a book. The six are <h1> through <h6>. The intent of these tags is to define divisions and subdivisions in the document, similar to chapters, sections, subsections, etc.

Never use these tags as anything but structural subdivisions. Never use one because it happens to be the right size or appearance. Make a special kind of paragraph to suit those needs.

Span

The <span> tag is used to make what would be called "character styles" in MSWord or LibreOffice. When a word or phrase represents something special and needs to be formatted accordingly, you use a <span> tag. In this document I use two span classes: One for emphasis and one for command names, short references to pieces of source code, and the like.

<span> tags are used for short phrases, not for paragraphs.

Div

The <div> tag is used as a container for other elements, often but not always including paragraphs. Here are some practical uses of the <div> tag:

1. Styling a series of paragraphs, complete with special handling of the first and last paragraph. Note that this can be done just with the paragraphs, but it's harder and less portable between browsers.
2. Centering or right justifying contents of the <div> container.
3. Creating columns without resorting to tables.

If you ever consider using tables to display anything but tabular material, use <div> instead.

Pre

The <pre> tag is used to insert verbatim writing that displays linebreaks as they occur within the <pre>/</pre> pair. By default material in the <pre>/</pre> pair displays as a monospace font, but you can change that if you want to. You might have several different classes of <pre>, each with its own attributes.

Note that <pre> isn't as "raw" as you might like -- anything with angle brackets is treated as HTML. So, for instance, if you were that kind of guy (and I hope you're not), you could use <br> tags instead of newlines to make a new line. The one place where it might be handy to use this feature (flaw?) would be to emphasize specific words of code or commands. This would be typical with a command line session, where user input is bolded.

I've found circumstances where I need to show source code, but I need to emphasize the lines I just added. The best way to do that is by using two different classes of <pre> to give two different appearances, rather than using HTML tags inside .<pre>. By the way, if you ever need to document HTML tags themselves, inside an HTML document, you'll need to use &lt; and &gt; instead of the angle brackets themselves.

Tables

Tables work pretty much like they always did, except now that you're using Bluefish, you should change all appearances using CSS.

Tags You Shouldn't Use

Don't use tags that contribute appearance but no meaning. The tags governing a piece of text should convey the meaning or context of that text. For instance, use <span class="code">, not <tt>. Use <span class="emph">, not <em>.

Bluefish's zencoding helps you do this very efficiently. To type <span class="emph"></span> and end up with your cursor between the tags, ready to type, just do this:

1. Type span.emph
2. Ctrl+Shift+Enter
3. The tags are now complete, with the cursor between them, ready for action.

Here's a list of tags unacceptable for styles-based authoring:

• <tt>
• <em>
• <br>
• <b>
• <font>
• <small>
• <big>
• <strong>
• <sup>
• <sub>

There might be rare occasions when the preceding are acceptable, but those occasions would be rare indeed if you want to stick with styles-based authoring.

Important CSS Class Attributes

Class attributes are numerous as the stars in the sky, but a small subset should get you through the night. I've divided them by purpose:

• Font attributes
  • font-size
    • Specified as a percentage of normal font size, or various text values like large, x-large, etc. I just use percentages, personally.
  • font-weight
    • normal, bold, bolder, lighter, 100-900, inherit
  • font-family
    • serif, sans-serif, monospace, cursive, fantasy
    • Can also be an actual font name like "Times New Roman", but don't do that. See my font rant.
  • font-style
    • normal, italic, oblique, inherit
  • font
    • Please, do me a favor, and don't use this attribute. See my font rant.
• Margins and padding
  • margin
  • margin-left
  • margin-right
  • margin-top
  • margin-bottom
  • padding
  • padding-left
  • padding-right
  • padding-top
  • padding-bottom
• Colors
  • color
  • background-color
  • border-color
• Borders
  • border-style
  • border-width
  • border-color
• Other/Misc
  • display
    • inline-block, inline-table, block, among many others. Inline-block is good for bordered boxes.
  • text-align
    • left, center or right
  • border-collapse
    • collapse, separate, or inherit

Use Tables Only For Tabular Material

Back last century, before widespread adoption of CSS, one easy way to place a note, warning, tip, etc, in a centered, bordered and colored box was to use a table. Seemed pretty clever back then, even though that wasn't at all what tables are meant for. If you used WYSIWYG editors like I did, you might have kept doing it because it's easy in WYSIWYG.

Nowadays, we buy Maroon 5 downloads, not Ace of Base CDs. And nowadays, we box our special content inside <div>/</div> container pairs, not inside tables.

<div>/</div> can take all the same attributes as tables: background color, border size, color, and type, padding, etc. All you lose from using <div>/</div> instead of tables are the useless <tr> and <td> tags.

I've found exactly one thing more doable with tables than <div>: Centering the box, and also having the box grow and shrink to the text inside it. With tables, all that's necessary to do that is to, within the CSS of the particular class of table, put margin-left: auto; margin-right: auto. That doesn't work with <div>. But I found a workaround:

div.centerer{
width: 100%;
text-align: center;
}

div.mybox{
display: inline-block;
border-width: 5px;
border-style: ridge;
padding: 0.5ex;
}

div.mybox p.title{
text-align: center;
font-size: 200%;
}

div.mybox p{
}

The ability of div.mybox to shrink and grow with its widest content (up to 100% of window size) is due to its display: inline-block; attribute. But that still doesn't center the box, even if you put left and right margins at auto. So what you do is, you put it in an outside container with text-align: center;, so that the inline-block aligned box acts like text and gets centered. Pretty cool, huh? So you do this:

<div class="centerer">
<div class="mybox">
<p class="title">This is my note!</p>
<p>The quick, sly, fox jumped over...</p>
</div>
</div>

Pretty slick, huh? And remember, the centering style is so generic you can use it around anything.

Creating and Debugging Multilevel Lists

HTML lists are trivial until they go multilevel. Then life gets tough. And when they plunge to three levels and deeper, you need to take special steps to code them, and in the not unlikely things go wrong, to debug them. Please be aware that even a messed up multilevel list might render OK in some browsers -- browsers are that forgiving. But that's not what you want.

What you want is a list that's valid HTML. So what you need to do is check it with the following command:

tidy -eq

Only when it renders correctly and it passes the Tidy test with no errors or warnings is it acceptable.

Creating a Deeper Level

You make a deeper level by embedding a <ul>/</ul> pair within the parent pair. But where within?

Pretty much the standard in multilevel lists is for the lower level list to be under an item of the parent level. That means that the entire lower level list belongs to the item it's below. And that means that the parent item's end tag must come after the entire lower level list. So in the browser it would look like this:

• Item 1
• Item 2
  • Subitem A
  • Subitem B
  • Subitem C
• Item 3

The code that produced it looks like this:

<ul>
<li>Item 1</li>
<li>Item 2<ul>
<li>Subitem A</li>
<li>Subitem B</li>
<li>Subitem C</li>
</ul></li>

<li>Item 3</li>
</ul>

Do you notice I have no indentation? As things get deeper, indentation can actually screw you up because you make an indentation mistake, and then make coding mistakes to match the indentation mistake. So I eliminated indentation. Your mileage may vary.

Anyway, in the preceding HTML code, notice that the end tag for item 2 comes after all code for the sublist. In other words, the sublist is part of item 2. This is a very important concept, without which you'll travel the Avenue of Adversity. This is fairly easy to keep track of with two levels. More than two, not so much.

Item 1
Item 2
	Subitem A
	Subitem B
	Subitem C
Item 3

<ul class="level1">
<li>Item1</li>
<li>Item2<ul class="level2">
<li>Subitem A</li>
<li>Subitem B</li>
<li>Subitem C</li>
</ul></li>

<li>Item 3</li>
</ul>

Debugging Multilevel Lists

If your multilevel list doesn't look accurate in the browser, or it doesn't pass the tidy -eq test, then you'll need to debug it, and if you're running more than 2 levels, it's going to be difficult.

The first thing I'd recommend is that you format the list as described in the previous tip. That goes a long way toward making the list's complexity understandable. Once this is done, you're ready to begin phase 2...

Next, if you haven't yet, assign a class, indicating level, to every <ul> in the multilevel list. This way you can temporarily assign crazy, instantly noticeable colors to each level, to make sure the levels you intended to assign are really being assigned.

After that, use Bluefish's ability to fold tag pairs in a list using the tiny plus and minus signs to the left of the code in Bluefish. So what you want to do is start from the innermost sublists, close them, and see whether they either take too much code with them when closing, or leave some of their code outside when closing. Either of these indicates a tag mismatch. Work out from the innermost, until you've folded all the top level items, so that the list looks multilevel, and you see just the top <ul> and bottom </ul>, the list items between them, and nothing else. Then test with Tidy, and chances are, it will be OK. Be sure also to look on a browser to make sure it's how you intended.

If the advice in the preceding paragraph doesn't work, keep in mind that you can tag match by mouse-clicking immediately before or after either a start or end tag.

Getting An Assist From Bluefish

CSS is nice and all, but remember what I said in this document's Introduction: I'm a production man. I'd use Frontpage if it were the only way I could write content fast. Fortunately, Bluefish has a host of production-boosting features.

For one thing, it has good syntax coloring, not the hit or miss coloring for, let's say, Vim. And speaking of Vim, you can set Bluefish not to do any indentation for you, and that's the way I like it. I like my C, Lua, and Python source code indented, but not verbose content like a web page. And what I do is, as I type, I insert blank lines where they make sense. Between Bluefish's color coding, its ability to not indent, and my insertion of strategic blank lines, plus its quick search facility and Firefox's instant change tracking through its Auto Reload addon, I can always quickly find where I am and what's going on.

Next is Bluefish's Zencoding. I'd say at least half the codes you type are paragraphs: <p> and <p>. The fact that these codes can be written, and the cursor ready to write content between them, with easy key combo Shift+Ctrl+Enter, is a spectacular gift. Running a close second is Bluefish's ability to do the same thing with <h1> through <h6>, as well as its ability to turn span.code into the proper tag, with class filled in, with one Shift+Control+Enter, and likewise create an id with p#pagetitle.

Another Bluefish turbocharge is the fact that it knows HTML syntax: Its tags and their properties and those properties' possible values, and it gives you all this as auto-completion while you're typing. This works within the body's HTML, but also within the head's CSS.

In fact, one way to learn CSS is to make a dummy CSS declaration in the style part of the header, like this:

div.bogus{
color: red;
f
}

In the preceding example, the second you type the f character, a popup will list "float" and a bunch of properties beginning with "font".

Another of Bluehouse's productivity accelerators is the fact that it makes the mouse almost completely unnecessary. If you haven't tried an all-keyboard-all-the-time interface, try it. They're fast. Hugely, hugely fast. And if you're working on one of those notebook computers that move or click the mouse every time you accidentally touch it with your wrist, you can turn it off, because there's almost nothing in Bluefish that requires a mouse.

Bluefish Isn't Perfect

Bluefish is pretty darned good, but there are some things that would make it even better. On top of that list would be a feature that would offer autocomplete menus not only on HTML tag property names, but also on styles you've made. For instance, imagine your CSS has definitions for p.title p.contents, and p.hedgefund. What would be be perfect would be if, after you type or autocomplete <p class="", Bluefish would offer a popup with title, contents, and hedgefund, so you can choose which one you want. This would require Bluefish to have read and parsed your CSS, whether it's in a stylesheet internal to the current file, or an external one.

Also, if I'm going to be picky about things, Bluefish requires too much use of the cursor keys, which, due to their location, rips your hand from home key position. A lot of times, after you autocomplete a tag pair, where you really want to be is inside the opening tag, ready to autocomplete properties. Other times you want to be just where it puts you: Between the open and close tag, ready for you to type content. It would be nice to have a special keystroke place you within the start tag to begin autocompleting properties, then another keystroke to put you back between begin and end tags, and yet another keystroke to place you beyond the end tag so you can continue writing new content.

I have a suspicion thought. My thought is that either these things exist, or methods just as good exist, and I just haven't found them yet.

A Few Final Words

WYSIWYG HTML editors are getting rarer than hen's teeth. They go in and out of business constantly, there are none that are offered with all the major distros. This has always been the case, and it's the case even more now, that basing a website's future development on a WYSIWYG HTML editor is a risky business.

Meanwhile, Bluefish comes with most major distros: I know for a fact it's on Ubuntu and OpenSuSE. Bluefish has been available with most major distros since the late 1990's. Nothing is for sure, but Bluefish certainly looks like it's here to stay.

Bluefish is roughly as productive as the WYSIWYG HTML editors, and with Bluefish it's easier to write truly standards conformant HTML.

There are many web development alternatives. You can use CMS's like WordPress or Drupal, and for the most part stay away from HTML. You can use Rails or PHP to program yourself a website. You can pay big bucks for an HTML editor. You can pay a company really big bucks to make your website. You can continue using WYSIWYG HTML editors, hoping that some other WYSIWYG will replace the one that your distro just dropped.

My decision was simple. For seldom-changing, informational pages, I like the security, backup friendliness, portability and resource conservation of static HTML. And I demand an editor I can count on to be around next year. Bluefish was the obvious choice. If you write HTML professionally, you should check out Bluefish too.