HTML Authoring

Cc977532.appen_b(en-us,TechNet.10).gif Cc977532.image-app(en-us,TechNet.10).gif

This section describes some of the problems related to Microsoft Internet Explorer HTML authoring. Troubleshooting topics include:

  • Text does not wrap in text boxes.

  • Background images are not displayed.

  • Internet Explorer is not automatically redirected.

  • Frames are not displayed in Web pages.

  • Permission is denied when scripting across frames.

  • Errors occur when you use Web Folders.

Text does not wrap in text boxes

When you enter text in a text box created by using the <TEXTAREA> tag on a Hypertext Markup Language (HTML) page, the text may not wrap correctly. In this case, the text continues to flow to the right side of the text box without breaking or wrapping. This problem occurs because the HTML page does not contain the parameters that activate text wrapping in a text box.

To wrap text in a text box, use one of the following methods:

  • Use the WRAP attribute of the <TEXTAREA> tag with either the Physical or Virtual value to enable word wrapping.
    For example, you might type the following <TEXTAREA> tag: <TEXTAREA NAME="Name" ROW99S=6 COL99S=40> </TEXTAREA>

  • Insert WRAP=Physical as part of the <TEXTAREA> tag.
    For example, you might type the following <TEXTAREA> tag: <TEXTAREA NAME="Name" ROW99S=6 COL99S=40 WRAP=Physical> </TEXTAREA>

Note When you are typing in the text box, press ENTER to manually insert line breaks, which forces the text to wrap.

Background images are not displayed

Pages created by using the Data Form Wizard by Microsoft Visual InterDev™ may not display background images in Internet Explorer. This problem occurs because cascading style sheet (CSS) tags take precedence over HTML tags. Pages created by using the Data Form Wizard reference a CSS; the CSS has a tag for the background image of Transparent, which overrides any value in the body tag of the Active Server Page (.asp) file.

Cc977532.prcarrow(en-us,TechNet.10).gif To display background images

  • Delete the background: transparent line from the BODY property of the CSS.

Internet Explorer browser is not automatically redirected

When you load a Web page that contains the <meta http-equiv="refresh"...> HTML tag, the browser may not automatically be redirected to another Web page. This problem may occur for one of the following reasons:

  • The author of the page did not place the <meta http-equiv="refresh­...> tag in the <HEAD> section of the HTML source code.

  • The syntax of the <meta http-equiv="refresh"...> HTML tag is incorrect.

To resolve this problem, update the Web page by using the appropriate method:

  • If the <META> tag is not located in the <HEAD> section
    Modify the HTML source code to place the <META> tag in the <HEAD> section of the Web page. This may require adding the <HEAD> and </HEAD> tags to the Web page.

  • If the syntax of the <META> tag is incorrect
    Modify the HTML source code to correct the syntax of the <META> tag. For example, a <META> tag might look like this: <meta http-equiv="refresh" content=" n ;url=https://www.domain.com/ pagename.htm">
    The n is the number of seconds the browser program pauses before loading the new Web page.

Frames are not displayed in Web pages

When you are using Internet Explorer to view a Web page, a blank page may appear instead of a defined set of frames. If you right-click an empty area of the Web page and then click View Source , the following message may appear:

This document might not display properly because there is a <FRAMESET> within the <BODY> of the document.

This behavior is by design and occurs when the Web author puts the <FRAMESET> tag after the <BODY> tag in the main or "framing" HTML document. All <FRAMESET> tags and underlying instructions should precede any <BODY> tags.

Cc977532.prcarrow(en-us,TechNet.10).gif To display frames on the blank page

  1. Remove the <BODY> tag.

  2. Remove any additional HTML code between the <HEAD> of the document and the <FRAMESET>.

The framing HTML document defines the frame regions that appear in the browser and the documents or objects that initially appear in the frames.

Permission is denied when scripting across frames

If your script code tries to access a script or an object in a different frame, you may see the following script error message:

Permission denied: 'Parent.RemoteFrame.RemoteObject'

Internet Explorer implements cross-frame security. A script or an object in one frame is not allowed to access scripts or objects in another frame when the documents referenced by the frames' SRC attribute specify Web servers in different second-level domains. This corresponds to the domain-name.xxx portion of the full server-name syntax server.domain-name.xxx .

