Webpage Coding
Example #6 Testing For Support
The »previous example was optimised for sharing code by breaking it down into a number of separate code sections stored in external files and including within the pages as Server-Side Includes, an advanced and rather useful feature of a web-server.
Although we are only dealing with a simple demonstration example which has absolutely no fancy features at all let us pretend that this example is in fact a page which has all manner of fancy features within it and thus requires CSS, DHTML, JS and cookies to work correctly.
To maintain the standards of 'Graceful Degradation' you cannot simply assume that these will be supported on the client machine. If they aren't then your webpage will fall-over, you need to check carefully!
It is necessary to add a few simple tests that will quietly check that each of these requirements is supported, and if they are not then to at least ensure that the page still behaves sensibly and that the user is informed of the problem.
Support Testing Notes
We can also take advantage of another useful feature of using SSI files, we have parts of the page which if changed will have a global impact on the site as the content is shared to all pages.
So it is with the tests which we wish to add, these are all to be added into
the head.ssi
and header.ssi
sections. Refer to the
previous examples for the source code...
JavaScript Support Test
The first test is a combined test for both JavaScript and ultimately the
CSS as well. This involves the addition of a few lines to the
header.ssi
file as follows: View source code in common.js
<noscript><div id="noscript">Your browser does not support JavaScript or
it has been disabled.<br />Without it you will not be able to view this
site properly, some pages may not work correctly...</div></noscript>
<div id="header">
<h1>Example Webpage</h1>
</div><!--header-->
It uses a function called: 'browserUpgradeWarning()'
included within the common.js
file which has already been
sourced externally. It does nothing fancy**, it simply adds the following
code to the top of the page above the header;
Which renders as:
**Note! This function can also be used to invoke the DHTML and/or cookie support tests; see below...
If JS is unsupported the second part of the call comes into effect the
<noscript>
option. This provides a message to the effect
that JS is not working. What you choose to do is up to you, either warn
the user or direct them to a JS-free, plain-text alternative version of your
website, if such a thing exists!
Without it you will not be able to view this site properly, some pages may not work correctly...
Ok so that's JS tested, but we have just informed the user that they have an old browser - how's that?
CSS Support - Old Browser Check
This requires an addition into the head.ssi
file, we create a
very simple stylesheet called 'nowarn.css' and import it
as follows:
...
<link rel="stylesheet" href="./simpleskel.css" type="text/css" />
<style type="text/css">
@import "/css/nowarn.css";
</style>
...
</head>
Note the different syntax, import rather than link. This takes advantage of the fact that the earlier version 4 browsers (IE4 and NN4) do not understand this notation and thus don't pick up this second stylesheet. (See also: Cross-compatible CSS)
The stylesheet content contains just a single directive; to remove the warning added by the 'browserUpgradeWarning()' function.
div#upgrade {display:none;}
// EOF
Simple and fairly self-explanatory, it also provides an additional test of this basic DHTML functionality; the ability to modify the underlying page CSS after the page has loaded, and support of this particularly useful display property.
Obviously if any part of the proceedings so far fails then one or the other of the two above messages will be displayed alerting the user to the problem.
The remaining tests are less critical and only required if these relevant functionalities are also to be used within the pages.
DHTML Support Testing
Most of this test is implicit within the DHTML functions that are in the
common.js
file. These self-test for DHTML support (based on
object detection not browser detection) and exit without
making any changes if there is a problem. These are detailed within the 'Shared JS Code' page.
However the 'built-in' test does not report failure back to the page in a way that the user can see, if we want to do this then we need to add another simple JS function; dhtmlSupportTest() See source code
We can call this from the existing browserUpgradeWarning() function, dhtmlSupportTest() will simply test the global variable DHTML which is a flag set for DHTML support at the start of the script and if there is a problem it will add the following block above the page header warning the user about the issue.
Cookie Support Testing
The cookie support test is also a simple JavaScript function called cookieSupportTest() and invoked from the browserUpgradeWarning() function. This too is detailed within the 'Shared JS Code' page.
Basically it uses the two built in cookie functions from the
common.js
file to write a value to a cookie and then retrieve it.
If the retrieval is successful then cookies are ok, but if it isn't it adds a message above the page header just as for the previous tests and warnings; thus:
Conclusion
So now we have a page template that can easily be cloned into every other page within your website. It makes the maximum possible use of shared code, nothing is coded twice without a good reason. The page utilises all modern DOM compliant functionality and has full support testing and graceful degradation potential built in to it from the start.
From this point on you can concentrate on the content and style of your pages and website as the structure and layout are now essentially complete. Subsequent changes to these routines will be confined to just a few shared files.
It should be noted that this type of optimised structure also lends itself nicely to automated processing and CGI scripting of dynamic pages that will automatically pick up the 'badging' of your site, this is an idea that will be discussed further in the CGI pages.