|
|
|
Table of Contents
Web Site Map.
| The diagram shows the main links in black between the various pages on this web site. |
| The orange links show javascript feeds to various pages. If javascript is enabled, these pages will be enhanced by extra features. |
| Clicking on the diagram will not enable you to link to other pages. |
| To simplify the diagram, any links between the home page and the pages shown in bright green are not shown, as are links to external sites. A smaller version of this diagram is included at the start of the main pages to let you know where you are. |
|
Web Site Navigation.
The Penrith Ramblers web site is arranged in 2 main sections. The section of interest to fell walkers is navigated using the dark green buttons. A second section giving the 'three Fs', physical features and facilities, of the region, where the walks are held, can be accessed by clicking any of the names located on the picture on the Home page. Once there, use the light blue buttons to move around this section. Moving between the two sections has to be done via the Home page using the magenta button. The 'Web Site Management' page, where you are now, can only be accessed from the Home page. |
|||||||||||||||||||||||||
|
Aim of the Web Site.
Please note that the information on the site is provided in good faith and whilst every effort has been made to ensure that it is accurate, you use it without any warranty of it being complete or error free. Information on the region's facilities in the 'supplementary' section of the web site can change quickly. You may be able to check this information by using the web site links provided. To Top |
|||||||||||||||||||||||||
|
Refresh - to ensure you get the latest web page.
For so-called top speed access to the internet your browser may be set to store web pages after they have been downloaded. Trying to download an up-dated version of the same page now fails, as the browser reproduces the page it had previously downloaded instead. To overcome this, your browser can probably be set up to periodically reload a web page every 2 minutes (say) or whatever other time span you prefer. This is useful for getting the latest news from a site, such as monitoring stock prices. The updates/messages page on this site is not in that category of importance but it could be useful to reload its page to see, if there have been any relevant late changes to a walk before setting out. Another method, which may update a page is to use the 'refresh' or 'reload' button. If a number of buttons show a red insert as soon as you enter the site, it means you have previously visited those pages in the recent past. It has been found that pressing the 'refresh' button does not necessarily delete this past record. It is possible to download software (such as 'CleanCache', which works on a number of browsers) to do this for you. With Mozilla Firefox, selecting 'Clear Private Data Now' on closing the browser, will ensure that pages will be loaded from the internet, next time you connect to it. | |||||||||||||||||||||||||
|
Web Site Manager.
| |||||||||||||||||||||||||
|
Just in case you might be interested: As previously stated, it is the aim of the site to provide an up-to-date walks' programme. Updates will be placed on the site as soon as possible but even so, allow several days. The manager operates single handed and will not be available 24/7. In his role as Membership Secretary, don't hesitate to get in touch, if you require further information on subjects covered on the site, You can also ask for an information pack and application form to join the Ramblers Association. Or you may prefer to join on-line by contacting the Ramblers Association and select 'Join today' and then 'Join on line now'. You can phone the manager on 01768 895328. Alternatively, you can e-mail. Incidentally, though supportive of his namesake's catch phrase, 'KEEP WALKING', the web site manager has no other interest linking him with the company. |
 
