Technical details about mindspill.net

Welcome to the age of online dinosaurs. Thinking back, version 1 probably came into existence in the late 90s and was extinct in the early millenium, replaced by various versions since.

Hm. It seems that most links on this page are dead. Oh well. I’ve updated the page to disable and strike through links to content that I’m no longer maintaining.

Version 5 of mindspill.net

The site is currently on version 5, migrated from v4 in 2011. It is generated with nanoc, having left MODx when it put on weight (in the form of its Revolution release).

Version 4 of mindspill.net

Created in 2006, version 4 of mindspill.net marks the move to the MODx content management system. The technical concepts behind the site - the use of XHTML markup with CSS styling - remain the same as with version 3, but maintaining the site using a content management system is much easier, quicker, more maintainable and more flexible than doing so manually.

For details of version 4’s technical implementation, see the MODx page.

Version 3 of mindspill.net

Created around 2002 I think. This version will probably never be replaced…

Update: It was replaced. Kind of. It became mindspill.net v4 when the content was moved into the MODx content management system to make it easier to maintain. Click here to view mindSpill.net version 3 (update: no longer available)

…It is written as all good web pages should be. The content was marked up using strict XHTML 1.0 and structured to look good with no style sheet applied. The pages start with the title, then the main text, further links, site links and finally various extra info about the site. The order in which these elements were placed is to allow screen readers to read the most important content of the page before any related and additional information (it’s very frustrating to have a screen reader list all of the links in the site before the actual contents of the subject-matter).

The desired layout and appearance of the site is achieved using style sheets. Most layouts can be achieved this way.

See the themes section (update: no longer available) for a collection of the designs that can be applied to the site.

Version 2 of mindspill.net

Created around 2001 I think. The code behind version 2 of the site is a lot simpler than that behind version 1. Click here to view mindSpill.net version 2. (update: no longer available)

Browser compatibilty

The theming of the site is dependent on the use of JavaScript, cookies and style sheets. However, if either or all are not present, then the site will gracefully degrade to give a document that should be viewable on most browsers that support HTML 1.1 and tables. The simplest of which I’ve tried is Lynx.

Site layout

The site now uses server-side includes to construct each page, hence there are a number of templates that are used in each page. The site layout is primarily achieved using tables, which the templates construct around the main contents of each page. The theme design uses style sheets to control the text colour, type and layout but most importamtly the colours and background images of the table data elements. JavaScript is used in each content page to determine the corrent style sheet to link to given the current theme. Additionally, in order to achieve the correct table dimensions, JavaScript is used in the templates to write transparent spacer images to each table data element. A naming convention is used so that a simple reference to the theme name when constructing the source path of the style sheet or image is all that’s needed to completely alter the dimenions of the page.

The templates are organised as follows…

  • open.shtml (update: no longer available) opens the top-most table that defines the header bar along the top of the page to contain the menu items and a main body section in which the contents of each page will sit. This is closed off by it’s partner close.shtml (update: no longer available).
  • open_menu_item.shtml (update: no longer available) is called several times from open.shtml (update: no longer available) to open the table that will hold a menu item. The partner close_menu_item.shtml (update: no longer available) closes the menu item table after the link has been defined.
  • open_footer.shtml and close_footer.shtml (update: no longer available) are responsible for adding the footer text (e.g. The version number, current theme and webmaster email).
  • open_page_date.shtml and close_page_date.shtml (update: no longer available) can be optionally included between the footer shtml includes to add a date to the footer.

Code

As previously mentioned, JavaScript is used in each content page to select the correct style sheet and in the templates to add spacers to the table data elements (<TD>). It does this with document.write statements to write out strings of HTML constructed to incorporate the current theme name, determined by JavaScript that appears in each page before the theme name is required…

  • theme.js (update: no longer available) - Theme (using request parameter and cookie).

    A function setTheme is defined to determine the theme from either the request parameter or the document’s cookie, in that order and depending on whether they exist. The theme name is then stored in the document’s cookie so that the data persists on refresh of the page. If neither a theme request parameter or a cookie exist then the theme defaults to “mindSpill”.

    The details of passing data via URL (i.e. in the request parameter, or the search string to use JavaScript speak) can be found in the description of the selectpage.js script used in version 1, as can the details of cookie handling be found in the description of the theme.js script.

  • remotepassword.js (update: no longer available) - Simple password protection (in a pop-up box, hence “remote” in the filename).

    This simply retrieves the string from the text box (the password), appends “.html” to the end of it and opens the corresponding location in the browser. If the password is incorrect the page will not be found. Note that this is not very secure. The password is not encrypted before transmission and the page, once opened, remains in the browsers history.

