DHTML Javascript Drop-Down Menu - Compile Properties: FrontPage Support

Compile Properties: FrontPage Support

If you are a FrontPage user you can link your menu into a Shared Border so that you won't have to link it into each page separately.

Note: You should link the menu only to the Bottom Shared Border to make sure that you won't get into Netscape trouble. The reason for this restriction is explained in the last section of this page.

How to use the Bottom Shared Border to display a menu in all pages:

1. Inside FrontPage, check the Bottom Shared Border box in all pages where you want the menu to appear.

(see notes below to understand why you should not choose the top, left or right shared border to insert the menu-linking code)

2. Inside AllWebMenus, go to Tools-> Project Properties > Compile Properties-> FrontPage Support and check the "Support Shared Borders in FrontPage" box.

3. Close your Web in FrontPage so that all compile/link changes take effect.

4. Compile the menu at your WEB's root (not inside your _borders directory).

5. Use the "Link Compiled Menu to Web Page(s)" command to link the menu to your WEB's _borders/bottom.htm file.

Note! The _borders directory is set to be hidden by Frontpage. In order to work with the files in this directory you will need to change a setting in your "Folder Options" of your Windows Explorer, as illustrated below:

clip0020

clip0022

Following the steps above, the menu appears in all pages containing the Bottom shared border.

The exact positioning of the menu is determined by other properties (see paragraph below).

(note: the presence of the menu-linking code inside the Bottom shared border does not necessarily mean that the menu appears in all pages containing the Bottom shared border. You may want some of these pages not to show the menu. To achieve this behaviour, you should compile the menu using the "Element-relative positioning" method on the <Positioning> property and make sure that you do not include the menu-positioning code on these pages. With this way the menu will not appear on the page.)

Why linking the menu to the Bottom Shared Border does not affect the desired position of the menu on the page:

Since the menu floats on the page, its position is not determined by where you place the AllWebMenus menu-linking code (i.e. the code inserted when using the "Link Compiled menu" command). Instead, its position is determined by the <Vertical Distance from Edge> and <Horizontal Distance from Edge> properties, or by the menu-positioning code that you may have inserted at the desired location on page. So, position-wise it does not matter where you place the menu-linking code (where you link the menu). However, for Netscape-specific reasons it does matter that you not move this code from the end of the page! And the only way to achieve this with Shared Borders is to link the menu into the Bottom Shared Border and check the related box in Compile Properties.

For more info on how to achieve exact menu positioning by using the related menu-positioning code you may read the "How Do I Position the menu relative to a page element" section.

Optional Reading - Why choose the Bottom Shared Border only:

IE displays the menu perfectly regardless of which shared border is used.

However, Gecko-based browsers will not do the same. This is why:

This type of browsers do not function properly when NESTED tables are used because they will not render a table until they read the entire table (Firefox is not as flexible as IE on page redraws).

Therefore, it is not a good idea to nest tables like this:

<table>

blah, blah, code, code

</table>

</table

The reason has to do with Netscape taking forever to load the page and other problems. Rather, it is best to stack the tables like this:

<table>

blah, blah, code, code

</table>

<table>

blah, blah, code, code

</table>

When you use shared borders (let's say the TOP shared border), FrontPage converts your pages to table pages to separate the shared border content from your main pages. In FrontPage you will not see the "tables" - but only the content.

However, when you publish the page, FrontPage inserts the following code:

<table border="0" cellpadding="0" cellspacing="0"

width="100"><tr><td>

THIS IS WHERE YOUR TOP SHARED BORDER CONTENT GOES

SO, THIS IS WHERE THE ALLWEBMENUS SECTION IS

</td></tr></table>

<table border="0" cellpadding="0" cellspacing="0"

width="100"><tr>

<td valign="top">

THIS IS YOUR MAIN PAGE CONTENT <p>This is really the body of my page. END

MAIN PAGE

</td></tr></table>

So, as you can see above, the final result is: AllWebMenus section is moved inside a <table> </table> structure and this is where the problem in Netscape begins... It seems that the problem is related to how Netscape interprets unclosed tags. The AllWebMenus script uses tables (<table>), rows and cells (<tr>, <td>) to implement the menu items. While everything is very well declared and very well formatted inside the AllWebMenus script, it seems that Netscape creates problems when there are UNCLOSED table tags prior to the menu call (this is the "nested tables" problem explained above).

Checking the "Support Shared Borders in FrontPage" box takes care of this Netscape inefficiency and allows your menus to display properly in Netscape too.

Note: The menu-linking code is normally inserted at the beginning of the HTML (right after the <BODY> tag). However, due to the incapability of Netscape to support nested tables appropriately (used by the Shared Borders), it is required that you keep the menu-linking code at the very end of the Bottom Shared Border (i.e. right before the </BODY> tag).