There are three goals in organizing and naming your files:
You want the resulting filenames and URLs to be easy to type.
You want the filenames to be usable without change on as many different servers as possible, so that you can migrate to the most appropriate server at any time with minimal effort.
You want the filenames to be usable without change on as many different personal computers as possible, so that the responsibility of maintaining the files can be assigned to someone else at any time with minimal effort.
The following rules achieve those goals:
Organize your files into folders, but limit the depth of nesting of folders. In particular, do not create more than six levels of folders for your web files.
Give your files and folders names that are short but understandable.
Filenames and folder names must not include any space characters.
The underscore character ("_") and the hyphen character ("-") are both legal, but both require extra effort to type, and so should generally be avoided.
Capital letters are also legal, but they require extra effort to type, and on some servers, including ww2, are not distinguished from lowercase letters, so either:
use only numerals and lowercase letters, or
keep the case of all letters for the file and folder names on your personal computer exactly matched to their cases in your HTML, including HREF and SRC attribute values.
If you already have filenames and links between them that specify mixed case letters, you need not change them for use on ww2, unless there are two files whose names differ only by the case of one or more letters.
Do not give your folders or subdirectories names that include periods, use only letters or numerals.
File names should have exactly one period (" . "). The filename's "type" or "extension" should be chosen conventionally (e.g, .htm, .html, .jpg, or .gif), because that information may be used so that the browser can properly display the contents.
File and folder names should have no spaces, nor punctuation marks, beyond those discussed above.
There are several issues to attend to when organizing your web files on your hard disk. The first principle is to establish a collection of folders on your hard disk that exactly correspond to the folders for your Web files on the server: identical names, nested within each other in the identical organization. This makes it possible to test your files from your hard disk, by using the Open File choice from your browser's File menu. It will also make it possible for you to effectively test your files using the staging server, which we will discuss in more detail later.
A second principle is to help the browser's cache to provide the greatest possible advantage. You do this by using exactly one copy of each image file. Then, every time it is called up, the browser will know that it already has a copy in its cache, and will not ask the server to send it again. This applies not only to your own image files, but especially also to the collections of image files we maintain on the server for shared use. If your reader has recently seen any of the pages that use an image that you reference, it will already be in the cache the first time it appears on your page. This reduces the load on the server and on the network, while speeding up the display of your page.
We suggest that you create your directory structure according to the following plan:
Create an HTML directory (or folder, we use the two terms interchangably) in a location that is easy to navigate to (e.g., at the top level of your hard disk, or at the top level of your "Documents" folder).
Inside that folder, create a folder for each separate subsite you write web pages for.
The HTML folder corresponds to the "ww2.ohio.edu" folder on the server. Inside the subsite folders, you will create folders and files whose names exactly match those you create inside the corresponding folder on the server.
Also inside your HTML folder, but not inside any of the subsite folders, create a folder called "www".
Inside the "www" folder, create two folders:
One folder called "ougifs"; you will save copies of the older shared image files (GIF and JPEG format) from the server into this folder.
Another folder called "images". This folder will receive your copies of the newer shared image files, to be used.
This will produce a structure on your hard disk that can be diagrammed as illustrated on the left portion of the figure:
The right portion of the figure shows the organization of your files and folders on the servers. A more detailed discussion of using the staging environment for your personal testing is included later in this chapter.
The advantages of organizing your hard disk files as shown on the left are that you can use an identical relative URL to point to any of the shared graphics, whether on your hard drive or on our servers, as discussed below.
There are essentially two kinds of files you will be working with, text files and binary files. The former includes HTML files. Binary files contain any images, sounds, videos, etc., to be displayed.
You have many choices for preparing your text (HTML) files. The simplest is to use a standard word processor on your personal computer and save the result as a text file.
Current versions of Microsoft Word can import and export files in HTML format. This is potentially valuable for publishing documents on the web that are based on documents that already exist as word processor files. The primary difficulty with these word processing programs' HTML capabilities is that they produce Web pages that are fragile. This subject is addressed in some detail here.
You can use any browser to test your web files on your personal computer before making them public. In the File menu, the choice Open File (or Open Location ) will permit you to examine any HTML file you have created, and any files it links to, provided that the links specify URLs that translate correctly on your system. If the scope of your project requires organizing the files into multiple subdirectories (or folders), then you should use relative path names instead of absolute URLs. Examples of relative path names are included in section G, part 2, below.
Some testing of new portions of your web materials will require that the files be placed on the server along with the related files. If there is no link anywhere that leads to your file, you can do this "concealed" testing by just opening the specific URL for your new file, and following the links it contains, to verify that all is well.
If you are testing locally on a computer that is not connected to the network, such as at home, references to images that are on the server but not on your personal computer will fail, even though they would succeed if your page were on the server.
The Front Door servers have been configured to provide for on-line testing of new Web pages and especially of re-organized Web sites. This has been arranged by running two servers: files uploaded to the production server, ww2.ohio.edu, will be seen by the world only with URLs starting with http://www.ohio.edu/; files uploaded to the staging server, wws2.ohio.edu, will be seen with URLs starting with http://wws2.ohio.edu/.
Testing from your hard disk is not possible for pages using the generic e-mail script (see Using Mailto ). Web pages using that feature can only be tested from the server. On-line testing also permits other people to review your pages from their own computers, before you go public with the new pages. This makes it easier to gather feedback about new designs, and therefore will improve the overall quality of your Web site.
Files uploaded to the staging server, wws2, will be displayed with the same URL that your regular files use, except for the substitution of "wws2." instead of "www."
We have prepared separate notes on the procedure for managing the transition from staging to production for a new Web site or a massively revised Web site. For small changes, just upload the files to their production locations, as soon as testing is completed.
The server does not have an infinite amount of disk space. If you keep in mind the fact that part of your audience has only dial-up connections to the internet, and consequently keep your files of reasonable size, you should encounter no problems. Remember that sound and video files are generally quite large, and that modern digital cameras take photos that require major reduction before placing online. Please make a point of removing files that are no longer part of your site. If you run out of disk space, please contact OIT ( firstname.lastname@example.org, or 593-1222) for assistance.
The files that you use during on-line testing should require no modification in order to be placed into production, when the time comes. Just be sure to follow these rules:
All image tag SRC attributes for any images should specify the graphic image file with a relative URL, using "../" as needed. If you have organized your hard disk's Web files as outlined in Part A of this chapter, you will be able to view your pages with the graphics displayed correctly from your hard disk as well as after uploading to the staging server.
All anchor tag HREF attributes for links among your own pages should specify the target with a relative URL, using "../" as needed.
All anchor tag HREF attributes for links to Front Door pages in other subsites should specify the target with an absolute URL, starting with "https://www.ohio.edu/" and including the full path and filename.
All image SRC attributes and all anchor tag HREF attributes for links to other people's pages and images should specify the target with an absolute URL, starting with "http://" or "https://" and including the full path and filename. Those links should be to the production version of their Web site.
When you re-organize a Web site, please do your best to avoid frustrating people who follow links from other sites and from search engines. In particular, it is a good idea to follow these guidelines:
Whenever your new site has a page whose contents correspond closely to those of a page from your old site, make sure that the new page has the same name and is located in the same folder, so that it has the exact same URL as the old page.
Whenever your existing site has a page for which there is no single corresponding page in the new site, create a replacement page, which will have the same name and be located in the same folder, so that it has the exact same URL as the old page, that contains links to your new home page and also to any other pages in your new site whose contents closely correspond to the various parts of the old page.
If you really want to "retire" a URL, create a replacement page such as described in the previous point, with the body containing text warning that it will be removed in the future, and containing a link to the single best new page. You should also use META tags in the HEAD of the page to automatically jump to the new URL (see technical content standard 6, below).
If you decide to re-organize your site in a way that results in an entire second-level subsite going away, please consult with Web Services.
These comments are intended to promote a basic degree of consistent look and feel to Ohio University's presence on the web, while still leaving opportunities for creativity by each pagemaster.
For discussion, we organize the content standards into three groups.
Each official Ohio University Web page contains at least three reciprocal links back to the Ohio University Front Door: one using the signature logo graphic in the header, one using the logo graphic in the footer, and one as part of the copyright notice, as illustrated in the footer of this page and as described in the on-line style guide at https://www.ohio.edu/brand/web/.
Each personal or organizational home page should have a link back to the Ohio University Front Door, and personal home pages should have a link to the individual's department home page, if there is one.
In order to be linked from a Front Door page this reciprocal link must meet the criteria spelled out on the Rules for Student Organization Pages.
For reciprocal links other than the copyright statement and the logo graphic, a text link would be the minimal approach.
Consider including a page of external-to-Ohio University links - a "hotlist" of resources likely to be of interest to people who would explore your pages:
Do not put your hotlist on your home page, but you might well choose to have one link on your home page that points to the hotlist page. Many people viewing your page will be coming in from outside with an interest in what Ohio University has to offer on that subject. We should therefore avoid cluttering our home pages with links to items that they have probably already seen. At the same time, many people within the University are looking for external resources, so having a centralized, departmentally maintained hotlist is a valuable service to provide.
All external hotlist links should be verified by the person responsible for the page's contents, on a regular basis, and corrected as needed. Automated tools can verify that something is there to link to, but cannot verify anything beyond this.
Every page should provide a mechanism to communicate with the web maintainer for that page.
Every page should have at least one external link. Usually that link will point back to the page from which the current page is most likely to have been reached.
Every page should be critically reviewed from Chrome, FireFox, Internet Explorer, and Safari, and any other web browser you can use. This critical review should include at least one Windows-based browser and at least one Macintosh-based browser. You should also adjust your browser window to a variety of widths while looking at your pages.
A more complete discussion of these issues is included in Keeping Web Pages Robust.
When a page becomes obsolete do not immediately delete the old page. Instead, create a modified file of the same name to replace it. The contents of this "replacement page" should state that the page is now obsolete, and provide appropriate guidance to the reader. Have a live link in the file leading to the new page.
You may also choose to include a tag of the following form in the HEAD of your HTML, which will cause the page to automatically transfer to the new URL for those readers whose browsers can support this.
<META HTTP-EQUIV="refresh" CONTENT=" 10 ;URL= newURL ">
The newURL above should be the same as that used for the HREF in the anchor tag, discussed above. The CONTENT number is the duration in seconds before the transfer takes place; it should be long enough for the person to read the page, and it should be long enough for the person to click the browser's "back" button. This "replacement" page should have minimal text and no or minimal graphic images. The TITLE tag should give a clear indication that it is a retired page, so that if it comes up on search engines, people will know not to bother following it.
The following example illustrates such an approach to this situation:
<TITLE>RETIRED PAGE - Information Technology at Ohio University</TITLE>
<META HTTP-EQUIV="refresh" CONTENT="10;URL=https://www.ohio.edu/oit/">
The Information Technology pages have been re-organized. The new home page is:
If your browser does not automatically jump to that page in ten seconds, or if you don't want to wait that long, just choose the link, above, to go there right away.
Whenever possible, use relative path names for links among your own files. This will simplify typing and testing, and will make it easier for you to migrate your department's files to another web server if you decide to do that in the future.
Even though the browser will re-wrap your text for display, you should format your raw HTML files for easy readability.
Avoid lines longer than 80 characters
Place paragraph, horizontal rule, table, table row, and break tags on lines of their own
No line breaks inside URLs (neither for anchor HREF nor for image SRC)
Put tags' keywords consistently in all lowercase letters, or consistently in all uppercase letters
Each HTML file should have a <HEAD> ... </HEAD> section that contains a <TITLE> ... </TITLE> block. The text of the title will be displayed by many browsers, and it is used by a number of automated web search and indexing procedures. Your pages will be easier for people to find through these search engines if you make the title descriptive of the contents, using the appropriate keywords that people who would want to find it might search on, and with no acronyms that have only local meaning.
Linked images: if you have an in-line image that is clickable, and you have adjacent text that is also clickable to get to the same location, then the image and the link text should be part of one anchor tag. For example, HTML such as the following:
<A HREF="http://www.ohio.edu/oit/"><IMG SRC="../www/images/sgar.gif" BORDER=0
ALIGN=MIDDLE ALT=""> Go to the Office of Information Technology Home Page</A>.
will produce the following:
Clicking on the icon functions identically to clicking on the highlighted text of the link.
The keyword-searchable index of Ohio University Web pages, accessible through the "Search" feature on the Front Door, identifies the pages in the search results display by using the text contained within the <TITLE> ... </TITLE> in the head of the page. In order to avoid having different pages appear to your readers to be duplicates, be sure that every page's title is both unique and descriptive.
The keyword-searchable index of Ohio University Web pages, accessible through the "Search" feature on the Front Door, may contain duplicate entries if the same page is referenced in more than one way. This is an issue both in the anchor tag HREFs and also in imagemap data blocks ( see Imagemaps on Front-Door Servers ). This leads to the following rules:
For default, index, or welcome files, which the server will permit you to leave off the end of the URL, always be very careful to consistently include the filename in full, or consistently exclude the filename. Including the filename has the advantage of working correctly while checking files from your hard disk; excluding the filename has the advantage of working even after a change of server.
Because some Web servers are case-sensitive in the path and filename part of the URL, search engines often presume that pages found by following URLs that differ only by case are in fact distinct. Since ww2, wws2, and people2 are not case-sensitive, any case combination will work when browsing pages on those servers; therefore we urge that you consistently use the one that is easiest to achieve.
Each HTML file should have appropriate keywords and description <META> tags in its <HEAD> ... </HEAD> section. These tags should indicate the nature of the content of the page. This is especially important for your home page and any other navigational pages. More details are available in the keywords META tag section of the HTML Tags Summary.
Official pages should be reviewed periodically.
See Technical Issue 9, about <HEAD> and <TITLE> tags.
If you use HTML or graphics from someone else, or base your work on something someone else has done, be sure both to visibly acknowledge that fact and also to seek permission from the original author. This is a legal as well as ethical requirement. Once you have their permission, copy the file to your server, so that your traffic does not load their server, and so that they can be free to modify or remove the original without concern for the impact on you.
If you have a roster of department members, use a consistent format and display each individual's e-mail address as a clickable "mailto" link. If any of the individuals has a personal home page, make their name in the roster a link to their personal home page.
For most of your audience, you can "pre-load" the Subject of the e-mail by specifying the link as shown below:
If you have a roster of students, use a consistent format and display each individual's e-mail address as a clickable "mailto" link. If any of the individuals has a personal home page, make their name in the roster a link to their personal home page.
Special considerations apply to students (including both undergraduate majors and graduate students in the department), because they have the right, under Federal law, to require the University to conceal their presence as students at the University. At any given time, about 100 students at Ohio University have active requests for such privacy. There is a standard form that students fill out and submit to the Registrar's Office, to exercise this right. The Registrar's Office staff then mark that student's records in the SIS system.
Any web-visible roster of students must have a prominently displayed revision date. That revision date must not be changed without confirming that none of the listed students has requested privacy. That confirmation can be done directly using SIS, or indirectly using the people search feature found on many Ohio University pages.
For training in using SIS, contact the Registrar's Office. To use the people search for this purpose, go to the Front Door, https://www.ohio.edu/, click on search icon (magnifying glass) in the upper-right, click in the search box, type the student's name, select "People" instead of "ohio.edu," and click on the "Search" button. If you find the student, all is well. If you don't find the student, remove his or her name from the displayed list unless you can confirm directly with him or her that he or she still wants to be listed.
Another Ohio University web author may want to provide a link into a particular spot within your document. Please consider accommodating requests to provide an anchor tag for them to link to (<A NAME="id"> ... </A>) at specific locations.
Please consider requests from other Ohio University web authors who wish to have links added to your document, pointing to particular items of theirs. If such a request seems unreasonable, please discuss the issues with the requester. Unresolved questions should be brought to the attention of the Web Team.
Do not re-invent the web! Link to central resources.
Do not re-create information that duplicates information provided by others.
Do not re-type anything that is already being published.
See Technical Issue 5, about using multiple browsers to check the appearance of your pages.
See Technical Issue10, about the use of in-line images that are parts of links.
Bullets and other small graphics that are not clickable parts of links they are adjacent to should not be blue, because that is the default color of clickable links in many browsers. Likewise, they should not match any non-default color coded for links in that page.
See Content Issue 4, about the display of department employee rosters.
See Content Issue5, about the display of department student rosters.
Separators: it is better to use horizontal rules (tag <HR>) than short, wide graphics. For variety, you can use the SIZE and WIDTH attributes inside the tag. For example, <HR SIZE=5 WIDTH=100%>, produces the rule below this paragraph:
For large documents:
Include a Table of Contents near the top with internal links down to the various sections.
Use appropriate header tags for the titles of the sections that are important enough to rate Table of Contents entries.
Consider whether or not to provide a "Return to Table of Contents" link every two or three sections.
Depending on the lengths of the individual sections that rate Table of Contents entries, it may be appropriate simply to provide one return link at the end of each section.
Consider whether to split the document among several files, so that each one loads more quickly, or to keep it as one file, so that a single print or save command will permit your user to grab a complete copy.
Use large graphics with care - they slow down the display and may not be accesible to all browsers. Consider placing large graphics on subsidiary pages, rather than on the first page of a group. If you must use large graphics, consider saving them with more aggressive data compression. See also Visual Issue 17.
A number of standard graphics are available on the Front Door servers (through "https://www.ohio.edu/www/"). These are the complete absolute URLs, and as usual we strongly advise that you use relative URLs.
Newer versions of HTML provide options for controlling the colors of background, links, etc. Except as noted here:
Individual browsers are often configured to ignore the color directions in the HTML files, so you cannot count on your colors being used.
Background images that show pale on your monitor may display so darkly on other machines that your text cannot be read.
If you feel you must do something different from the default, you are not likely to encounter any problems by specifying a background color that is lighter than the default.
Please do not specify any TEXT or LINK colors. Reader's become accustomed to the default coloring of their preffered browser and attempting to overwrite that default coloring is incredibly user-unfriendly.
Transparent GIFs are often a nice touch, especially if your site includes pages with more than one background color.
On the web type faces are controlled by the browser.
Use the typewriter (<TT>) and
pre-formatted(<PRE>) tags to force graphical browsers to use a fixed-pitch font. Note: graphical browsers tend to use a smaller-sized font when displaying fixed-pitch fonts. Use <FONT SIZE="+0"> tags inside the <TT> and <PRE> tags to force a readably large display in some browsers.
Use the <STRONG> tag for emphasis
Use the <I> (italic) and <CITE> tags very sparingly
Use the <ADDRESS> tag very sparingly
Use the <FONT SIZE="-n"> tag very sparingly
Use the underline (<U>) tag very sparingly
Do not put large blocks of text in <STRONG> or <B> tags
Do use header tags (<H1>, <H2>, etc.) to define the structure of your document so that the browser can display it appropriately. Avoid header levels 5 and 6, because many browsers display them with a type face that is smaller than the standard size, and is therefore difficult to read.
Do use list structures whenever sensible, and nest lists when appropriate. Feel free to put <BR> or <P> tags within or between list items to force extra white space.
If using a <UL> list structure for a set of links, be sure to force extra white space between lines, so that there is dead-space between the links. You can do that with <BR> or <P> tags; another approach is to have each link end with code such as the following:
... </A><FONT SIZE="+2"> </FONT>
or start with code such as the following:
<FONT SIZE="+2"> </FONT><A HREF= ...
This approach has the advantage of using less space between items, so that more items will be visible at any one time without scrolling.
Be very careful using tables. They provide control over the placement of items on your page and look nice in graphical browsers, but they present major challenges to speaking browsers and hand-held devices.
Any "Go Back" or "Return" link should include or be adjacent to visible text that says where it will take you back to.
A single "larger" graphic, or a pair of them side-by-side is appropriate as a "masthead" at the top of the first screenful of a home page, or, for official pages, immediately below the standard university header. For content-rich pages, such a masthead should be at most 672 pixels wide and at most 200 pixels high. Home pages and other navigation-intensive pages, on the other hand, can reasonably be wider -- up to 760 pixels. If a pair of graphics is used, then for official pages, the one on the left should be the University logo, unless the logo is already at the top left, and the logo should be linked to the Front Door.
A set of terse text links near the top, such as can be found in the upper-left segment of this page, or the alphabet across the top of the Administrative Offices home page.
A set of terse text links near the top, positioned by using TABLE tags, with a Definition List inside each data cell of the table to format the short explanatory text, such as can be found on the Policy home page.
A set of small graphic buttons near the top, such as can be found on the Athens Campus map and tour building pages, such as http://www.ohio.edu/athens/bldgs/arc.html.
In each of these, the link from the text or graphic is directly to the location of interest: they do not function as a table of contents for the page they are on.
For your home page, consider providing a more detailed explanation of what will be found on the pages linked by the primary links. One method is to use a <DL> list structure for the whole page with the <DT> items also being tagged as headers of the appropriate level and being links. For example:
<DT CLASS="H2"><A HREF="alpha.html">Alphabetical Index</A>
<P>Links to pages, sorted alphabetically by page title.</P>
In order for this to work gracefully, the first line of your HTML file should be:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
and the HEAD section should include the following two lines, specifying an appropriate CSS file that defines the "H2" (or H3 or H4) class to have a suitably large and bold face:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
<link rel="stylesheet" type="text/css" media="all" href="subsite.css">
The <DT> items in the main body of the home page may be adorned with a thumbnail graphic.
For quickest loading, use the same thumbnail graphic for each item.
For variety, you may choose different thumbnail graphics for each item, but make sure that
They are all the same size, so that the several headers line up with each other.
That size is reasonably small.
Include HEIGHT and WIDTH attributes inside the <IMG> tag.
An image that is located within an ordinary HREF anchor tag can be clicked to follow the link, but thast link will be followed no matter where within the image your mouse pointer was when you clicked. An image map is a single image that provides multiple links: the result of clicking in the image depends on the precise location of the mouse pointer at the time it was clicked.
Neither people2 nor ww2 are configured to support any server-side imagemaps methods, so if you would like to use imagemaps on either of those servers you must use client-side (browser) imagemaps.
The procedure for preparing the required files is discussed in detail in Imagemaps on Front-Door Servers.
On ww2 and wws2 you can control the access to your Web pages based on Ohio ID. There are two requirements: that the server configurations be correctly adjusted, and that you create and maintain a text file with the required information. Very similar methods work on people2 for personal web pages, as documented separately for that server. For ww2 and wws2, please follow these steps:
Send an e-mail to email@example.com, identifying the subsite that is to be password-protected.
When the servers have been re-configured accordingly, you will be notified by e-mail.
Login with SFTP to wws2, and upload into the subsite a home page (e.g., index.html) and a text file named "ht.access" that has the appropriate content (see example and discussion, below).
Attempt to access the home page at https://wws2.ohio.edu/subsite/ — and observe that you are challenged for your Ohio ID and password.
Give your own personal Ohio ID and password. If your ht.access file grants you access, then you will see the page; if not, then you will be re-challenged.
Repeat the above three steps with ww2 if your subsite is already in production.
Upload your real home page and all other files for that subsite. If this is the initial migration, upload them to wws2; if you are already in production you may choose to use wws2 as a staging server, again, or you may choose to upload the files directly to ww2.
As the list of people who should have access to the pages changes, revise the ht.access file and upload it to ww2 and to wws2.
There are three ways you can specify who has access:
everyone who has an Ohio ID and password (this is approximately 225,000 people, including all prospective students who have formally applied for admission)
those who are on a list of specific Ohio IDs
anyone who is in an "Active Directory group" maintained by OIT (e.g., the group of people who are authorized to update your subsite).
If you use more than one of the three, a person need only match any one (or more) of the specifications to get access.
You may want to copy and paste the text below, or you may just type in the parts you want to use. We recommend that you include the group specification for the subsite pagemasters for your subsite.
#This is a model ht.access file
# To permit everyone with author access to the subsite to see the pages in the subsite,
# uncomment the following line and replace the "subsite" (highlighted red) inside the cn
# value with the actual name of your subsite, in all-lowercase letters:
# Require ldap-group cn=OIT-WEBSVC- subsite -admin,ou=WEBSVC,ou=OIT-AIS,ou=OIT,ou=Ohio,dc=ohio,dc=edu
# To permit everyone with a valid Ohio ID and password to view the pages
# in this subsite, and no one else to see them, uncomment the following line:
# Require valid-user
# To permit specific individuals, and no one else, to view the pages
# in this subsite, uncomment and include one or more lines of the form:
# Require ldap-user user1 user2 user3
# To permit only a specific individual to see a particular file, uncomment and
# include blocks of the following sort:
# <Files "filename.html"> # Require ldap-user user1
# the "ldap-" may be omitted;
# replace each "userN" above with the appropriate Ohio ID;
# multiple users and multiple lines of this form are combined with a logical OR
It is safe to place the ht.access file in the same folder on the server with your published documents, because the web server is configured to refuse to serve any file whose name ends with ".access".
The URL path specification is directly translated from the location and name of the file on the server: for example, a file named "index.html" that is located within the folder named "athens" that is itself located within the folder for the entire site, has the URL:
on the staging server, and will be seen by the world at
If a URL specifies a subdirectory, but has no filename, the ww2 web server is configured at this time to search that subdirectory for the following files, displaying the first one on the list that it finds:
If the server doesn't find any of those default files, it will create an index on its own, listing the files it does find.
As mentioned above, using relative paths for links will reduce your typing now and will make it easier to migrate your web files to another server in the future if you should decide to do so. Let us consider some examples based on the files and folders shown in the following illustration:
Working down from the top, those files would have the following absolute URLs, when seen from the production server:
The simplest case occurs with two files in the same ("parent") folder; in that case, the relative URL is just the name of the other file; for example, a link leading from the second page to the third in the above list could be specified as:
<A HREF="columbus.html">Getting here from Columbus</A>
When the target file is in a folder that is in the same folder as HTML file, the folder name is given first, followed by a slash, and then the filename; for example, a link leading from the first page to the third in the above list could be specified as:
<A HREF="travel/columbus.html">Getting here from Columbus</A>
To link to a file in an outer folder, the relative URL starts with "../"; if the target file is two layers out, then the relative URL starts with "../../"; and so on; for example, a link from the fourth page to the first on the list above could be specified as:
<A HREF="../index.html">Map and Tour Home Page</A>
A more complex situation occurs when we build a relative specification from one page to a "cousin" page; for example, a link from the third page to the fourth on the list above could be specified as:
<A HREF="../parking/index.html">Parking When You Get to Athens</A>
All of the above examples illustrate specifications that are relative to the page containing the HTML in question.
Further commentary and examples may be found in the discussion of Anchor Tags in the HTML I Class materials.