Version 1 of mindspill.net

Created in the late 90s I think, probably around 1998. Written in HTML (with CSS) and JavaScript. Click here to view mindSpill.net version 1. (update: no longer available)

The first version of this site had the option of either loading a framed version that relied heavily on JavaScript to implement a flashy menu and a very flexible theming scheme, or, in the event of browser incompatibiliy, it would gracefully degrade to present a simple version of the site that was viewable on nearly anything. Unfortunately the flashy framed version is not compatible with any browsers other than Micro$oft Internet Explorer 5.5 and Netscape 4.7, which is also an indication that it’s not up to standard (in the literal sense of the word - it violated many of the World Wide Web Consortium standards of which IE so arrogantly disregards). Because of this you’ll not be able to see the true interface if you’re using any other browser, a pity because I’m quite pleased with the result.

The reason I implemented version 1 was to teach myself the code neccessary for client-side web programming. Now that I have mastered it my requirements are different. I now want a site that focuses on content rather than it’s delivery, that is easier and quicker to maintain and will not require research into the latest browser DOMs nessesary to keep the code functioning. Hence version 1 has been replaced with a second version that does not use nearly as much JavaScript but is none the less good looking, themed and useful (to me at least!).

Following the description of the code there is a list of bugs and a list of things to do (which is now of course a list of things I had to do).

Browser compatibilty

The code for the themed version of the site is targetted at the browsers I use at home - Netscape 4.7 and Internet Explorer 5.5 (with Mozilla support coming soon (update: I’m obviously no longer adding support to something that no longer exists!)). For cross-browser compatibility the scripts test the document object model (DOM) of the browser. From this the browser vendor and version can be assumed and the function calls altered accordingly. It would be best for the scripts to be completely browser independent by testing each element of the DOM before use (see Netscape’s cross-browser support document). This is on my list of things to do.

It is hard to test the site on all browsers and as such only IE 5+ and NS 4.7 are fully supported by the themed version of the site. Support of more browsers (particularly Mozilla) remains on the list of things to do. However, I have set the pages up so that they can stand alone if desired (non-critical JavaScript, no frames or cookies) and viewing them this way should be ok in any browser. The most basic I’ve tried is Lynx.

Site layout

The site is organised as follows. The index page is defined by index.html, first seen when visiting the site. This provides a link to the themed (DHTML) version and a link to the introductory title page (do not confuse with the index page). It is the themed version for which the majority of code is necessary. If the link to the title page is followed a basic text index is provided for site navigation, and the majority of browser compatibility issues are no longer relevant.

The themed (DHTML) version

The themed version surrounds the pages with an index bar on the left and a title across the top. It consists of several frames. At the top level there are 2 frames, called mainframe and globalframe, the first of which holds the main page content and the second of which is a hidden frame that holds global functions and variables. I’ve tried to move the bulk of the code out of the HTML pages themselves as I like them to define the content rather than its delivery. Hence the bulk of the JavaScript code is defined in .js files and included in the HTML ones where necessary.

After image preloading (performed by loading a preload page into the mainframe), 3 other frames are created in the mainframe frame, called index, title and page. These hold the index (the icons on the left), the page’s title and the page itself. It is perhaps best seen with this diagram.

