Last year I wrote that it is still possible (although not recommended) to use the deprecated <font> tag in Dreamweaver CS4. I recently got an email in response to that post asking how to remove the font tag from existing, older documents using CS4.

The writer noted that it was relatively easy in CS3 “all you have to do is highlight the block of text you want to edit and select “default” in the font selector box and “none” in font size and instantly the code is removed.”

The good news is it’s also very easy in CS4. All you need to do is right+click the offending <font> (or other) tag in the Status Bar at the bottom of the Document Window and select Remove Tag from the pop-up menu.

Viola, no <font> tag.

Adapted from my Dominate Dreamweaver online training course.

Back in the day, the Hebrews had a habit of getting themselves into trouble in spite of their favored status with God. So he decided to try to make it easy on them by reducing the rules to Ten Commandments.

In search of similar guidance from a lesser deity (Adobe), I ventured to the top of our local equivalent of Mount Sinai where I received these Ten Commandments for Editing Dreamweaver’s Spry Menubars on a stone iPad.

1. Thou shalt not edit the style sheet without reading the comments.
2. Thou shalt not edit the styles haphazardly.
3. Verily, rules for some selectors are defined in two locations.
4. Thou shalt not edit the position or display properties within the menubar styles.
5. Thou shalt not use the height property within menubar styles.
6. Thou shalt not apply padding, borders or margins to menubar list items <li>.
7. Thou shalt not set widths for links <a> within menubars.
8. Thou shalt not edit the browser hacks.
9. Thou shalt not edit the menubar JavaScript file.
10. Verily I say unto you, a new style shall appear to define the appearance of submenus.

Click a commandment above to view the related commentary.

I. Thou shalt not edit the style sheet without reading the comments.

Some very clever person at Adobe (God bless them) hath taken the time to insert extensive comments into the code of the menubar CSS file. Open the CSS file and read those comments and you shall be enlightened (and save a lot of wasted effort).

II. Thou shalt not edit the styles haphazardly.

Adobe hath joined the various styles rules together to function in harmony. Editing them without a clear plan and understanding of their purpose is guaranteed to create more problems than solutions.

A good plan is to edit styles according to the structure of the HTML page (and for that matter the order the styles appear in the css file).

1. Overall list (ul.MenuBarVertical or ul.MenuBarHorizontal)
2. Top-level list items (ul.MenuBarVertical li or ul.MenuBarHorizontal li)
3. Overall sub-menus (ul.MenuBarVertical ul or ul.MenuBarHorizontal ul – notice the second ul)
4. Sub-menu list items (ul.MenuBarVertical ul li or ul.MenuBarHorizontal ul li)
5. Links (styles related to the <a> tag including hover, focus, etc. states)

III. Verily, rules for some selectors are defined in two locations.

Adobe hath divided the LAYOUT INFORMATION from the DESIGN INFORMATION (not a bad idea) so rules using the same style selectors may appear in both locations. You can edit them in either place but make sure the properties you set in the layout section aren’t overwritten in the design section.

IV. Thou shalt not edit the position or display properties within the menubar styles.

Those who have not yet eaten the fruit from the tree of CSS knowledge are often tempted to edit the position and display properties within the menubar styles. While some sins go unpunished, this one rarely does. It WILL break your menu. And, while we’re on the subject, don’t go adding position or display properties to the style rules that don’t have them either.

V. Thou shalt not use the height property within menubar styles.

It’s very tempting to try to “force” your menubar to conform to your design by defining a CSS height property for one or more of the menu elements and you might get away with it. But the odds are that, under some conditions, one of your menu items will wrap to a second line and the height properties you so meticulously set will be ignored or your links partially obscured.

To be delivered from this evil, the best practice is to allow the height of your menu and menu items to be determined by a combination of the text-size and padding of your menu link <a> style.

VI. Thou shalt not apply padding, borders or margins to menubar list items <li>.

Set the width of your menubar “buttons” using the list item <li> rules. Since, as it is written, padding, borders and margin add to the width of HTML elements, applying those properties to list items will likely break your design.

Apply padding and borders to your buttons using the link <a> rules.

VII. Thou shalt not set widths for links within menubars.

In the commentary for Commandment VI we learned the width of our buttons should be set using the list item style rules. Any attempt to set a width for the links will likely conflict with those settings. But be not afraid, because the display: block property in the link style rule guarantees the link will completely fill its parent li tag.

