Topic Outline for Writing HTML

  1. Browser Support of Graphic Markup

    1. a short history of HTML browsers

      1. Mosaic 0.7 (1993)--graphics can be included with text (though scarcely integrated)
      2. Mosaic 2.0 (Fall 1995)--support for HTML 3.0 tables;
        Netscape 2.0--
        The difference from previous versions of Navigator was remarkable. Tables. Not only did it feature "HTML 3.0" proposed enhancements such as frames and client side imagemaps. It included the first versions of what is three years later still the main attributes of a web browser: Java support, LiveScript (today known as JavaScript), a plug-in api, and encryption technology (SSL) enabling secure transactions over the Internet. (www.dejavu.org)
        IE 2.0--also supports tables. Tables begin to be used for layout. (David Siegel pioneers 1-pixel gif.)
      3. NS3, IE3 (August 1996)--Plugin architecture; NS3 has rollovers; Peter Paul Kroch (www.quirksmode.org/browsers/netscape3.html) praises NS3 as apex of pre-CSS browsers;
        Dejavu says IE 3 was big breakthrough beginning CSS support.
        FutureSplash bought by Macromedia 1996 developed into Flash.
      4. NS4 (June 1997); IE4(Nov 1997)--age of Dynamic HTML, DOM split commences;
        IE4 supports Unicode, better CSS1 support and DOM
      5. IE 5 (March 1999)--IE displaces NS as most used browser
      6. IE6 (Nov 2001)--improved CSS; NS share plummets to less than 10%
      7. Mozilla 1.0 (June 2002)--Unicode and almost all CSS1 and CSS2 supported; new DOM converges with IE 6.0 (breaks with NS4: drops LAYER and breaks many pages using old DOM)
      8. Firefox 1.0 (October 2004)Splits off browser from Composer and Mail and replaces Gecko layout engine with XUL interface--takes extensions.
      9. IE 7 (Beta, XP only: early 2006)--More standards-compliant than IE6.
      10. Firefox 1.5 (May 2006)--FF has very roughly 26% of browser market.
    2. customizing the browser:

      Amazingly, many viewers do not know that they can customize the look of pages in their browser. They can adjust the default settings for font face and size, color of text and background, and the treatment of links. Further, if they tick the "always use ..." line, they will override whatever the writer has specified in this regard. It is a good thing the viewers can do this customizing if they have have limitations of vision, but it would be a serious blow to webpage writers and designers if everyone knew of these options and ticked the "always use my settings" line: then a good bit of their design ingenuity would be blocked out from that viewer's screen. Fortunately for designers, that line by default is not ticked, and people don't know about it, or leave it alone. Note that if you do not specify a font-size, font-face, or colors for your page, the page will be displayed with the default settings for the browser and platforms, or with those set by the viewer. One theory says that that's just fine: let people choose the font, size, and so forth that they are comfortable will; they know better than you what they like. True, but they may not exercise any control over the browser, even that of specifying their preferences.

  2. boxes:

    1. HTML block (and list) elements:

      The elements of HTML ("tags") are containers ("boxes")for content (text, sound clips and animations, images). They are simultaneously units of structure, units of formatting, and units for layout. Browsers have defaults for how to render these boxes, but Cascading Style Sheets take charge of the rendering process by assigning typography, color, and layout features to the boxes. The main box types in HTML are

      • DIV,
      • P,
      • BLOCKQUOTE,
      • LI (LI's are contained in unordered (UL) or ordered (OL) lists)
      • H1, H2, H3,H4, H5, H6 (these are the labels or titles of the component divisions)
      • IMG (not a container, but definitely a box)
      • OBJECT (holds audio and video clips, applets)

      Note that there are no elements NOTE, ABSTRACT, BIBLIOGRAPHY, FOOTNOTE, APPENDIX, STANZA, REFRAIN, CAPTION, PROCEDURE, DISCUSSION, INTRODUCTION or CONCLUSION. [MK 57, 96, c.7] For rendering, boxes can have borders, margins, padding, backgrounds, locations. In addition, you can set the line-height and various other properties of the contents of a box including visibility.

      In early HTML there were three elements that came without a closing tag: (HR, BR, and IMG). Since XML (and thus XHTML) require all elements to be closed, we now add a closing slash at the end of the tag: <IMG SRC=blah width=blah />. Eventually, IMG is supposed to be phased out in favor of OBJECT which does have a closing twin.
    2. borders, backgrounds, margins, padding:[MK 275-87]

      Any box can be given a border (in one of several types: solid (single or double), dotted, dashed, raised, grooved) but the latter are not supported by all browsers out there today. Borders can also be assigned colors and widths.

      Ex: Open a new page in HTMLKit and set up three P's with some random content. Then put a STYLE tag at the top of the page and add these specifications:
      p {border:solid 2px;
         background-color:darkseagreen;
         color:ivory}
      Preview it. Try changing the border-type, width, and background color. Try making it ivory.

      These funky color names come from MK 618-19.

      Margins are space outside of the border; padding is spacing inside the border between it and the contents.

      Try adding some margin space around your P, say, in pixels: margin:20px; that will put the margin all around the P. You can break it down into margin-top, margin-right, etc. to specify them separately. Now add padding to the inside, say, padding:8px; same story about specifying each side if you want to.

      You can't embed a P inside another P, but you can embed a P or another DIV inside a DIV.
      Put your three paragraphs inside a DIV tag. Experiment with the margins and padding of both the DIV and the P to see they interact.

      In addition to colors, you can put an image in the background of a box. Most commonly, that is done with the BODY box, and it is usually done with a smallish image that can be tiled (or repeated) so that it does not take up much bandwidth or time downloading. The key style term is "repeat," which can also be limited just to repeat-x, which repeats the image from left to right, or repeat-y, which repeats it vertically. Quite often, for example, a long, thin gradient image is repeated vertically or horizontally to give the impression of a large, smooth gradient surface. Usually the background scrolls with the page, but "background attachment" can be set to "fixed" so that the text and images appear to slide over the background.

      The background of this page is a very light-weight 40 px square of white; its left and bottom sides have a light blue line along their edges. When the square repeats, they join together to give the look of graph paper. And they are fixed. So you can see the syntax for these options by looking at the style section at the top of the page's source.

    3. size and dimensions:
      Right now, your P's and DIV are being sized and laid out by the browser according to the size of their contents. You can specify dimensions of width and height. You can use either fixed units of measure, especially px, or relative, and if relative, they can be relative to the size of the base font used ("em") or a percentage of the window space. (This is true for the margins and padding too). So you could set the width of a P at 40%, say, and no matter how you resized the screen (or whatever window size somebody is browsing at), the P will take up 40% of the available screen width. People who are worried about filling up a big monitor screen with text wall-to-wall sometimes set a P width of 44em (or so). Since the em is based on the size of the base font, larger fonts will produce wider Ps, but the P will never get bigger than 44em's. This is one of the bases of "liquid" or "scalable" layout.

      nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, qui doLOREM IPSUM, quia DOLOR SIT, AMET, CONSECTETUR, ADIPISCI vELIT, SED quIA NON NUMquam EiUS MODi Tempora INCIDUNT, UT LAbORE ET DOLORE MAGNAm ALIQUAM quaERAT VOLUPTATem.

      nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, qui doLOREM IPSUM, quia DOLOR SIT, AMET, CONSECTETUR, ADIPISCI vELIT, SED quIA NON NUMquam EiUS MODi Tempora INCIDUNT, UT LAbORE ET DOLORE MAGNAm ALIQUAM quaERAT VOLUPTATem.

      We want to limit the size that a box can scale up to so that the design is not shattered and the page begins to require scrolling. For this the max-width property is very useful (and is now supported in IE7). So if we add this specification to the previous DIV (id="biglorem"), we can stop it from going past, say, 700px:

      nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, qui doLOREM IPSUM, quia DOLOR SIT, AMET, CONSECTETUR, ADIPISCI vELIT, SED quIA NON NUMquam EiUS MODi Tempora INCIDUNT, UT LAbORE ET DOLORE MAGNAm ALIQUAM quaERAT VOLUPTATem.

      The whole point of using relative font measures is that people can change the size of the base font on modern browsers quite easily. It is sometimes said that dimensions in pixels are immune to viewer control, but that is true only in IE. It continues to be true in IE-7.

      If you fix the width of a box containing text and also its height, you should provide for a viewer using larger font-size. In this case, the box will not resize, and the text will overflow beyond the box. You can use the overflow attribute in the style sheet to specify that the div should sprout scrollbars if the text overflows, so that someone can at least read it (overflow:auto) or you can suppress the overflowing text with overflow:hidden

      So if we set the green biglorem box's height at 150px, we get this:

      nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, qui doLOREM IPSUM, quia DOLOR SIT, AMET, CONSECTETUR, ADIPISCI vELIT, SED quIA NON NUMquam EiUS MODi Tempora INCIDUNT, UT LAbORE ET DOLORE MAGNAm ALIQUAM quaERAT VOLUPTATem.

    4. inline boxes also:
      Even inline tags like A, B, I, and SPAN are boxes and can be given borders and background colors. comme ça There are actually 4 kinds of boxes: block, inline, list, and hidden. These are the possible values of the attribute display. The crucial difference between block and inline elements is that each block element begins a new line, whereas inline elements, are, well, in line.

      We speak of P and DIV as block elements, and A and SPAN as inlines, but these are just the default values for their display attributes and can be reversed if for some reason you want to do so.

    5. IDs and classes of boxes:[MK 8.3]

      We can think of DIVs, Ps, and LIs as general purpose units of structure for many texts, but we might want to have other units as well--say, notes, captions, footnotes, abstracts, or sidebars. We could petition the W3C standards committee to bring out a new version of HTML with these extra tags added, but the mechanism of stylesheets offers a good substitute: we can define (sub)classes of the general entities (types of P, for example) and assign display properties to just that class. You often see a class="note" attribute with a P tag with style properties like smaller font-size, and also sometimes another class of P "caption" which also has distinctive font properties with its text aligned center.

      It is especially good to keep the specifications of boxes and classes of boxes in the stylesheet area (either in the HEAD or on another page entirely, marking individual occurrences of the class. That way, it is very easy to restyle a document just by changing the specification of the class once in the HEAD (or on a separate style sheet).

      We can set properties of individual boxes by giving them an ID value. Each ID given must be unique for the document and can be anything you want. Then the style sheet refers to the ID with a hash mark in front and assigns it properties.

    6. Three places to put styles: [MK 8.1]
      1. Style setting can be done in line, as a part of the box tag itself, as for example <p style="font-size: 120%; line-height:120%; color:green">. Some HTML conversion programs write style info this way, which makes it very hard to change the style of classes of boxes, or all instances of one box type. It makes most sense with BODY, since there will always be only one BODY tag in a document and the tag will be fairly easy to find.
      2. It can be put in HEAD of the document inside a STYLE tag pair. Then a little different syntax applies (it is not HTML, strictly speaking). The values set here for elements and classes of elements apply to all instances of the element in the document, unless over-ridden by an in-line specification at an individual instance. We say the style specification cascades downward from the top of the document.
      3. It can be put in an external document with the extension .css. This is a handy way to assure that several or all of the documents on a site have the same style specification, and a very convenient way to change the format of all of the documents that call for the style sheet. There are two ways to do this linkage of external stylesheet (see MK). Even if a document links an external, site style sheet, it can over-ride the external sheet with its own document-level specifications, or (as before) with in-line specification. In-line style has the last word; the word before the last is the document-level specification (at the top of the page). This is the "cascading" part of cascading style sheets.
      4. An element may have both a class specification and an individual id, and inherit specifications from both. In fact, an element can have two or more class specifications, but one and only one id. Further, you can give special styles to an element in the context of another element, and the same style can be given to several elements. This quickly gets into more advanced and intricate possibilities beyond the level of this document.
      5. Inheritance: In general, boxes contained in other boxes (the "children" of those boxes) inherit the style specifications from their parents. So if we set font specifications for BODY, they will be inherited by P, LI, BLOCKQUOTE, etc. But styles set for P will not be inherited by BLOCKQUOTE or LI because these cannot be the children of P. (Of course you can put a P inside a BLOCKQUOTE and have much the same effect as if BLOCKQUOTE itself had the style, but if you put text directly inside BLOCKQUOTE, it will not have the styles of P.) [MK 8.2]

  3. Positioning and layout

    1. positioning:
      1. floating:

        By default, boxes are laid out in the order in which they appear in the source (="normal flow order"). But they can be marked float:left or float:right (formerly called align) so that surrounding text will flow down alongside them (not possible in Mosaic 0.7).

        Here is a simple traffic light—three 2em square DIVs each with a different color. Beside it is the complete page that makes it. (These are actual HTML pages loaded into OBJECTS.) Should be an object displayed here Should be an object displayed here


        If we add a single line that floats all DIVs to the left, we get: Should be an object displayed here Should be an object displayed here

        The float:left specification for all DIVs is inherited by all three DIVs of the special classes and applied as the layout engine gets to each one—so, three times, producing the horizontal stack. If the float were "right", the result would be a green-yellow-red horizontal stack in the upper righthand corner of the containing DIV. Note two points about this simple example:

        1. The DIVs, being block elements, hold their shape with no content, just on the strength of the height and width specs given. In-line elements such as SPAN or A with no content would collapse.
        2. We could have used id instead of class for the colors on this page, since each colored DIV occurs only once. But if we want to repeat the figure, or otherwise build upon it, we would have to change to class, since otherwise we would end up with multiple instances of …id="red"… which is highly illegal.
      2. Fixed position
        They can also be pinned down, as it were, at the left top corner. If the left and top dimensions are reckoned from the top and left of the BODY (or other containing box, if the box has one), they are given the style marking position:absolute; if top and left are to be reckoned from the top and left of what their normal position would be in the flow of objects, they are marked position:relative. (See absolute⁄relative demo.) If you want to nail them to the screen so that they don't move (as with the menu for this page), even when the page scrolls, they are marked position:fixed (though the first IE to support "fixed" is IE7). The location in x, y is given in pixels, where top left is 0,0. It is possible in this way to overlap boxes. In that case, the last mentioned one in the source goes on top. z-index is a way of changing this. stacking order.

      Homework:
      Make these two designs each on a new page with three DIVS all positioned absolutely. Hints:
      1. For red-blue: the framed box is 300 pixels wide and 400 high. The value for border is "double"; the colors are "darkred" and "darkblue".
      2. For "CSS": do it in em's, no box dimensions necessary.


    2. CSS templates:
      One popular way of laying out material on a web page is to put it in a set of DIVS and then write style sheet specs for how the DIVs should be displayed. This method is used by blog engines, for example, that let you restyle your blog by changing style sheets. A two or three column display is one way to break up the deadly march text across a large screen. Unfortunately, not all browsers fully and correctly implement the CSS1 and CSS2 standards that these designs are based on, and adding markup to control for browsers variations can complicate the code a bit. In particular, IE has a "standards" mode and a "quirks" mode for older HTML pages; Mozilla Firefox, Safari, and Opera apply just the standards mode. IE is still the browser of the great majority, however, so sometimes peole design templates for it in its quirks mode. Very confusing. Here is a template for a three-column page with a header that already has some colors and text in it, but that is just to show you what you can modify (for starters). It uses a DIV embedded inside another DIV to make the design work cross browsers. The first line makes IE use standards mode, but it will be the same in IE even if it is missing that first line and IE goes into quirks mode. It is easy enough to remove the Banner DIV if you don't want it, or edit its styles, and likewise for the column DIVs.

      This page uses a 2-col menu-right setup. In Firefox, you can read the style sheet for this page, and edit it, if you have the Developer's Extensions installed. If so, pull down the "CSS" menu and select Edit Style. As the name implies, you can tweak at the style right on the spot. Also, this page makes the positions of the top and side DIVs fixed so that they don't scroll with the content part of the page, and making this work in IE is also a little tricky and more advanced than we should get into at this point.

    3. tables:[MK, c.10]

      Support for tables was slow to stabilize across browsers, but it preceded CSS and provided the first means of position control and layout on the page. Many, many pages were and still are laid out in tables with invisible borders. Tables are inherently fairly liquid in that they are self-sizing in columns and cells, but these auto settings can be over-ridden by absolute pixel measurements. Much the same padding and centering properties exist for TDs (cells) as for DIVs. Some people mix tables and divs. Though they essentially do the same things, tables induce one to think in terms of a two-dimensional grid (like magazine or newspaper paste-up) where DIVs lead one to think in terms of layers—two-and-a-half dimensions, as it were.

      Tables are unsurpassed for displaying data in columns and rows. This was their original purpose.

      Here is the same banner and 3 column page layout done in tables. I have set the border attribute of TABLE to 2px, so that you can see the cells and rows. (NOTE: the border property must be set in TABLE; it cannot be set in the style sheet.) Change the attribute to 0 to get rid of the borders. Also, I set cellspacing to 0 because it has a default of 1 or 2 px. Zero out border and cellspacing and you will get the same look at with the DIVs.

    4. frames:[MK, c.11]
      Frames were another fairly early device for partitioning the browser screen into measured, identified boxes, though the boxes in this case are browser windows in their own right that display other webpages. Frames (except for IFRAMES)are simply windows that are held together in an array by a FRAMESET container. An IFRAME (inline frame) is a window that can be placed anywhere on a page. These are useful, for example, if you want to display a page while discussing it. Note that they display the whole page, with scrollbars if necessary. [MK 11.6] The first inserted frame is actually not an IFRAME but an OBJECT: object here

      When the browser sees the FRAMESET tag, it knows that the entire screen space will be divided into discrete windows. The simplest frameset is a set of two frames—one a menu header for the other, or one a left or right menu column for the other. So a simple menu-header frameset would be:

      <frameset rows="22%,*">
    <frame src="tmenu.html" name="topmenu">
    <frame src="main.html" name="mainwin">
 <⁄frameset>

      This entire block could be pasted into a blank page (called, say, headmenu.html) and sent to the iframe coke window (name is "cokewin") by clicking load frameset. If you do click this, you will see that it doesn't look like much, since I have not created the tmenu.html and main.html files yet.

      The 3D ridge is a frameborder, which is there by default. If you want to get rid of the ridge to minimize the difference of windows, you can suppress it by adding frameborder="no" and border=0to the FRAMESET tag. (The border=0 is necessary for IE, though not Firefox.) Of course, if we did this now, we would not be able to see any sign of two windows in the iframe. But after we put some text and backgrounds in main.html and tmenu.html we would be able to see them distinctly.

      The "name" attribute is important on frames so that you can target them for files to load in. In the case at hand, the Coke iframe has the name "cokewin" and when you clicked on load frameset, the link was targetted for "cokewin".

      We can introduce more windows by dividing up one of the frames, that is, by replacing it with a FRAMESET (i.e., FRAMESETs inside FRAMESETs). Here is the 3-column plus banner layout template done in frames. This amounts to taking the previous top-menu design and dividing the lower "mainwin" frame into three by replacing it with a second FRAMESET. This time I have added the attributes to suppress the frameborders to obtain the look of the div and table versions. There is a little cross-browser nastiness on this point: [MK 11.3.1.2] Before you make a regular practice of suppressing frameborders in frames arrays, however, note that the default for frames is to allow the viewer to drag the borders to resize the frame if they wish (so that they can modify your design to a certain degree). This is not possible if there are no borders to catch with the mouse, and it can also be prevented by adding a noresize attribute to a FRAME.

      A Dada Collage in Frames? If frames design runs to wild excess ("playing around with FrontPage"), and diverse pages are loaded into the various frames, we get Teo Spiller's A Nice Page.

      Because pages load into frames, they can be set to reload a new page with the META tag HTTP-EQUIV=REFRESH, so that the frame will appear to spontaneously change its contents, sometimes many times. Heavy use of reloading pages in frames can produce a constantly changing grid of squares some what like certain game shows; a classic example is Vivian Selbo's Vertical Blanking Interval. [MK 13.2.2]

      Homework #2:
      The "Here" links show how to execute the 3 columns plus banner in divs, tables, and frames. Fill out the "3 column large center" CSS Template from HTMLKit with colors and bits of text, and then emulate your page in tables and frames. [Tip: if worst comes to worst, you could make these designs by taking the 3 column plus header templates and hacking off the header, no? ]
    5. secondary windows ('popups'):
      By default, the target of a link opens in the window where the link is —it replaces the page with the link. This could be noted target="_self". We can instead specify some other window for the new page to open in. In common use, this window is called "_blank," though it can also be called other things. In IE6 or 7, the default treatment of "blank" is to open a window with the same dimensions but offset somewhat top and left so that it does not exactly cover the original page (as sometimes happend in the past). (If the window is already open fullscreen, it will only offset from the top.) This can be confusing if you miss the offset and don't realize what has happened. The best clue that it has is that the Back button is disabled on the new window: it has no history. In Mozilla and Firefox, the default is to send _blank to a new tab and switch to it. This window has no back arrow (i.e. arrow is gray). These default behaviors can be changed by the user but perhaps generally are not.

      With a little Javascript, however, we can open sized and otherwise customized windows, and these "pop ups" or secondary windows are opened as instructed by the major browsers (although other treatmeents can be customized). MozDev really opposes secondary windows on usability grounds, but gives some useful Best Practice ideas if you are insistent.

      The "target" attribute is deprecated and is not even included in the XHTML DTD, so XHTML employing it will not validate. The alternative is to use Javascript as follows.

      Sometimes we want to open a smaller window and position it so that it does not merely cover the first page. We use Javascript to do this, and we can select the amount of window decoration we want, including the various Tool, Status, and Location bars and scrollbars. We can also do certain very dubious things this way, such as opening a window that will seize the entire screen canvas without any control apparatus at all. (Browser escape mechanism: F11; or, to kill popup, Alt+F4) We can also write a page that will resize and relocate the window it opens in. Partly because of obnoxious uses of these features by advertisers, some people advise against using secondary windows, which would throw us back to old-time HTML where every link opens in "_self". But the great advantage of secondary windows is that you can both "go" to another page and keep one foot in the original page. "Popup blockers" should not block secondary windows that you open from your pages. Complete and accurate control of secondary windows is one of the marks of the polished Web writer and we will cover it in detail, especially because MK do not.

       

  4. Hypertext

     

    1. HREF links::
      A hypertext is a set of documents (aka "files") linked by HREF links from one document to one or more other documents. The main element with a HREF attribute is A, but HREF does occur with other elements as well (such as LINK, where it is used to load in a style sheet, META, where it is used to automatically change the page being viewed, and AREA, where it links a portion of an image (a hotspot) to another document). All of these do contribute to linking documents into a hypertext.

      HREF may also point to and trigger a Javascript function, but that is another and later kettle of fish.

      Each HREF is given a value which is a URL giving the path to another document, and the HREF is essentially an instruction to load that document into a window for display. This URL can either be relative to the location of the present file or absolute (or "fully qualified"), which gives the full IP address of the targeted document (begins "http:⁄⁄). So a document in the same directory as the present page could be given the relative URL href="sister.html", one in a subdirectory of the present page's directory (say, "fammembers") could be given the relative URL href="fammembers/sister.html">. Both documents could also be referred to by their fully qualified IP address, but it is better to use relative URLs for files on the same machine, so that when you upload or move a hypertext, the relative links will still be good.

      The target of a hypertext HREF link is the whole other document and it is usually loaded with the beginning of the document at the top of the window. You can specify a particular segment of the document that you would rather open on by putting an ID at the beginning of that segment and then linking to it with a hash mark prefacing the ID name. So, if you had put an ID of "sports" in a P of the file sister.html, you could open directly to that point with the URL href="sister.html#sports".

      Note HTML hypertext links are uni-directional and only indicate the documents linked from the present document; they do not indicate the documents linking to the present one. It is possible to make pairs of bidirectional links—this is usually done for footnotes, for instance. And it is also done with a link that says "Back," though of course such a link implies that there is only one way back (i.e., that there is only one document linking to this page).This directionality of HTML links imparts a certain direction of flow in HTML hypertexts, and if you enter a hypertext "downstream" you may never encounter a link taking you upstream.

      Exercises:
      1. on a scratch page in HTMLKit, make a link to your homepage. Make a second link to this section (id="href") of this document that you are reading right now. Test the links in Preview and when they work and save the file as "href_scratch.html" in your subdirectory of the the L drive.
      2. add a link to somebody else's scratch file. Check and save document.

       

    2. indicating link anchors:
      By default since the early days (see Mosaic page above), words that are link anchors are colored blue and underlined; if the anchor links to a document already visited, its color is changed to purple. In addition, when your mouse is over an anchor, the cursor changes to the pointing hand and the URL of the linked document appears at the bottom of the window in the status bar. The blue and underlining may be welcomed by very new users of the Web, but it gets old and is a real design clunker, so people work out other ways of indicating anchors, which most people pick up on fairly quickly. Sometimes people sort out their anchors according to whether they are links to other parts of the same document, other documents on the same site, or remote documents on other machines elsewhere.

      You can get rid of the underlining with the CSS text-decoration:none style added to A. As for example, on the A anchors in the Menu on this page.

      Whole images that are link anchors, if given a border, will have the border turned to blue. By default, these days however, the default for IMG is border="0". The same is true even if the link anchors are just AREAs of the image in an imagemap, but there is no way in standard HTML to draw the borders of the hotspot. It can still be detected by the cursor and status bar indicators.

      There is a use of DIVs called CSSImageMaps that does let you show hot spots—as long as you are content with rectangle-shaped hotspots.

       
    3. hypertext structures:
      Since Ted Nelson first coined the term in 1965, hypertext has been taken to mean "multisequential writing," by which is meant that it is a structure of pages ("nodes") connected by links that can be traversed in more than one way. Many books have some hypertext options in the form of footnotes and cross-references, and indeed the strongest example of a non-hypertext (i.e., monosequential) text is a slide show or Powerpoint presentation which allow only the move "Next." It might be better to change "can be traversed" to "invite being traversed," since books do have a preferred order of reading (to various degrees) but it is very easy to hop around in a book, especially one with a table of contents and an index. Narratives are meant to be read in a certain order and typically do not have indices; encyclopedias are not (and do have indices). Instructional writing is usually ordered from basic (reader completely unfamiliar with subject) to more advanced; blog entries are not, other than time of posting, though a series might represent a developing line of thought, a small journey of discovery, or (with Comments) a thread of discussion.

      So to be hypertext, pages must have more than one link to other pages; otherwise you have a strict linear line of march. One is constantly faced with having to decide which way to go, as in a maze or adventure game, and like these, it is hard to know which way to go, based just on the link word (or words) and information given on the page, partly because you don't know where each of the links leads to in any larger perspective. This may not be frustrating if you are content to wander about, but if you are trying to get somewhere—to obtain some information or win the game—you greatly appreciate being handed some sort of menu or map rather than having to map the network of choices out by trail and error one link at a time. [more about choices below]

      Obviously a menu page with links to several separate paths is only a minimal hypertext and not very maze-like. Imagine a General Prologue to the Canterbury Tales page with links from each of the pilgrim's described to their tales. But it does get mazy if you start cross-linking the tales, so that following the link would take you from one part of one tale to a part of another tale. You might do such a thing if you wanted to highlight and cross-reference certain terms, images, or themes. This is the sort of thing a traditional scholarly edition would do with a footnote which would refer to other texts (though of course not actually take you there). HTML lends itself to the construction of such networks of association and cross reference, where a particular item has not just a single place in a well-ordered hierarchy of concepts but several connections to various things. Note that the procedure of hypertextifying a Canterbury tale would overturn the scholar's careful subordination of notes to main text by creating a hybrid text that jumped from one tale to another. And who is to say that the link the hypereditor made is one that Chaucer had in mind or would endorse?

      Assignment: Hypertextifying a poem.

       

    4. choices and connections:
      When we hover, hesitating over which link to click, we are busily and rapidly constructing predictions about what we will find if we choose a link. We look to the status bar to see the URL of the link, to see whether it will take us to another site entirely, or to get some clue from the file name. It is also possible to give further information to a viewer by adding a "title" attribute to the link, which will pop up a little "tooltip" box when the link is hovered over. Browser support for titles is relatively new and people are just starting to use them. We make use of genre clues when available: links in a wikipedia article are likely to take you to other wikipedia articles that discuss the linked term, just as a link in a hypertext poem may well be a kind of scholarly annotation.

      There does seem to be an element of anxiety over choices that is special to hypertext (and perhaps "Choose your own adventure" books). It increases as the number of links on a page increase, and a few pages with more than four links per page will seem like a large, complex one, even if it ends up being a just a few pages cross-linking each other. Also, though we noted the similarity of pages with links to book pages with cross references and footnotes, there is an important difference, which is that we know the preferred continuation of the present page (the next page!),we know that footnotes are brief side links from the present page that will not take us anywhere further, and we know that the cross reference is points to an association that the writer pushed out of the development of the topic at hand. These conventions establish a hierarchy of pertinence to the present page. We do in fact experience increased anxiety of choice when reading a writer such as Noam Chomsky who writes copious and extensive footnotes, some of which significantly qualify what is said in the main text and amount at times not to something peripheral but a counter argument. Chomsky's readers experience the "I want to stay on track, but I don't want to miss anything important" struggle that raises the anxiety level. These considerations may restrain hypertext writers from linking every possible thing that occurs to them.

      Marie-Laure Ryan quotes Michael Heim's observation that "Hypertext thinking may indeed reveal something about us that is agitated, panicky, or even pathological. As the mind jumps, the psyche gets jumpy or hyper" (Narrative as Virtual Reality, 261). So it may, but the hypertext writer can reduce the viewer's anxiety of choice by providing more information about the link and the structure of the site. Along with this anxiety comes a second one of whether one has seen the whole site. Reading the whole text is strongly inculcated from early on as an intellectual duty and we would like to think we have experienced all that the writer has put there for us to experience. Even when we visit the zoo, which is recreational time and not work for most people, we want maps of the place so that we can see what there is to see. Sometimes the issue is put in terms of the pleasure of merely wandering versus the goal achievement of getting someplace, but the zoo example suggests that we want our time and energies well directed even when wandering. Finally, it is somewhat arrogant to assume that bewilderment is just something viewers have to go through. They will not go through it; they will go away, or, if viewing the site is assigned, they will find numerous reasons to dislike it. One should not overestimate the amount of puzzle solving viewers are willing (or able) to engage in.

      Having chosen to follow a link, we can then see, or try to see, how the new page is a continuation of the previous one. There is almost never a connective word to guide us (e.g., For example ...) since there are often more than one path to the new page. Poeple describe what we get often as "juxtaposition" and of the resulting structures as collage-like. This term needs some clarification. Juxtaposition can refer to asyndeton, which is this placing next to each other with no explicit linking word or phrase. Caesar's famous veni, vidi, vici is the classic example. Or, juxtaposition may refer to placing incongruous and unexpected things together, as for example alphabetical ordering does (election ...electron ...elegance ...element ... elephant...) (though in such cases is grouping reflects the arbitrariness of the linguistic sign and not some intention). Or, juxtaposition can refer, often with the modifier ironic to the placing together of opposite or antagonistic things (the banker-the beggar, peace-war, lies-truth). Ironic juxtapositions are actually easier to make sense of than the incongruous or oblique and tangential ones.

       

    5. scenes of viewing:
      A scene of viewing of a hypertext is analogy to some other, more familiar way of engaging the world. In general, the layout and structure of a page invites (or enables) being viewed in certain ways and not in others. So reading USA Today would be one scene of viewing and would suggest a rapid, scattered skimming and perhaps an occasional flip back to a back page to follow a link. Reading a book would be another, which might fit fairly well over an extended, continuous page (where scrolling would replace page-turning). Marie-Laure Ryan has suggested several other scenes of viewing interactive art that we might apply to one text or another. Among these are travelling, supermarket shopping, viewing a kaleidoscope, and working a jigsaw puzzle. Here are brief discussions and examples:
      1. travelling:Here the site is like territory, links are like roads and clicking them is like travelling over them to the next place. A map which is an imagemap with hotspots linking to "explore further" pages almost inevitably attracts the travelling analogy, and it is invoked in a somewhat more abstract way by Mark Bernstein in Hypertext Gardens, where he breaks down travelling into three types: moving through a highrise office building, wandering the the forest, and strolling through an English garden. This analogy is neutral with respect to how goal-directed the travelling is, and we might distinguish a range of kinds of travelling ranging from "seek and retrieve" of a specific piece of information to wandering about looking to be pleasantly surprised. Marketa Bankova offers us a sort of annotated New York City spots, but couches the site as search for a mysterious "it", imposing a quest game structure on her collection of photographs and vignettes of NYC street scenes, complete with "Go North, Go West" etc. options. But the viewer quickly abandons the adventure game engagement since no progress is made on it in favor of just wandering about from one of Marketa's shots to another.

        On the travelling through territory analogy (one speaks of traversing a network), multiple links on a page become forks in the road, and maps of the network of connections can be very valuable. Lacking maps or helpful signposts, the traveller can become explorer and begin to map the network themselves. But if you provide a map of a site with every node reachable by a single click, then you provide a way to skip the travel and any meaningful sequences that might occur along the way. Sometimes web writers will do this: for example, Larry Albert's Houston Wet:Back to Nature is mainly a documentary in 17 episodes. These are linked from a Remote Control (so that you could go to any of them directly, and within the episodes, there are sequences of upwards of 20 pages displayed first on a numbered time line, so again you could jump to any page directly. However, the first panel of each timeline says Begin, and each panel has an arrow to the right and page number counter, thus indicating relative position and preferred direction. Of course, "Back to Nature" can be read as one long linear narrative—that is, after all, one of the oldest of signfying sequences—and it does not link across episodes.

        The traveller-explorer-tourist is usually quite conscientious about seeing the whole territory, or at least not missing any of the good places.

      2. supermarket shopping:

        On the analogy to supermarket shopping, the site is a display of resources without any over-arching design, links are transportation but not dimensions of meaning, and viewing is a hunt for good objects to gather and enjoy. Sometimes the shopper does not fully view the objects but downloads them or bookmarks them for future viewing. Supermarket sites usually do establish some kinds of relatedness among the wares, sometimes geographical. Mr. Beller's Neighborhood, for example, is a collection of locally authored pieces by diverse hands which are linked to maps of lower Manhattan neighborhoods via hotspots. Similarly, Aka Kurdistan locates narratives of Kurdish individuals over most of the twentieth century both on a timeline and as hotspots on a map of the Near East. There is no cross-linking between the individual pieces, however, or signifying sequences among them, though there are thematic consistencies. Returning to New York City, another annotated map is the very detailed New York Songlines, which covers a great deal of midtown and lower Manhattan in a block-by-block guide where interesting or notable places, shops, buildings, parks, and so forth are described and links given to relevant other sites about them on the Web. This all-text site is a splendid counterpart to the aerial views that are more common.

      3. kaleidoscope:

        Sites resemble kaleidoscopes for Marie-Laure Ryan when they change on each viewing, though viewing is a meaningful configuration. Sites which change in this way make use of randomization routines to pick links from a preset list, though which link you get is not preset. Robin Michal's e-arcades selects a short text from a list of over 392 (now 411:7/30/06) and matches it to one of six or seven backgrounds in one of about eight general topic areas (Media, Internet, Body, Technology, Money, Social Structure, Computers, and Globalization). That is, each topic area has at least five different backgrounds. If you reload a page or return to it, it will come up with a newly selected background from the set of five or so for that topic area. Thus it usually has a different background from the one it had on first reading, providing a different visual context for the text and, in practical terms, making it somewhat difficult to tell whether you have visited this page before. Further, each time you click a link, it will not necessarily open the same page it did the previous time, though the passage it does open will be related in some way to the word(s) you are clicking on. The site thus does not behave like normal hypertext and what you get each time through will be somewhat different from what you got the previous time.

        Michal uses this device to honor the intention and emulate the effect of Walter Benjamin's Arcades Project, which is an unfinished attempt to write the social history of Paris in the nineteenth century. What has come down to us as the Arcades Project in effect is a set of Benjamin's note cards--thousands of them--mainly summarizing and quoting the work of other scholars. These snippets are grouped into about 28 different files but heavily cross-referenced as well. The files are printed one after the other in editions of this "project" but no sustained argument or narrative emerges, though a multitude of novel connections are suggested. Michal makes her own set of snippets from recent commentaries on technological change--a kind of social history of the present. (I have slightly modified Michal's randomizing script and used it to place texts from the Arcades Project with graphic backgrounds of the type Benjamin collected.)

        The previous paragraph was written a few years ago (2003?); Michals has revised the site, making each background a mosaic of 20 thumbnails and a constant-recurring background for the text. The effect is to reduce the different look of the backgrounds in any of the 8 areas and hence the uncertainty of whether the page has been visited. This mutes the impact of any individual thumbnail image; some of the backgrounds in the first version were very striking.

        In order to study Michal's site, I collected all of the "notecards" on several sub-topics into tables so that they may be viewed altogether rather than clicked through one after another. The table biofield collects all of the biological metaphors for technology in the set of snippets. What is gained by this collection, and what is lost? There are 150 of these groups/semantic threads. Put another way, each page may be seen as a point where three or four of these threads intersect.

        Russet Lederman achieves a similar, kaleidoscopic effect in her prize-winning American Views. Though written in Flash, it offers many animated menus of choices of snippets from the lives of three New Yorkers who chose quite different relations to the American landscape, one remaining in New York, one emigrating to North Carolina, and one to the Bay Area. These snippets, which are primarily audio clips of interviews with the individuals, are self-contained in the way that answers are, and constantly shuffled by the menu interfaces to break up narrative sequencing. One of my students likened the interface to that of the digital kiosks and directories in the newer museums—if, to be sure, the menus were constantly re-shuffling. Lederman also mentions Benjamin's Arcades Project and its fragmented, non-linear, montage-like construction.

        Ryan observes that kaleidoscopic sites, because of their shifting combinations, are better for lyrical meanings than narrative or sustained argumentation: they are, she says, associative, thematic and quite tolerant of incongruous juxtapositions, as if, one might say, we are trying out different combinations and sequences without yet committing to a final, best composition. In that sense they engage the viewer as a critic collaborator.

©2004 George L. Dillon
http://courses.washington.edu/hypertxt/engl282/topics.html
Last modified: Wednesday, 14-Jul-2004 00:42:57 PDT