And now for the code…

  • preload.js (update: no longer available) - Image preloading (using DHTML).

    This script is based on one by Nicolas from javascript-page.com. I have extended it quite a bit but the idea remains the same.

    A page is loaded (into mainframe) that stores all of the images we wish to preload as well as some progress bars (these are created in a complicated table by the function writePreloadTable). Each of these images (including the segments of the progress bars) has an onLoad event associated with them that calls the function countDisplayedImage (or countProgressBar) to keep track of how many images have been loaded. When all images have been loaded the function openPage is called to open the desired page, in my case “frames.html”.

    I’m having some problems getting the timing to work properly in Netscape, probably because of when the events are registered. I’ll sort it out when I have time (although it’s by no means critical and just results a bit less eye candy).

  • writeframeset.js (update: no longer available) - Writing frameset (using DHTML).

    This script defines a function writeFrameset that is called by “frames.html” to contruct a frameset consisting of 3 frames, index, title and page. Values passed to the function determine the size of the frames. This is neccessary to allow different themes to use different frame dimensions (e.g. the text theme requires a larger index frame).

  • theme.js (update: no longer available) - Theme (using cookies and DHTML).

    The theme name is stored in the document’s cookie so that the data persists on refresh of the page. A function setTheme is defined to read and alter the cookie. It is called before any other functions when “global.html” is loaded into the globalframe frame. The cookie is a string consisting of colon-seperated data-value pairs that store the theme name and the cookie’s expiration date, as follows…

    "themeCookie=*theme*; expires=*date*;"

    The indexOf method is called to determine where “themeCookie=” and the colon first occur in the cookie. The substring function is then used to extract the theme name. If one does not exist then the default theme oj is used. The getTime method (from the Date object) is used to get the current time, to which a month is added. This is turned into a string using toGMTString. Finally the cookie is set by constructing a string consisting of the determined theme and date.

    When the theme is to be changed, changeTheme is called with the name of the new theme. This function simply backs up the old theme name (useful when switching themes, see this problem), changes the theme variable to the new theme name, changes the cookie to store it, then calls initialisePreload to load the images required by the new theme.

    A function called themeCSS is defined to link a stylesheet into a page depending on the theme. It is called by each page to override the default theme (which is hard-coded into the HTML of the page).

  • changeimage.js (update: no longer available) - Image rollovers.

    This script is used to change the images in the index when the mouse moves over them. It is a good example of getting around browser object-model differences by contructing a string to represent a command (in this case to change the image). The string is made up of several parts that can be defined differently depending on the browser being used.

    The image is changed by simply setting its src attribute. The script is called by the onMouseOver or onMouseOut events, as you can see if you look at the source of the index (the frame on the left, called index). The code is lengthy because the index document has layers (to allow the scrolling). For an example of the code to use if the image is not in a layer take a look at the source of the about me section (update: no longer available), where my picture is changed when the mouse moves over it. The code used is…

    <A href="#" onmouseover="document.images['me'].src='4goofsmall.jpg'" 
            onmouseout="document.images['me'].src='steph-baby-cut.jpg'">;
<IMG src="steph-baby-cut.jpg" width=200 height=263 name="me" alt="me" border=0></A>

  • scroller.js (update: no longer available) - Item scrolling (using Layers).

    My code is based on that by Morten Wang - read his tutorial for a good description of DHTML-based animation.

    Scrolling is achieved by creating layers in the document (by surrounding every object we wish to move with the <DIV></DIV> tags) and manipulating the position attributes of their style. Like changeimage.js, the script starts by getting around browser object-model differences by constructing strings that will later be used to form commands. For instance, the variables leftPosition and topPosition are defined to hold the names of the position attributes of a layer’s style object (called pixelLeft and pixelTop in IE, and left and top in Netscape and Mozilla).

    The script defines a class Scroller that is instantiated with the “level” of the layer containing the objects to scroll. The “level” is simply a convenient naming convention I’ve adopted to distinguish between layers in a hierarchy - objects at level 0 are defined at the root of the document, those at level 1 are defined in a layer, those at level 2 are defined in a layer within a (level 1) layer, and so on. By defining the index bar’s link images at level 2 I can scroll them individually (by altering their wrapper layer’s style) or collectively (by altering the level 1 layer’s style).

    The use of level numbers is convenient for use with Netscape, as in order to access an embedded layer’s style it requires the name of all layers higher up the heirarchy (IE doesn’t). For instance, Netscape would require…

    document.layers["level1"].document.layers["object1"].style.left = xpos;
document.layers["level1"].document.layers["object1"].style.top = ypos;

    While IE would only need…

    document.all["object1"].style.pixelLeft = xpos;