VIII. Thou shalt not edit the browser hacks.

What CSS hacks Adobe hath joined together, let no man set asunder.

IX. Thou shalt not edit the menubar JavaScript file.

Yeah though you walk through the valley of Javascript, you shall fear no evil (if you just leave it alone).

X. Verily I say unto you, a new style shall appear and it shall define the appearance of submenus.

And God said, “let the styling for the sub-menus be separated from the styling of the main menu.” And it was, with the addition of a new style rule, so.

By creating a new style rule (ul.MenuBarVertical ul li or ul.MenuBarHorizontal ul li for submenu list items and ul.MenuBarVertical ul a or ul.MenuBarHorizontal ul a for submenu links – notice the second ul in the selectors) you can define CSS properties that apply only to submenus (or more precisely to unordered lists that are themselves within an unordered list). And, by the way, you only have to define the properties that you want to be different from the main menu. The rest of the properties will be inherited.

Now, go forth and sin no more.

When you’ve been creating web pages as long as I have, it’s easy to start thinking you’re hot stuff. Then along comes some perfectly obvious little html shortcut that you’ve been overlooking for a decade. It tends to humble you pretty quickly!

And judging by the response at the DreamweaverClub.com forum, I wasn’t the only one surprised by this one. So I thought I’d share it with you.

