FrontPage and HTML

FrontPage HTML. These two words, when used together, have caused more pain and strife for Microsoft and the average FrontPage user than either would care to admit. To be nice, in many ways FrontPage creates its own "flavor" of HTML that, finally, can be controlled with the tools provided by FrontPage 2003.

To understand how FrontPage can now optimize HTML, FrontPage's approach to HTML needs to be understood first. After that, the tools FrontPage 2003 offers to optimize FrontPage HTML can be examined and better understood. We'll do both in this chapter.

With FrontPage 2003, you can reformat existing HTML to a cleaner, more compliant format: An optimize HTML dialog box is now part of your toolset, and FrontPage can also optimize HTML during the publishing process so that the world will never know what program you used to create your Web page.

We'll start with a real-world example. Figures 29.1 and 29.2 show the HTML of a page created in a previous version of FrontPage before and after the page was considerably optimized by FrontPage 2003 through the publishing process.

Figure 29.1. The last 28 lines of a 423 line "older" FrontPage HTML page loaded into FrontPage 2003.

Figure 29.2. The page of HTML from Figure 29.1 after it has been published and optimized by FrontPage 2003. Note that the same page is now only 58 lines long.

In this chapter, we will show you how to get the best possible HTML with FrontPage 2003.

What's Wrong with FrontPage's HTML?

At a quick look, the HTML created by FrontPage seems harmless enough. Any user can quickly enter the Coding view and edit the HTML at will. It looks a lot like the HTML found all around the Net, doesn't it?

In short, FrontPage has three issues surrounding its use of HTML:

• The HTML produced by FrontPage isn't always that good. It has gotten better with each revision of FrontPage and now, Microsoft claims that the code produced by FrontPage 2003 is so clean that it is virtually interchangeable with products like Dreamweaver MX. We've seen nothing in the development of this chapter that would lead us to believe otherwise.

• A great number of legacy issues surround the way FrontPage produces HTML. From multiple tags for the same font to legacy and meta data added with the hover buttons, the "old" FrontPage HTML was much "fatter" than it needed to be.

• Because FrontPage writes HTML on-the-fly based on conditions in the site, it must include a considerable amount of metadata in the HTML.

For the first issue, take heart FrontPage produces considerably better HTML than it ever has before. The other two issues are explored a bit deeper in the sections that follow. FrontPage 2003 offers help for all three of these issues and provides additional tools to further massage and clean up the style of HTML it produces.

If you are having problems eliminating the FrontPage specific HTML, see "Make the FrontPage Specific HTML Go Away" in the "Troubleshooting" section at the end of this chapter.

Legacy Markup Issues

Themes, navigation bars, include files, Web components, and the list goes on: All the tools that add to the HTML from FrontPage need FrontPage to write the HTML. Unlike simple design and markup HTML, FrontPage can't let you edit code associated with these elements because they require specific coding that changes as does the file and Web site.

For example, the addition of a new page to a site with a navigation bar across every header requires the addition of navigational metadata across every single page in the Web.

In order to use the tools described previously, the HTML produced by FrontPage must also contain whatever additional information is needed for these tools to provide the functionality they were implemented for. This information is commonly referred to as metadata.

In short, because a FrontPage Web site holds more than just traditional HTML markup, it makes sense that it will often contain more than just the HTML.

What You See Isn't What It Codes

If you use a FrontPage-specific tool (such as included content) in your FrontPage Web site, the HTML for that tool, as seen in the Coding view, is not the same HTML as is presented when you view your site.

There is no way around this because the core HTML needs to store FrontPage data (such as interactive button content, link bar locations, and so on) so that they can be quickly edited with the click of a button in the Design view. No option exists within FrontPage to turn off this feature because doing so would negate the product's power. If you use a FrontPage tool in the design process, you will need to let FrontPage write the appropriate HTML code as needed.

This is really only an issue if you are going to take HTML content directly from your FrontPage Web content on your desktop and move it to a Web server, circumventing the publishing features available with the product. If you need to do this, we recommend publishing the site from one area of your hard drive to another, allowing FrontPage to produce the optimized HTML that you adapt as needed.

If you are having problems with FrontPage specific HTML and using Site Build It's HTML upload feature, see "Using FrontPage with Site Build It" in the "Troubleshooting" section at the end of this chapter.

For a detailed look at the publishing process, see "Publishing a FrontPage Web Site," p. 299.