|
||||||||||||||||||||||||
|
Placing Messages and Photos on web site.
| |||||||||||||||||||||||||
|
Members can pass on any messages, which they think will be of interest to other ramblers and have them placed on the web site. Also, the web site manager welcomes suitable photographs for display on the 'Penrith Ramblers Photos' page. When submitting a photograph by e-mail or CD, try to rename it with the subject of the picture and, if relevant, the leader and the date. Less convenient but better than nothing, is to send an accompanying text file with the photograph, linking the number on the photograph with the subject matter. If you have close-up shots of people's faces, please check that you have their permission to display the photograph. The site manager reserves the right to choose which photos to display and may crop some to improve presentation. Please bear in mind that photos may need compacting first before being put on the site in order to reduce the download time. If necessary, photographs displayed on the site are compacted using 'jpeg' file format to between 250KB and 300KB of memory with landscape photos having a width of about 1080 pixels and height 810 pixels. Actual values depend on their shape. Portrait photographs will keep the height of 810 pixels with widths less than this. (Photo sizes for the slideshow display are even smaller.) Photographs, which are much smaller than these sizes, will probably appear blurred or blocky, when displayed at the sizes quoted. Messages will be placed on the site when it is convenient for the site manager to do so.. To Top |
|||||||||||||||||||||||||
|
Acknowledgements
| |||||||||||||||||||||||||
|
Several members of the Penrith Ramblers have provided feedback, which has helped to improve the accuracy of information given on the site and reduce the number of typos, grammatical errors, and spelling mistakes. Technical advice in the initial stages was also provided. Thanks go to all those who have made a contribution, with apologies, if subsequent changes to the site have begun to nullify their original efforts. | |||||||||||||||||||||||||
|
Information on extra facilities on the Walks' Programme, Map/Compass Work pages and Slideshow.
| |||||||||||||||||||||||||
|
Since the site was first set up, the Walks' Programme page has been modified, so that those who have javascript enabled should get improved presentation. This includes:
A section dealing with the security issues of using Javascript and how to enable it was added. (Oct 2007) The scripting is based on the DOM (Document Object Model), which many browsers now incorporate, though I.E.7's implementation of CSS is not up to that of the opposition and has meant unwanted compromises have had to be made - see below. No guarantee is made that earlier versions of these browsers will work, in which case surfers should notice no change from before. In order to have the mapping facility enabled without having to scroll the window a long way, it was decided to limit the walks on display to a portion of a selected month's walks, scrollable in its own window. To give reasonable accuracy, four overlapping maps are used to display the position of the walks. Each of them has Penrith located near one of their corners. The pale blue areas give an indication of land roughly over 1500 feet. The maps are too small to add further height bands. To aid locating walks, most main roads are indicated (in brown) and a few minor roads are also shown, (in mustard yellow), mainly in areas where main road access does not exist. The position of the spot indicating the location of a walk can only be approximate as some walks cover quite a distance. The spot might be located at a significant physical feature or between significant features if there is more than one given in the walk-description. In order to make the spot visible when placed on regions of the map of different colour, it both changes colour and blinks. To Top On some walks, only the leader is in possession of a suitable map showing the region of the walk, which is not considered good practice (as the leader could fall off a rock face, for example, with the only map). In order to encourage other ramblers, besides the leader, to take the appropiate OS map(s) for a walk, each of the four maps used to show walk locations have an equivalent area showing the required OS maps spread out appropiately to cover that area. The blinking spot appears on the relevant map(s). Some care has gone into showing where the OS maps overlap, though for clarity, the overlaps may be slightly exagerated in places because of the small scale. Clicking on the notice below the 'Region of Walk' will display the OS map layouts. If a walk is close to a map edge, you may need the adjacent map too. A walk in the Grasmere area could involve up to four maps! With some browsers, such as Opera, you might try using the mapping facility with the enlargment setting at 90%. Except for the smaller scale, the mapping is unaffected and the need to use scroll bars should be less. On the Map/Compass Work page a facility to check out a map reference has been included. This uses the same maps as used on the Walks' Programme page. Because of the small size of the maps, accuracy is nowhere near high enough to check out a 6 digit reference. However it does enable one to check if you have the correct letter code and if eastings and northings are the correct way round, unless of course they are of nearly equal value. It is also possible to find out which 1:25000 O.S. map the grid reference falls on. The facility can be accessed from the section on 'Compass' on the Walk Equipment page. From there, you will need to follow the links - the technical bit - Walks Programme - for those with a knowledge of javascript and CSS.
The scripts referred to here are used by 'walk.html', the Walks' Programme web page on this web site and/or YourGridRef.html. togglemap.js provides most of the javascript coding.
Overcoming browser I.E.'s shortcomings..
To overcome these limitations, each table with a month's walk had to be split so that the header was separated from the body and both sections placed inside 'div' tags. It is now possible to apply height values to the 'div' tags enclosing the table bodies, which then constrain the height of the table bodies inside. The 'display' property with value 'block' together with the 'overflow' property with value 'auto' is also applied to the 'div' tags so that the table body inside becomes scrollable, if the table body is longer than the height set. The set of tables together with their div tags were then enclosed in another div tag, which was needed to set the position of the new header, for each set of month's walks selected. To Top
The grid references used to plot a walk's position are placed in an invisible cell at the end of each row, with an optional 'clickable' cell before this.
To overcome the lack of values for the CSS property 'display' in I.E., the property 'visibility', with values 'visible' and 'hidden', is used to control these cells instead. However the property 'visibility' with value 'hidden' still takes up space, unlike the property 'display' with the value 'none'. Fortunately the cells in the table, which are to be controlled were already at the end of each row, otherwise vacant spaces would have appeared in the tables. However, to accomodate I.E., some other browsers have been forced to display a blank space at the end of the rows, which is visible because the space does not match the background colour. The option of matching the row colours with the background colour and so disguise these extra spaces is not available because the rows alternate in colour slightly. The joining-up of table headers and corresponding scrollable table bodies caused no problems except for I.E. and AOL, which uses I.E. With I.E.7, it was found that if the scrollable table was less than half the length of the full unscrolled table, a gap appeared between the header and the scrollable table body. As the number of rows in the unscrolled table could be as much as 30 (assuming 2 double width rows), the scrollable table has to contain at least 15 rows. It would be better if this was shorter, so that window scrolling is not required as well. (Rather than have a special case for I.E., all browsers now have a scrollable table body of 15 rows.) . To Top
For I.E., the righthand scroll bar of the scrolling table did not appear, even though the scrollable table displayed by I.E. went beyond the bottom of the window. To overcome this problem a blank space is positioned below the lowest position of the scrollable tables, This is applied to all browsers even though it seems it is only necessary for I.E. Because of the (enforced) overlong scrolling table and the blank space below it, two right hand scroll bars are displayed, one for the window and one for the scrollable table.
The 'toggle' switch/button also had to be modified to accomodate I.E.s limitations. The 'toggle' needs to select and then remove the mapping facility on successive clicks. Rather than spend a lot of time working out how to undo all the changes to the DOM, after the mapping facility had been enabled, it was decided instead to reload the existing page. This is fairly quick, as the page will have already been loaded and will be stored in the browser's cache. For all the browsers tested, except for I.E., to reload the page in its unmodified form, it was found sufficient to replace the existing href ="#" with href ="walk.html", the URL of the page. With I.E. it was not only necessary to alter the 'onclick' attribute to onclick = "window.location.reload()" in order to reload the page but it was also necessary to ensure that the function 'enableReturn', which does this, was implemented first before any changes to the DOM of the web page had occured, otherwise a later version of the page rather than the original version was reloaded. Two passes of the function were also needed, which all browsers now undergo.
IE's differences with other browsers, mentioned here, are far from exhaustive. The problem of failing to complete the full download of images from the internet is an unwanted feature that only IE seemingly suffers from. This causes a problem, when displaying slideshow images using IE. (See Incomplete photographs for more information). .
Another difference was encountered when thumbnail images, capable of enlargement, were added to the supplementary section of the web site, which deals with the physical features and facilities of the region. To do this it was necessary to get information on window geometry. This threw up a number of differences between IE and other browsers. Go to the section on window geometry in the section on 'Expanding images' to see a list of the properties involved, IE does not comply with the DOM level 2 event handling model, where an event (such as onclick, onmouseover etc.) is 'captured' by the event handler while providing details of when and where it occured. Instead IE supports event propogation by bubbling, where events bubble up the hierarchy in the iE model. This can lead to memory leaks and a serious loss in performance unless the 'cancelBubble' property of the Event object is set to true by a specially designed event handler. For further information go to the section on event handling in the section on 'Expanding images'. To Top
In Early 2008, most pages were upgraded to use 'Standards mode' rather than 'quirks' mode, which had been used originally to accomodate IE's failure to meet W3C specifications, Now that IE's share of the market is justly falling, many web designers ask why other browsers should be continually put at a disadvantage by IE's non-compliance? Some web designers say that they are now saving a lot of time and effort by not designing extra code to cope with IE's out-dated API (Application Programming Inteface). Those who use IE would only get the basic web page, with no enhancements. It was hoped that the introduction of IE 7 would bring IE more in line with the rest. It has a little but there is still some way to go, as already described. Another example of how it differs from other browsers is its showing of images. Firstly, the first few pixels at the top of an image are omitted. Secondly, it treats images like in-line text, allowing for extensions of letters below the line, such as f, g, j,p,q,y, which is unnecessary. This has meant that the 'Site Plan', for example, cannot be drawn too near its top edge. To Top
In going to 'standards' mode, the mark-up for centring the image of the site map at the top of many pages on the web site had to be rewritten, because using the original mark-up, the map had shifted to the right and the overlaid image of an arrow pointing to the user's place on the site was in the wrong place. Suitable mark-up using classes, 'centredImage1' and 'centredImage2', on the external style sheet, 'walkstyle.css' satisfied all the browsers but IE. To bring IE into line, it was necessary to set the font-size of the body element to 100% and include a setting of 'font-size:16px;' in the 'centredImage1' class, even though no text has been used on the page up to this point! If web designers do decide to cut their losses and design sites for W3C compatible browsers, discrepencies like this can only worsen the look of the layout of IE's web pages, compared to other browsers, The name which appears on a button is given by the 'value' parameter within the 'input' tag. These names had to be kept especially short because I.E., unlike other browsers, added extra padding before and after the name, despite being operated in Standards mode. This caused the name to exceed the width of the button but more alarmingly also caused all the preceding tabs in the same table to be moved to the right and be stretched beyond their defined length, resulting in a very distorted display!
It was found that 'href' parameters of 'a' tags and 'src' parameters of 'image' tags are case sensitive, when read off the web but are not when read off a page stored on the computer. This meant that every working page loaded from the computer, had to be re-tested for missing images or inoperative links when placed on the internet. This was not just an annoying feature of I.E. but other browsers too.
Accuracy of plotting a point. To Top
When plotting points on a map, it is necessary that the points appear in the correct position in relation to the map. Having to introduce corrections for differences in browser operation is best avoided as it would require the use of 'browser sniffing'. To position an element, style="position: relative;" and/or style ="position: absolute;" can be used. It would appear that the default browser settings of 'margin' and 'padding' differ between browsers, because browsers plot points in different positions while using the same code, whichever type of positioning is used. To overcome this,
The positions objects are displayed on the screen differ between browsers and can cause an aesthetic problem. In Netscape the display was originally spoilt by having the map partly cover the tabs on the left of the window, when the window was wide. This problem was cured when 'margin' and 'mapping' were set to zero, as already discussed. A method, originally adopted, of making the map's position move further to the right, the wider the window became was now unnecessary and was dropped. To improve presentation, Opera and I.E. have had adjustments made to their layout.
Scripts are loaded when required, some when the page is loaded, some when the mapping facility is selected, which is done by the function 'enable' when the boolean variable 'mapping' is 'true'. This variable is initially set to 'false' in 'global.js' at window.onload. To Top
Highlighting rows in walks' tables.
Because some of the walks on the walks' programme take up two rows, the highlighter has been designed to highlight both rows in such cases. A row is deemed to be the lower part of a double row if its cell containing the 'time' is empty. Call this the 'test-cell'. In rare cases a walk may not have the time specified and would wrongly be considered part of the entry for the row above. By including a 'non breaking space', in the test-cell, (when updating the walks' programme say), the row is not coupled with the one above. (Without giving full details, using the attribute 'colspan' to join up cells in a row could effect whether two rows were paired up or not. For example, if the test-cell is joined to adjacent cells and the combination is empty, then any following joined-up cells will affect the pairing of rows, depending on whether they have any content or not. If they have content, the rows don't pair up. If they are empty, they do! Correct operation will always occur if the test-cell is isolated from other cells,) The script which does the highlighting is 'highlightRows.js'. The script for striping table rows is a common application of javascript and is labelled 'stripeTables.js'. The moving title to the page is applied using 'positionMessage.js' and 'moveElement.js'. Interchanging walks and walk leaders occurs quite often and involves swapping rows of data in the tables of walks. Fortunately, the rows, containing details of the walks, can be relocated in the Walks Programme tables if required, without having to worry about re-identifying their position. This is because the keyword 'this' has been used rather than 'id' attributes to locate where a row is in a table. Moving the position of the columns in a walks' table is no problem either, as long as the corresponding header titles are moved too. However the actual titles must not be changed, unless appropiate changes are made to the script in 'toggleMap.js', This is because the location of the cell in a row containing the description of a walk, say, is found by locating the corresponding cell in the table header, in this case, the cell with the title 'PROPOSED REGION OF WALK'. Similarly the grid reference is found by first locating the title 'MAP' in the table header.
The format of the walks' table was changed during 2007. Extra columns for height and distance were introduced and all the walk details were placed in one column instead of two, resulting in an extra column overall and hence the need for a revised template for the walks web page. It is practice to name the region of a walk, each time its position is plotted, when the map facility is used. The string containing this information is taken from the walks web page and its new structure means that some strings are so long, that the ends of them get overlaid by the map. To overcome this problem, javascript is used to split any long strings into two, with each substring on a separate line. The font size has also been reduced. To Top
Walks' table print out facility.
Many of the methods used to produce the mapping facility are used to produce the print facility, added to the 'Walks' page. This facility incorporates checkboxes, which provide the ability to select and print out any one month, or more, of the displayed walks' programme. The class 'noprint' has been added to all parts of the walk page, which are not required when the walks' programme is printed, such as the the navigation bars, the site map, etc. Those months not selected are also given the class 'noprint', which is evoked when the programme is printed using @media print{.noprint {display:none;}}. The months selected for printing are assigned the class 'print' which is evoked using @media print{.print {display:block;}}. Because the various browsers and printers in use will vary in how they have been set-up, a note giving suggestions of suitable browser and printer settings has been added. This note needed to incorporate 'new line' and 'carriage return' characters. This was done using regular expressions within a 'pre' tag. The special characters are ignored otherwise. Using this tag also allowed several space characters to be placed together (without them being shunted-up into one) thus giving a better layout. The javascript coding for the print facility is contained in printprog.js. To Top
The technical bit - Slide-show - for those with a knowledge of javascript and CSS.
The main web page referred to here is 'thumbpg.html', which is the Photo display web page but this is supplemented by photointro/largepic0.html, photointro/largepic1.html etc. 'slideShow.js' holds most of the the javascript coding with some in global.js. The basic photo section on 'thumbpg.html', contains a set of small photographs (thumbnails). When any thumbnail is clicked on, HTML is used to load a web page, which contains an enlargement of the thumbnail together with some information about the photograph. For example if the third thumbnail is clicked on, the web page largepic3.html in the folder 'photointro' is loaded. Unfortunately, using HTML,there have to be as many of these 'largepic' web pages as there are photos. The basic principle behind the 'slide-show' is to use javascript (slideShow.js) to load these web pages successively into an iframe, which has been added to the web page containing the thumbnails. With suitably designed HTML pages, the information on them can be used directly. This involves removing all navigation buttons from the tops of the pages and placing them at the bottom. This is because the web page is loaded into an 'iframe' from the top and by adjusting the height of the frame, the navigation buttons are obscured from view. (If a form was used to pass the photo details, as in some slide-show designs, each set of information would have to be copied and made an <option> within in a <select> tag in the form. This can be a chore, when the photos are replaced on a regular basis.) Pressing the 'NEXT' or 'BACK' buttons successively, before each image has been downloaded can cause a back-log of downloads, which need to be completed. To prevent this, special measures have been taken. These include disabling these buttons during the process of checking if the pre-loading of each image has occured and forcing the loading of the 'last good' download, if the selection process has got ahead of the downloading process. Remember, the photographs are not all preloaded at the start, which would produce a long wait but one or two photographs are being preloaded each time a photograph is being viewed. If the viewing times are shorter than the download times, problems could arise. To help the viewer identify where a photograph is located in the slideshow, its number is displayed. Switching between images during a slideshow caused a problem with I.E. in that in some cases a quick flash of the previous image occured before the next image was displayed. A 100 milliseconds delay had been allowed to give time for content to be loaded into an iframe, for opacity changes and for redrawing of iframe borders. However, it would appear that I.E. is slower than other browsers tested in one or other of these operations and so, for I.E. only, the time had to be increased to 350 milliseconds. This means there is a noticeable gap between the display of one image and the next with I.E. Incomplete and spotty photographs.
Unfortunately, the browser 'brontosaurus', Internet Explorer causes problems, which, this time, are beyond the cure of the web designer. This is the incomplete downloading of photographs from the internet, resulting in only the top portion of a photograph being displayed. (No error message is provided when this occurs.) Another fault is the display of small white dots appearing at random in very dark areas of an image The only real cure is to use a browser, which does not do this, such as Opera or Mozilla Firefox, which are free downloads off the internet. If you insist on using I.E. and get a photo without its lower part, then trying to download it again is of no avail, as the browser only takes the faulty photograph from its cache and makes no attempt to download it again. (This also explains why manually operating the slideshow is more smooth once all the photos have been downloaded, as the photos are removed from the cache, rather than being downloaded again.) To get a new download, you need to clean the cache first. Software such as 'CleanCache' will do this for a number of browsers including Internet Explorer. It is a free download off the internet. Alternatively, you will have to delve into I.E. to do this. For further information you can read a document on the subject written by Fourmilab . (Incidentally, the author is not yours truly!) Some of the techniques used in the slide-show are discussed further below.
At any one time only one of two images can be viewed next and (except for the start) only one of these images will not have been seen already. Thus it is only necessary to preload one image at a time before it may be needed. (Obviously, this would not be the case if the photographs were selected randomly.) In normal use, with fast internet connections, the image will have been downloaded fully into the browser's cache while the viewer was looking at the previous photo. However, slow connections can mean that the allotted time for downloading an image may be overrun. Hence a check is made to see if the image has been downloaded before an attempt is made to display it. An array 'imgTag' keeps track of the images. In the design, each member of this array refers to an image and takes on values 0, 1 or 2. The value 0 indicates no attempt to pre-load has been made. Value 1 indicates that pre-loading is underway and value 2 that it has been completed successfully or attempted.
To get this information, the complete property of the image object is used, e.g. preloadImg[picNo].complete. This is false when the image is loading and true when the image is loaded or when the browser has given up trying to load it! Because reading 'preload[picNo].complete' is undefined before the image, picNo, is loaded, it was possible to read the value of 'imgTag[picNo]', which would be equal to 0, instead. At one point it is necessary to delay the attempt to load an image from the browser's cache into the 'iframe shim'. This is necessary to make sure that the image has been completely downloaded into the cache, before any attempt to measure its width is made. A standard method using iteration and setTimeout has been used. The iteration is broken if a download is successful or a time of about 5 seconds is exceeded. Each iteration occurs after a delay of 50 millisecs after which a test using the complete property of the image is made. If the result is false the test is made after a further 50 millisecs and so on until an allotted time (of 5 seconds) runs out or a true result occurs, indicating that the download is complete. The method of getting the content of the iframes depends on the browser. The preferred method is to use the Document Object Model or DOM method, i.e. IframeElement.contentDocument, which is implemented by the latest versions of the browsers Opera, Mozilla and Netscape but not the latest versions of IE, which uses iframeElement.contentWindow.document, while IE 5 uses iframeElement.document. As mentioned above, two iframes are used in the slideshow display. Both are contained in the same <div> tag. If both are full size then one is clearly below the other. However by having only the visible one full size and the invisible one a 1 pixel shim the change in position when switching from one to the other is minimal. The opacity of the iframes is switched from 100% to 0% depending on whether the iframe is full size or a one pixel shim, respectively. Again I.E is lagging behind the other browsers in its implementation of opacity settings and instead of setting the opacity using object.style.opacity=(opacity); implemented by the latest Opera, Netscape and Mozilla Firefox browsers, for I.E. its filter method had to be used, namely, object.style.filter="alpha(opacity=" + opacity +")"; In both cases the opacity was a decimal value between 0 and 1, inclusive. An attempt to fade-in each image was abandoned, for although the function worked successfully with small images, it caused annoying flickering with images nearly the size of the screen. The speed that the browser is able to change the opacity of a large image may have a bearing on this. For reference, the javascript code for a fade effect is included in the file 'global.js' but is not used. It allows the user to set the start and finish opacities, the time for this change to take place and the time to display each opacity increment. Further information may be gleened from the comments in slideShow.js, which contains the javascript coding for the slide-show found on the web page thumbpg.html. The technical bit - Expanding images - for those with a knowledge of javascript and CSS..
The web pages which incorporated the use of 'expanding' images were: eden.html, dales.html, lake.html, pennine.html and howgill.html. These pages are supplementary to the main site. The javascript to do this is magnify.js and global.js. (Because of the large memory needed to download the images, this facility has been temporarily disabled, in order to prevent the site being closed down.by the web host.)
To TopThe process is simple for the user. If javascript is enabled the small photos (thumbnails) will enlarge when clicked on. (Some padding and a border are added once an image is full size, together with a caption and instruction on how to remove the enlarged image) When the mouse-cursor is moved off the enlargement to outside the border (or frame), the enlargement will return to its original thumbnail size. The thumbnail image itself is not enlarged but remains on the web page. Instead a copy of it is enlarged, and this will most often spread over the thumbnail image. Wherever the thumbnail happens to be on the page, the enlarged image will finish with its centre close to the centre of the page.The process of enlargement is done in small steps by changing its size (style.width and style.height) and the position of its top left corner (style.top and style.left) every few millisecs. The time for each step, 'tStep', and the total time of the enlargement process, 'magnifyTime', can be adjusted outside the javascript code in the HTML web pages where the image tags are situated. This is done by setting the values (in millisecs) of 'magnifyTime' and 'tStep' in the attribute onclick = "magnify(this,magnifyTime,tStep); return false;". A minimum value of 'tStep' is about 10. 'magnifyTime' may range from 500 to 1000. The smoothness of the transition depends on having a reasonably high number of steps, (= magnifyTime/tStep), on the size of the image and on the browser used. IE seems to be the least smooth of the browsers tested. If the image is large, then the time to produce each change in the image is likely to exceed the value of 'tStep' The shrinking process uses the same function, 'resize' as for enlarging, Which process occurs is determined by the variable 'direction', which is +1 for enlargement and -1 for shrinkage.
Each image which may be enlarged has the class "inflatableImg". At the time the code is loaded, the code places the notice, "Click to enlarge.", over them all. Because the font may merge into some of the thumbnail images and not be clearly visible, the colour of the font can be adjusted. The colour chosen is taken from the 'alt' attribute of the image, which is then removed. However, this means that if the image is missing and javascript is off, the value of 'alt' appears, where the image should be. Hopefully this should be a rare occurence. At the onset of the enlargement process, the title of the thumbnail is stored and then removed. This is to prevent the possibility of a pop-up with the thumbnail's title and a caption, which is added to the fullsize image, appearing together. This could occur, if the mouse-cursor is placed outside the main image, as it is enlarged, and then placed over the thumbnail image, if this has not been fully covered by the main image. When an image reaches full size, the function 'addLabels' uses DOM scripting to add an instruction above the image. This instruction tells the user how to remove the enlarged image. The position of the instruction should fall on the image border but does tend to vary slightly, (depending on where the thumbnail is on the screen and other variables). A caption, giving information on the subject of the photo, is also added below the image. Because this tends to be longer than the title, this is taken from another attribute, 'name', given to the image. (It may be of interest that using the invalid image attribute 'caption', instead of 'name', worked with the browsers tested.) The caption, the instruction, the padding and the border are all removed from the enlargement at the start of the shrink process. When the shrinking process is finished, the copy of the thumbnail is removed and the 'title' attribute returned to the thumbnail image. The setting up and removing of mouse events is dealt with below. Besides needing to know the size of the element in order to carry out the enlargement process, it is necessary, to know the size of the window, how much the window has been scrolled and how much padding the element has. Out of the browsers tested, IE is again the odd one out, as its methods for finding the last three properties differ from other browsers. This means extra object detection code has to be added for IE. The table below shows the differences, which had to be considered in the coding.
* This is the cascaded style of the element taking into account, global style sheets, inline styles and HTML attributes. For padding on the other sides of the element, replace Left by Right, Top or Bottom. Later browsers of IE are made compatible with earlier versions by omitting the !DOCTYPE tag before the HTML tag at the start of the document. This is known as 'quirks mode' or 'buggy' mode as position and size attributes of the element work incorrectly by including the element's border and padding. In the strict or standards mode, with the tag, the CSS position and size attributes of the element work correctly. To Top
A note on mouse events..
The design uses only one mouse event at a time - 'onclick' to trigger the enlargement process and 'onmouseout' to trigger the shrinking process. Because only one event handler is used for a particular event on a particular object at any one time, DOM 0 event handling techniques can be used. i.e. when enlarging the image, the event handler is 'magnify', the event is 'onclick' and the object is 'img' and when shrinking the image, the event handler is 'setupShrink', the event 'onmouseout' while the object remains 'img'. The changing sequence of mouse events used in the enlarge/shrink process is as follows. After an image has had the mouse clicked on it, so starting its enlargement, all 'onclick' events assigned to images which can be enlarged, are then nullified. This is so that clicking on a second image does not start another enlarge/shrink process before with the first has finished. When a full size image is obtained, the event 'onmouseout' is added, which is assigned to the function 'setupShrink'. As soon as the cursor moves off the image and border, to start the shrinking process, the 'onmouseout' event is nullified. Finally all 'onclick' events are restored when the shrink process is complete, allowing the cycle to start again with another image or even the same image. The addition and removal of events was originally designed with DOM 2 event handling techniques using 'document.addEventListener' and 'document.removeEventListener', a total of 2 lines. IE does not comply with these techniques and a special event handling programme, of over 70 lines, was used to get round the problem. This programme has been placed in 'global.js' but is not now used. Places in the code, 'magnify.js', where DOM 2 techniques and the IE 'hack' were called have been kept but shielded from being read by using /* and */ comment characters. Much of the terminology in the above notes will only be understood by web site designers. If you need more information on the techniques used, you will need to save the source codes and inspect the scripts, In general, comment lines have been added in the scripts to aid understanding,
| |||||||||||||||||||||||||
|