As you know, when you link to a page using a normal link (such as <a href=”http://www.dwcourse.com”>DWcourse</a>) the link takes you to the top of the page. And, as many of you no-doubt also know, you can also insert an empty, non-link Anchor Tag (such as <a name=”item” id=”item”></a>) into your page and then link directly to the location of the Named Anchor within the page like this <a href=”http://www.dwcourse.com#item”>Link directly to item on DWcourse page</a>. To insert a named anchor in Dreamweaver select menu: Insert>Named Anchor.

Now here’s the obvious html fact that that I’d been overlooking. You don’t have to insert a named anchor into your page to link to a specific point within the page. You can link directly to any named object within your page. For instance, if you want to link to particular sub-sections of your page, each of which begins with an level 2 heading <h2> you can give each h2 a unique ID and link directly to it. In Dreamweaver you can assign an ID to an html object by selecting the object and typing the ID into the ID field in the Properties Inspector.

So, if your page looks like this:

<h1>Main Headline</h1>
<h2 id=”section1″>section 1 </h2>
content for section 1
<h2 id=”section2″>section 2 </h2>
content for section 2
<h2 id=”section3″>section 3 </h2>
content for section 3

You can link directly to section 2 from within the current page like this: <a href=”#section2″>Section 2</a> or from another website like this: <a href=”http://www.dwcourse.com#section2″>DWcourse Section 2</a>. No need to clutter up your code with an empty Named Anchor!

And, to point out the (now) obvious, the # (number sign) within a link refers to a named html object within the page, just as a # within a CSS selector refers to a named object.

I feel a bit stupid. In my recent Stop “Untitled Document” in Dreamweaver post I reported what I thought was a very clever way to find pages titled “Untitled Document” using Dreamweaver’s search function. It turns out there’s a built-in function that will will do the job:

1. Select menu: Site>Reports…
2. In the reports dialog:
   1. Leave Current Local Site selected in the Report On menu.
   2. In the Select Reports area of the dialog, check the Untitled Documents under HTML Reports.
   3. Click the Run button.

The Results palette will open and all documents with the title “Untitled Document” will be listed in the Site Reports tab.

In my defense, my earlier method gives you the ability to scan the titles of all your documents, which can be pretty handy.

If you’re like most folks, you occasionally forget to re-title you pages in Dreamweaver and then look foolish when you end up with pages titled “Untitled Document” (see Google search for “Untitled Document”). I like to check all my page titles before uploading a site but it’s a pain to open every document and it doesn’t alway happen. It finally occurred to me that I could use Dreamweaver’s Search function to simplify the process.

To access a list of all the page titles in your website:

1. Select menu: Edit>Find and Replace… (or Control+F/Command+F)
2. In the Find and Replace dialog:
   1. Select Entire Current Local Site from the Find in menu.
   2. Select Specific Tag from the Search menu.
   3. Type “title” into the text field that appears to the right of the Search menu (or select title from the popup menu to the right of the field).
   4. Click the Find All button.

A list of the titles of all pages in your site will appear in the Search tab of the Results palette (generally at the bottom of your screen). If you find an Untitled Document in the list, simply double-click on the search result and the page will open so you can edit the title.

A lot of folks are whining and moaning because Dreamweaver CS4 now enforces the use of CSS styles rather than HTML attributes for formatting. One of the things this means is no more font tag (and its related attributes).

That’s a good thing in my book. No more code like this:

<p><font color=”#003399″ size=”5″ face=”Tahoma, Geneva, sans-serif”>paragraph 1…</font></p>

<p><font color=”#003399″ size=”5″ face=”Tahoma, Geneva, sans-serif”>paragraph 2…</font></p>

<p><font color=”#003399″ size=”5″ face=”Tahoma, Geneva, sans-serif”>paragraph 3…</font></p>

Well you get the idea!

But CS4 has a dirty little secret and , against my better judgement, I’m going to reveal it:

IT’S STILL POSSIBLE TO USE THE DREADED FONT TAG!

The secret is CS4′s Wrap Tag… and Edit Tag… commands, both of which are accessed from a pop-up menu that appears when you right+click on a selection in the Design window. Here’s how it works:

1. In the Design window select some text.
2. Right+click on your selection and select Wrap Tag… from the pop-up menu.
3. In the Tag Editor dialog type in <font> (or choose it from the tag list) and press the Enter key twice (once to “set” th tag and once to dismiss the dialog). The text will remain  selected.
4. Right+click once again on your selection and select Edit Tag <font>… from the pop-up menu
5. In the Tag Editor – font dialog, make your selections for Face, Size and Color and click OK.

If you look at your code you’ll see something like this (shudder):

<font color=”#FF0000″ size=”+2″ face=”Tahoma, Geneva, sans-serif”>content</font>

That’s all there is to it.

To edit an existing font (or some other HTML) tag:

1. Select the entire tag by clicking within the tag in the Design window AND then selecting the tag from the tag listing in the status bar at the bottom of the Document window..
2. Right+click on your selection and select Edit Tag <selected tag>… from the pop-up menu.
3. Edit the tag attributes in the Tag Editor dialog and click OK.

Just don’t tell anyone I told you how to do it.

As always, feel free to comment here or email me with your questions, comments and suggestions. And please follow me on Twitter (DWcourse) for additional Dreamweaver news and tips.

My iMac recently froze up and, when I – eventually – recovered from the forced shut down and restart, I discovered my Dreamweaver preferences had been reset to the default settings and, even worse,

ALL 50 OF MY SITE DEFINITIONS HAD DISAPPEARED!

I have my site definitions backed up (most of them anyway) but the option of importing them one by one didn’t really appeal to me. Besides, I have Time Machine installed so I reasoned that, if I could figured out where Dreamweaver stores its site definitions, I could restore them all from the backup.

Well, it took a bit of research but I was able to make it work. Should you wind up in the same situation, here’s how to do it.

Sorry but these instructions are Mac OS X and Dreamweaver CS3 and CS4 only, if anyone can figure out how to do the same on a PC or for other versions of Dreamweaver, I’m sure a lot of folks would like to know about it.

Dreamweaver CS4 Mac stores site definitions in the file:

Macintosh HD:Users:<username>:Library:Application Support:Adobe:Common:10:Sites:Site Prefs

For CS3 the file is: Macintosh HD:Users:<username>:Library:Application Support:Adobe:Common:9:Sites:Site Prefs

Substitute your user name for <username> and, if you have renamed your computer’s hard drive, sub your drive’s name for Macintosh HD. The colons separate folder names.

Using Time Machine, restoring the site definitions was a simple matter of selecting the file, activating Time Machine, scrolling back a day or two and selecting Restore to replace the current (empty) Site Prefs file with the previous version.

Note: Make sure that you have Dreamweaver closed when you restore the Site Prefs file or the restored file will end up empty as well.

As I said, I also lost my customizations to Dreamweaver’s preferences. I was able to restore them in the same way. Dreamweaver’s preference settings are stored in the file:

Macintosh HD:Users:<username>:Library:Preferences:Adobe Dreamweaver CS4 Prefs

Of course, it’s Dreamweaver CS3 Prefs for users of Dreamweaver CS3.

If you don’t have Time Machine installed, you can also replace the Site Prefs and Dreamweaver CS4 Prefs files using a recent back up (you do have a recent back up don’t you?).

And, if you haven’t found yourself in this situation, be thankful and consider making a backup of your Site Prefs and Dreamweaver CS4 Prefs files and storing them somewhere handy.

As always, feel free to email me with your questions, comments and suggestions. And please follow me on Twitter (DWcourse) for additional Dreamweaver news and tips.

Another problem often experienced by Dreamweaver noobies is:

I’ve updated my site in Dreamweaver and it looks fine when I preview it but after I upload it the changes don’t show up on the site.

1. Let’s eliminate the easiest solution first. Did you refresh your browser window? When you view a page on the web, your browser stores a copy of that page (and it’s dependent files) in it’s cache. Then, if you return to the page, your browser shows you the cached version rather than the “live” version. This speeds up  browsing but also might prevent you from viewing the latest version of your page. Refreshing the browser window by clicking the Refresh button in your browser should guarantee  you’re looking at the current version of the page.
2. Another possibility – if you are viewing the home page of your site through a URL such as www.yourdomain.com – is that you have multiple index files. As you should be aware, servers are set up to display a default page for a directory if no file name is specified in the URL. The default file is usually index.htm, index.html, index.php or something similar. The server can even be configured (and often is) so that any of those file names can be used for the default file. A problem arises when more than one of the possible default files is present.Say, for instance, a file index.htm pre-exists on your server and, when you create your new site, you use index.html (note the “l”) as your default file name. When you upload your site the existing index.htm file will not be overwritten. So when you visit www.yourdomain.com you may continue to see the old index.htm and not your new home page, index.html.The solution is relatively simple, delete the index.htm file on the server OR change your default file to index.htm (remove the “l”) so that when it uploads it will replace the exiting home page.
3. Another possibility is that you have defined your Host Directory incorrectly in your Remote Site definition. If this is the case, when you upload your files they are placed in the wrong directory on the server. So you won’t see the new pages when you visit the site with your browser. More information on defining your site is available in my tutorial, Define Your Site at the Dreamweaver Club forum or in my Let’s Get Started with Dreamweaver mini-course.

As always, feel free to email me with your questions, comments and suggestions. And please follow me on Twitter (DWcourse) for additional Dreamweaver news and tips.

I frequently get questions like this:

My site works fine on my computer but when I upload it the [fill in the blank] are broken.

My first response is one I use to address of lot of issues: Make sure your site is properly defined. It’s critical enough that I wrote a tutorial, Define Your Site, for the Dreamweaver Club forum and also included the information in my Let’s Get Started with Dreamweaver mini-course.

Once that’s out of the way the next thing to do is take a look at the source code of your page and see if any of the links are hard-coded to point to a file on your local computer. If they are, they will point to URLs that look something like this: file:///C/site/test.html. There are a few ways this might happen:

• Your site is defined incorrectly (but we’ve already addressed that)
• You try to link to a file outside your root folder (and don’t let Dreamweaver move it for you when it asks)
• You copy code from a file that hasn’t yet been saved (Dreamweaver uses file:/// links until you save a page for the first time) into another page
• Dreamweaver screws up (it happens but not as often as some folks like to think)

The fix is relatively simple. Once you’re sure you have everything set up correctly, recreate the links. You can find the ones that need fixing by searching the source code for “file:///”

As always, feel free to email me with your questions, comments and suggestions. And please follow me on Twitter (DWcourse) for additional Dreamweaver news and tips.

As I mentioned earlier this week, I’ve been busily working to expand the amount of information we provide here at DWcourse.

Well, after some long hours and late nights, I’m proud to announce the release of Let’s Get Started with Dreamweaver, my introductory mini-course to Dreamweaver.

It’s a FREE 50+ page PDF that walks you step-by-step through the most basic steps you need to master when starting to work with Dreamweaver.

If you’ve been working with Dreamweaver for years, this information is probably old hat to you by now. However, if you’re relatively new to Dreamweaver this mini-course covers everything I wish someone had told me when I first started using DW.

It covers the kinds of things that a lot of people screw up early on, get frustrated with, and then quit before even giving the program a real chance.

Ok, enough with the sales pitch. If you’re interested just go enter your name & email address and I’ll send it over to you.

If you’re already registered for our newsletter you don’t need to sign up again, there’s a copy on its way to your inbox shortly.

Anyway, I really hope this helps and as always, if you have any questions feel free to email me or message me on Twitter.