document.all["object1"].style.pixelTop = ypos;

    To refer to a particular layer I pass its level number, N, to the Scroller class which simply appends “level” onto the beginning to get the name of the layer. If the browser is Netscape a for loop is used to construct a string document.layers[“level1”].document.layers[“level2”]…document.layers[“levelN”] to allow the correct layer to be accessed. Anyway, enough about levels…

    A function called moveLayerTo moves a given layer to a given position by changing the position attributes of the layers style, as shown in the code above. A change in xpos moves the layer horizontally and similarly a change in ypos moves the layer vertically. To create the scrolling, moveLayerTo is continuously called. For instance, to create the vertical scrolling of the link images in the index bar, the scroll arrows have onMouseOver and onMouseOut events associated with them. When the onMouseOver event is triggered (by the mouse moving over the scroll arrow) either the function startScrollingUp or startScrollingDown is called. These functions repetitively call moveLayerTo until either stopScrolling is called or the position constraints have been met. stopScrolling is triggered by the onMouseOut event (when the mouse moves off the scroll arrow) and stops any scrolling that is taking place by setting the desired stopping position of the layer to its current position Similarly, to create the movement of the index items (when the page is first loaded) and the title scrolling, the function scrollItem calls moveLayerTo until the layer has been positioned appropriately (xpos = 0, xpos = 1/2 page width, and ypos = 0 respectively).

  • selectpage.js (update: no longer available) - Page selection (passing data via URL).

    This function uses the URL of the document to hold data that determines the page to open in the page frame. For this, the documents location will be its URL followed by a search string beginning with ? (e.g. “http://mindspill.net/page/page.html?page=../code/code.html”, where in this case the search string is “?page=../code/codeintro.html”). It is usual for the search string to consist of name/value pairs separated by the & character (i.e. “?name1=value1&name2=value2&…”). I only use a single name/value pair as I only need to pass the desired location of the page frame. Calling location.search will return all text from the ? onwards, which can then be manipulated as desired.

    My function first gets the search string, removes the leading ? using the substring method and removes any “escape” formatting using the unescape method (the “escape” format is a worldwide cross-browser string format). The search string is then split as desired. In this case, it’s first split using & to get the name/value pair (e.g. “page=../code/code.html”) and then split again using = to allow the value to be retrieved (e.g. “../code/code.html”), giving me the desired location of the page frame relative to the location of the other pages.

    Note that the only reason I first split using & is because I may use more name/value pairs in the future and so the string may later contain & characters. If that were the case then I’d probably alter this function to be more general and return any name/value pair requested.

  • loadframe.js (update: no longer available) - Delayed frame loading.

    This uses the setTimeout function to delay the loading of a frame. An introduction page is stored in the frame until the desired page is loaded. It was used to load an introduction page before the actual content page appeared, but I no longer use it as I wanted to be able to switch between pages faster.

  • remotepassword.js (update: no longer available) - Simple password protection (in a pop-up box, hence “remote” in the filename).

    This simply retrieves the string from the text box (the password), appends “.html” to the end of it and opens the corresponding location in the browser. If the password is incorrect the page will not be found.

    Note that this is not very secure. The password is not encrypted before transmission and the page, once opened, remains in the browsers history.

Bugs

There are some bugs (or at least behaviour I want to change at some point!)…

  1. Problem: The image preloading does not work properly in Netscape. The progress bars change before the images are preloaded and the page is opened prematurely.

    Solution: Don’t know yet. It seems the image onLoad event is called too many times, the result of which is the images on the preload page being set correctly to the images that must be preloaded, then set straight back again to what they were (i.e. the blank colours). It could also be something to do with preloading the images in a different frame to that containing the images when the page is loaded. Any ideas please email me (update: no longer available).

  2. Problem: When using the v4.7 Netscape browser provided with Mandrake Linux v7.1, the page is not forwarded properly after preloading if the elements of the page already exist in the cache. The problem is something to do with the history of the browser, as if I then click the browser’s back button it works, or if I refresh the page and skip preloading it works!

    Solution: Don’t know yet. Any ideas please email me (update: no longer available).

  1. Problem: For v4.7 Netscape only, if this page (code), the tips page, the links page or the music page is reduced in size so that the contents table at the top of the document wraps the text inside it, then some text on the page resets to the default colour of black. Try making the browser really small and you’ll see what I mean.

    Solution: It must have something to do with the combination of tables, lists and headers, as the code, links and music pages have a similar format in this respect. Hence I suspect it’s yet another Netscape style sheet bug. Any ideas please email me (update: no longer available).

  2. Problem: After changing to the “text” theme, turning text off (by clicking “text off” at the bottom of the index bar) should return to the previous theme. However, after the browser is refreshed the previous theme defaults to “oj”.

Solution: Store the theme information in the document’s cookie or in the search string of the URL (i.e. the request parameter), as the data will be preserved on refresh. See theme.js and selectpage.js.

  1. Problem: When changing themes, subpages are not remembered and their parent pages are loaded instead. For example, if viewing the “tips” page (computing->tips), when the theme is changed the “computing” page will be loaded instead of the “tips” page.

    Solution: ? - I haven’t thought about it yet!

Things to do

There are some things still left to do…

  • Fix the bugs
  • Continue the move to style sheets. For instance, they don’t have much control of tables.
  • Make the themed (DHTML) version of this page compatible with Mozilla (and hopefully NS 6) by accounting for the different document model. This will be done before…
  • Move away from making assumptions about the browser vendor/version. Instead test elements of the document object model before use.
  • Load different arrow images depending on the theme. Presently, an orange arrow is used - fine for the “oj” theme but it looks bad with the “text” theme.

Last modified: 11/10/2012 Tags:

This website is a personal resource. Nothing here is guaranteed correct or complete, so use at your own risk and try not to delete the Internet. -Stephan

Site Info

mindspill.net © Stephan Dale.

Privacy policy

Go to top