The Internet Explorer Dynamic HTML object model allows a certain subset of safe actions to be scripted. For example, the window.location property of a remote server's frame can be set to allow navigation, but it cannot be scripted to prevent one frame from accessing the contents of another frame. For example, it is valid for a document retrieved from https://test.microsoft.com to manipulate another document retrieved from https://test.microsoft.com. It is not valid for a document retrieved from https://server1.some-domain-name.org to manipulate a document retrieved from https://server2 or https://server3.microsoft.com.

The intention of cross-frame security is to prevent a Web page author from accessing or misusing the trusted objects authored by another Web page author. Only pages hosted in the same domain can be trusted to safely script the contents of a particular page. Cross-frame security should also prevent unwanted communication between documents on opposite sides of a corporate firewall. For more information, visit the MSDN Online Web site.

In order for two documents hosted on the same second-level domain to interact, both documents must set the document.domain property to their shared second-level domain. For example, one document on https://example.microsoft.com could script and access another document on https://test.microsoft.com if both documents used the following line of script code:

<SCRIPT LANGUAGE="VBScript">
document.domain = "microsoft.com"
</SCRIPT>

Given the following FRAMESET:

<FRAMESET COLS="50%, *" FRAMEBORDER=1>
<FRAME SRC="https://server1/server1.html" ID="Server1Frame">
<FRAME SRC="https://server2/server2.html" ID="Server2Frame">
</FRAMESET>

Script in the "Server1Frame" frame is not permitted to access script or objects in the "Server2Frame" frame, and vice versa.

The following sample script code in server1.html causes the "Permission Denied" error, given that RemoteTextBox is an object created on the server2.html document:

<!-- From server1.html -->
<SCRIPT LANGUAGE="VBScript">
Sub CommandButtonLocal_Click()
Parent.Server2Frame.RemoteTextBox.Text = "Changed Text"
'Server2Frame has SRC on different server
end sub
</SCRIPT>

Errors occur when using Web folders

Web Folders enable you to manage files on a Web Distributed Authoring and Versioning (WebDAV) or Web Extender Client (WEC) server by using the familiar Windows Explorer or My Computer interface. WebDAV is an extension of the Hypertext Transfer Protocol (HTTP) that defines how basic file functions-such as copy, move, delete, and create-are performed by using HTTP. WEC is a Microsoft FrontPage protocol that is used for Web publishing.

The following sections describe errors that may occur when you use Web Folders with Internet Explorer.

The site is not available or not publishable

If you add a Web Folder for a site that is not available or not publishable (for example, FrontPage Extensions is installed but Authoring is disabled), you receive the following error message:

Cannot connect to the Web server https:// <server>/<folder> . The server could not be located, or may be too busy to respond. Please check your typing or check to make sure the Web server is available. For details, see c:\<windows>\TEMP\wecerr.txt.

To resolve this problem, use Internet Explorer to verify that the server is available. If you can open the server in Internet Explorer, contact the server administrator to request that publishing be enabled.

You do not have rights to view or modify files

If you add a Web Folder for a site that is publishable (for example, FrontPage Server Extensions are present and authoring is enabled) but you do not have rights to view or modify files, you are prompted for your user name and password and you receive the following error message:

You do not have permission to access this Web Folder location.

To resolve this problem, contact your server administrator to grant you the necessary permissions.

You specified a non-HTTP URL

If you specify a non-HTTP Internet address (URL) when you add a Web Folder by using the Add Web Folder wizard, you receive the following error message:

The location you have entered is not an HTTP URL. Web Folder locations must be HTTP URL's which point to a folder on a Web server.

To resolve this problem, specify a valid HTTP URL (for example, https:// server/folder ). Note that you can specify server/folder, and Web Folders automatically tries to open https:// server/folder . But specifying a non-HTTP URL (for example, ftp:// server/folder ) results in the above error message.

You specified a folder that does not exist or a protocol that is not supported

If any non-specific error occurs when you try to open a Web Folder, you receive the following prompt to browse to the URL:

Internet Explorer could not open https:// <server>/<folder> as a Web Folder. Would you like to see its default view instead?

To cancel the operation, click No . If you click Yes , Internet Explorer tries to open the Web site. If Internet Explorer is unable to open the Web site, you may have specified a folder on a publishable server that does not exist. If Internet Explorer is able to open the Web site, you may have specified a protocol that is not supported by Web Folders. For example, if you are trying to open a Web Folder by clicking Open on the Internet Explorer File menu and you specify a protocol that is not supported (for example ftp:// or file://), you receive this error message.