Monthly Archives: November 2005

JavaScript: popup messages

With the recent batch of changes to the site, I've introduced a number of my new JavaScript files to the domain. I feel that they're too good to be kept to myself, and as such, they're released under the GPL. The first one I'm going to talk about is the popup message JavaScript, which replaces the standard browser message popup with a custom XHTML one.

A JavaScript popup message in use on drboblog.Now I'm not usually one to replace browser features, as I believe that the browser and the web page should be kept separate, much as the structure and the presentation should be kept separate. However, when it comes to browser message popups, there really is no alternative but to replace them. They're ugly, unskinnable, and can really ruin what would otherwise be a good page.

So to replace the browser popup windows, I've written a Javascript file. It has functions for creating, controlling, and controlledly-detonating custom XHTML message popups, and replaces the standard browser window.alert("message"); function when included in the page. When activated, it disables all the links and forms in the page below it, and re-enables them when dismissed.

The code is pretty simple, and most of it is just bulk to generate and manipulate elements in the DOM, so it doesn't need explaining. However, I feel the usage of the code does require some explanation, and presents a nice opportunity for another example page.

To begin with, you must include my standard JavaScript library file, which is also available under the GNU GPL. This is accomplished using the following XHTML in the <head> tag of your page:

<script type="text/javascript" src="http://tecnocode.co.uk/sources/client/general.js" />

The next step is obviously to include the popup message JavaScript itself, which I would appreciate if you left in its original form, but since that's not a requirement of the license, you don't have to: :P

<script type="text/javascript" src="http://tecnocode.co.uk/sources/client/popup_message.js" />

This, too goes into the page's <head> element, but after the inclusion of the general library. On my website, I have moved site-specific popup message functions into a separate popup_message_custom.js file and included it, but this is by no means a requirement.

The final inclusion is of the CSS file. This file should obviously be customised to your own tastes and site design, but the default design is pretty neutral. This is included with the following markup (once again in the <head> section):

<link href="http://tecnocode.co.uk/sources/client/popup_message.css" rel="stylesheet" media="all" type="text/css" />

Now we get onto the actual calling of the functions necessary to create a popup message. You can call the following function anywhere you like to create a popup message, but a sensible place to put it would be in the onclick event of a link, or something else:

popup_message("window_title",message);

Here, you would obviously replace window title with the popup message's required title, and message with the message you want, which should be a JavaScript DOM snippet. Alternatively, you can pass a string, but this is messy. You should note that this function always returns false, to facilitate the cancelling of events.

However, in some circumstances, you might not know if the file has been included or not, and in any case, for backwards-compatibility, it is preferable to use the window.alert("message"); function instead of the script-specific function described above:

window.alert("message");

Whilst calling the JavaScript in this manner is backwards-compatible, the title of the message is just "Message", and you cannot pass DOM snippets in — only plain text can be passed as the function parameter.

Now that the details of using it have been cleared up, let's finish off with a slightly more technical description of the JavaScript functions, and the CSS:

Table 1: popup_message.js functions
Function declaration Description
public bool window.alert(string message) The original, unmodified browser popup message creation function, or a reference to popup_message("title",message); if popup_message.js has been included. Always returns false.
public bool popup_message(string window_title, dom_tree|string message) The custom popup message creation function, which creates a whole new element tree, and displays it on the page. Always returns false.
private void hide_popup_message(dom_event event) The function to destroy (remove) a visible popup message. It should not be called by any custom code unless you really know what you're doing.

The CSS is quite simple, and all the classes and IDs generated by the JavaScript already have a rule in the CSS file (although you could have styles for individual popup message IDs, but this is going too far). I have provided a brief explanation of each class, and an image to depict what it is:

Table 2: popup_message.js classes and IDs
Class / ID Description Applicable element(s) Descriptive image
.popup_message The main popup message "window" element. <div> .popup_message
.popup_message_title The title of the popped-up message. <h2> .popup_message_title
.popup_message_message The container for the message. <div> .popup_message_message
.popup_message_button The "OK" button used to dismiss the popup message. <button> .popup_message_button

A final note must be about the files I've provided. If you do use this script (and the CSS), please download it and host it with your website; do not leech my bandwidth! Additionally, please follow the terms of the license — I'm giving you something, and I only ask for a little in return.

Platinum 1.1.0

This notification isn't as prompt as I would've liked, as it completely slipped my mind, but the new version of my Platinum Firefox theme has been released – now compatible with Firefox 1.5. :)

Released a few weeks ago, this new version has fewer bugs, some patched-up colours, and most prominently, support for Firefox 1.5 (and all previously supported versions down to 1.0).

Even though it's at the bottom of the list, and has an appalling rating (I still suspect dishonesty), I hope somebody finds it and likes it – I've had some fun times (and some less-than-fun times) making it, and it should be enjoyed.

More updates, and an apology

As is plainly obvious from the renovated skin, I've made some more updates to my blog.

Due to a rather unfortunate accident which occurred over the weekend, the last version of this site was completely nuked from within – my Fasterfox extension was preloading links in the background, including the "delete" links for my blog posts. Rather...unfortunate.

Because of this, I've moved the schedule forward for this latest version of my blog, and uploaded it. Due to this updated schedule, I'm sure there are some unironed bugs, but they'll get stamped out as fast as possible.

The most prominent new feature would have to be the updated skin, but there is an awful lot of new Javascript in this incarnation, which is half-working, but I'm rather proud of it regardless.

Semantic web design

Semantic design is one of the many buzzwords floating carefree around the internet at the moment. Admittedly, it's not the biggest (that must be Ajax at the moment), but it is quite a good word. However, not many people know what is actually is.

The semantic web design I'm talking about is not part of Tim Berners-Lee's new semantic web, but it's related. The semantic web is an initiative to write new pages in a language based on RDF, which allows computers to extract the meaning from web pages. The semantic web design I'm talking about is the proper use of XHTML tags, to structure a page sanely. However, this also allows computer to "read" web pages, to a certain extent.

All the original HTML tags were created and designed to structure information, not to format it. However, since the explosion of the internet, this border was blurred by masses of ineducated poops, and HTML turned into a pea-soup of a formatting language. The W3C decided that this wasn't good enough, so they created XHTML. It was designed to be similar to HTML, but with all the extraneous formatting tags removed. The markup was semantic, and XML-compliant.

However, even when using XHTML, people somehow find ways to abuse the semantics, and use tags inappropriately. This article is trying to stamp that out.
Let's take a look at some markup for a sample page which has been written by a non-semantically-aware author. Concurrently, we'll look at the same page with good semantics. Both pages validate perfectly, yet the bad example is so much worse than the good one. Why?

Both examples start with the same valid markup - the DOCTYPE and the opening <html> and <head> tags:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-GB">
<head>

After this, it starts to go wrong. The bad example puts bad data into the <title> element:

<title>:) DrBob's amazing page :)</title>

This is not acceptable, as – although nothing strictly semantically incorrect has been done – the two smilie faces (":)") should not be in the title, as they are nothing to do with the page title, and are just confusing — semantics doesn't just cover the usage of tags, it also covers the contents of said tags.

The code should be written as follows; with the smilies removed:

<title>DrBob's amazing page</title>

Following that, some bog-standard code follows. However, the bad example has still managed to mess it up – even the simplest of code can be semantically incorrect:


<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="keywords" content="bad semantics,web design,web development,XHTML,semantic web" />
<meta name="author" content="Philip Withnall" />
<meta name="description" content="A page to teach about how not to do semantics in web design. Woo! I'm such a cool web designer! Pick me! Woo! (@Google: This mad text is all in the name of education.)" />

You'll notice the crazy content in the meta description tag: it's semantically incorrect. In a meta description tag, you should only include data relevant to the description of the page, not (as in this case) a very modest description of self.

Cleaned up, the code is as follows:


<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="keywords" content="good semantics,web design,web development,XHTML,semantic web" />
<meta name="author" content="Philip Withnall" />
<meta name="description" content="A page to teach about how to do semantics in web design." />

The next block of code in the bad example is quite interesting, and gives us an insight into why semantic web design is better:


<style type="text/css">
.title
{
font-size: x-large;
font-weight: bold;
}

h1,h2,h3,h4,h5,h5,address
{
/*Bah! I had to make these display inline to make them display right! Stupid W3C can't get anything correct!*/
display: inline;
}
</style>

We can see that the author's bad semantics have cost him appearances, as his incorrect use of heading tags (see below) meant that his page didn't display properly without CSS "enhancements". Any mildly-competent CSS coder would know that if you're making heading tags display inline, there's something seriously wrong.

Just for comparison, what follows is the CSS for the good example. Most of it can be eliminated or put into inline style attributes, however, as it's just to make the good example render similarly to the bad example:


<style type="text/css">
.italic
{
font-style: italic;
}

.bold
{
font-weight: bold;
}

.large
{
font-size: large;
}

.strikethrough
{
text-decoration: line-through;
}

.float_left
{
float: left;
}

.float_right
{
float: right;
}

.indent
{
padding-left: 20px;
}
</style>

The next block of code is completely correct, and parses fine, but the author of the bad example has made one of the worst (and unfortunely, most common) mistakes related to semantics: he's used a heading tag incorrectly:


</head>
<body>
<div class="title">DrBob's amazing page <h1>lolzorz</h1></div>

Heading tags are supposed to be used to logically structure the document, with logical headings of a short length in a tree-structure. Starting with the primary header tag is of the utmost importance, but the whole title must be in the tag, not just some small (and irrelevant) part of it. Cleaned up, the code is as follows:


</head>
<body>
<h1>DrBob's amazing page</h1>

The next section of text doesn't look too bad, but there are some mistakes, and some more offending with headers:


<div>I live at <address>Buckingham Palace</address> in <strong>England</strong>. Aren't I <h4>lucky</h4>! Whee!</div>
<p>My name is DrBob, and <em>I</em> come from <em>behind you</em>.</p>

The first offense is the encapsulation of text in a <div>. This element is for logically grouping sections of a document for styling or other purposes. It is not designed to contain text; for that, you should use a paragraph element. The next error is the use of the address element. Although its use is debatable, the official W3C HTML specification states that the address element should be used to encapsulate contact information for a web page, or a significant part of a web page, not somebody's postal address, unless it is their preferred contact medium with regards to the web page. Other errors in this section are regarding the use of emphasis and strong elements. These elements are not to be used with the mindset that "it's going to make the text italic", or "it'll make the text bold"! They should be used to signal emphasis on a section of text which would be emphasised if the text was read aloud. Although people would often make text italic or bold when that is applicable, it is probably not applicable in these circumstances, so the effect should be achieved using CSS. The final mistake in this section is the incorrect use of a level-4 heading. It can't be stressed enough that headers are to be used for logical document section titling, and certainly not for text sizing and font choices!

Corrected, the section is much easier to read:


<p>I live at <span class="italic">Buckingham Palace</span> in <span class="bold">England</span>. Aren't I <span class="bold">lucky</span>! Whee!</p>
<p>My name is DrBob, and <span class="italic">I</span> come from <span class="italic">behind you</span>.</p>

The next section is incorrect from the outset, as the author has chosen to indent it all using a blockquote element, instead of styles:


<blockquote>
<!-- Bah! I had to change it from a <p> to a <div> to get it to validate! Oh well. They're the same to me, anyway, because I know best. -->
<div>Look at my wonderful indented text! Aren't I so <h2>good</h2> at <abbr title="HyperText Markup Language">HTML</abbr>!</div>
<p>I know this page is <a href="http://validator.w3.org/check?uri=referer">valid <abbr>XHTML</abbr></a> and uses <a href="http://jigsaw.w3.org/css-validator/?check=referer">valid <acronym>CSS</acronym></a>. Aren't I <strong>so good</strong>!</p>
</blockquote>

The use of the blockquote element is bad, as the blockquote element should be used to denote long quotations, not to indent things.

In this section, there are also more examples of header misuse, and <div> tag misuse. There is also something else, which hasn't been seen before, and that's misuse and confusion over the abbreviation and acronym elements. The abbreviation tag should only (naturally enough) be used for abbreviations, so its use here to explain what "HTML" means is completely incorrect. The other two uses of acronym and abbreviation elements are also incorrect, as you should always specify a title attribute when using either element (and the author has used the wrong tag for HTML again).

Here's a clean version of this section:


<div class="indent">
<p>Look at my wonderful indented text! Aren't I so <span class="bold large">good</span> at <acronym title="HyperText Markup Language">HTML</acronym>!</p>
<p>I know this page is <a href="http://validator.w3.org/check?uri=referer">valid <acronym title="eXtensible HyperText Markup Language">XHTML</acronym></a> and uses <a href="http://jigsaw.w3.org/css-validator/?check=referer">valid <acronym title="Cascading StyleSheets">CSS</acronym></a>. Aren't I <span class="bold">so good</span>!</p>
</div>

By now, you'll be getting sick of this author misusing headers, so we'll skip that error in the next section:


<h3>Did you know I'm so good at HTML, I can make <del>text strikethrough</del>? Isn't that cool?!</h3>

Apart from the header misuse, there is only one problem with this section, and that's the incorrect use of the <del> tag. It is supposed to be used to indicate that a web page has been changed, and that the encapsulated content has been removed in the latest version, but this author is incorrectly using it to add a strikethrough effect to his text. (The author has also forgotten to add an <acronym> tag, but this isn't as important.) This is simple to clean up:


<p class="large">Did you know I'm so good at <acronym title="HyperText Markup Language">HTML</acronym>, I can make <span class="strikethrough">text strikethrough</span>? Isn't that cool?!</p>

The final section in our bad example page is also the largest, but only contains a few mistakes repeated many times:


<table border="1" width="100%">
<tr>
<td>
<cite>Here's a recent conversation I had with a friend of mine:</cite>
</td>
<td>
<dl>
<dt>Mark said:</dt>
<dd>So, have you looked into this new <q>semantic markup</q> thing?</dd>
<dt>DrBob said:</dt>
<dd>Hell no! I'm the best coder in the world already!</dd>
<dt>Mark said:</dt>
<dd>Are you sure? It looks like it has benefits.</dd>
<dt>DrBob said:</dt>
<dd>Go away. I hate you.</dd>
</dl>
</td>
</tr>
</table>
</body>
</html>

As you can see, the section contains a conversation log of an interaction between the author and one of his (no longer) friends. The first mistake is a blindingly obviously incorrect usage of a table. Many people have said it many times, and it can't hurt to say it again: tables should be used to display tabular data only, not used to lay out a page! The next mistake is the use of a citation tag in the wrong place. Citation tags should be used to show who a quote came from, and not at all in the manner shown in the example. The remaining mistakes in this section are all misuses of definition elements. The HTML specification defined several elements for use in defining terms. Here, they have been used to format the responses in a chat log, and this is completely wrong — if a computer were to read this page, it would record that "Mark said:" means "So, have you looked into this new semantic markup thing?", among other things.

A final mistake in this section is the incorrect use of a quote tag. As nobody said "semantic markup" (as far as any reader of the page can tell, anyway), it shouldn't be inside a <q> tag. Instead, it should just be quoted normally, as in the cleaned version:


<div class="float_left">
<p>Here's a recent conversation I had with a friend of mine:</p>
</div>
<div class="float_right">
<ul>
<li><cite>Mark</cite> said:
<blockquote><p>So, have you looked into this new "semantic markup" thing?</p></blockquote></li>
<li><cite>DrBob</cite> said:
<blockquote><p>Hell no! I'm the best coder in the world already!</p></blockquote></li>
<li><cite>Mark</cite> said:
<blockquote><p>Are you sure? It looks like it has benefits.</p></blockquote></li>
<li><cite>DrBob</cite> said:
<blockquote><p>Go away. I hate you.</p></blockquote></li>
</ul>
</div>
</body>
</html>

That concludes our little waltz through a semantically incorrect page. It has by no means covered every conceivable mistake regarding semantic readability, but it has covered the main ones. The main thing to think about when coding a web page, is what the actual meaning of the elements you are using is. Most of the time this is very obvious and self-explanatory, but if you're unsure at any time, it's always best to check with the W3C's specifications.

The future is sure to include more computers trawling through the internet looking for information. Whether it be the omnipresent Googlebot, or some university student's semantic web project, all computers need help in understanding web pages. Why make it harder for them, when it's so simple to make it easy?

For more information on common semantic mistakes, and the proper uses of elements involved in such mistakes, why not look at my semantics example page? It shows a table of common mistakes, and showcases some tricky (yet correct) semantics.

Some more changes...

This post was unfortunately deleted recently, but the general gist is here.

This post was a notification of the last load of updates to this website, now overwritten by the most recent load. It was unfortunately deleted as the result of a rather sticky accident, and cannot be retrieved.

Elite Force: Total Conversion

Well, since you can't see any recent blog posts, it's obvious that I've been busy! :P

For the past month I've been furiously coding for Elite Force: Total Conversion, and I can say that our code is taking shape. :D

I've coded most of the weapons and got them to a semblance of their final form. The pickups are just about all coded and working, and the useable pickups are currently under construction.

Our other fine coders have whipped up a nice everything-else, and we're nearing the time when we can say "Yah-boo. We've got a working game. :P"

On a side note, ocPortal 2.5 beta-testing is coming to an end, and it's looking good. :)

Spam statistics

I've just finished going through my Thunderbird Junk e-mail folder, adding spam-sending IP addresses to the tomjepp.co.uk sendmail reject list (over 200 of them), and I saw some patterns in the dust...

I've prepared a pie chart of the distribution of IP addresses that send spam to me:

http://tecnocode.co.uk/misc/Spam-Statistics-Pie-Final.png

It shows clearly that most of my spam comes from several key IP ranges (e.g. 20x.*.*.*).

I guess that one of those large ranges is Korea...:ninja:

Here is my current (03/06/05) sendmail reject list. Feel free to use it as you deem necessary.

AJAX

OK. I've been wanting to write an article about the myriad wonders of Ajax almost since I first found out about it. Ajax is a very powerful and flexible technology (almost as good as XML :P), and I love raving about it. I've just found some time to write this article; I'm currently rather depressed with some work I've been doing for the past 8 hours, so I thought now was as best a time as any to sit down and spout. :)

Ajax is one of the most flexible technologies to come to fruition since the birth of the web. It's actually been around for quite a while, but lack of widespread browser support, and developer ignorance have kept it at bay. It's basically just a simple application of Javascript to download new data and utilise it, without actually reloading the whole page. This allows developers to keep server load down; load data unbelievably quickly make some snazzy interfaces; and generally impress the users: Ajax is a flashy technology.

So, on to the actual code.

The implementation of Ajax is rather simple - all the data is transferred using XML packets:

  • The transaction is initiated from the client-side, using Javascript
  • The Javascript uses an XMLHttpRequest object (or equivalent) to fetch a page from the server (typically from a dynamic script)
  • It sets an "onreadystatechange" function to catch the response, and then exits
  • The "onreadystatechange" function catches the response from the server, and parses the XML
  • It then dynamically calls the respective function to deal with the actual data received

var req;

function load_XML_doc(url)
{
if(window.XMLHttpRequest)
{
//Branch for decent browsers' XMLHttpRequest object
req=new XMLHttpRequest();
req.onreadystatechange=process_req_change;
req.open("GET",url,true);
req.send(null);
}
else if(window.ActiveXObject)
{
//Branch for IE :(
req=new ActiveXObject("Microsoft.XMLHTTP");
if(req)
{
req.onreadystatechange=process_req_change;
req.open("GET",url,true);
req.send();
}
}
}

This function is called on the client-side when you want to initiate an Ajax transaction. It requests a document from the server, sets a function to catch the response, then disappears. It uses different methods of communication for different browsers (Gecko / MSIE), but the end result is still the same.

function process_req_change()
{
//If req is 'complete'
if(req.readyState==4)
{
//If status is 'OK'
if(req.status==200)
{
//Process the result
response=req.responseXML.documentElement;

var method=response.getElementsByTagName("method")[0].firstChild.data;
var result=response.getElementsByTagName("result")[0].firstChild.data;
var resultpos=response.getElementsByTagName("resultpos")[0].firstChild.data;
resultpos--;

var eval_text=method+"(";
for(var i=0;i<resultpos;i++)
{
eval_text=eval_text+"'',";
}
eval_text=eval_text+"result);";

eval(eval_text);
}
else
{
alert("There was a problem retrieving the XML data:n"+req.statusText);
}
}
}

This function receives the XML data packet sent by the server, extracts the useful data, and calls the right function to handle said data. Note that the XML handling is all done through the DOM. No IE-only old methods for Ajax. ;)

This is all fine and well...but without the XML data format, everyone's a bit stuck:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
<method>get_databases</method>
<result></result>
<resultpos>5</resultpos>
</response>

There are three main points of interest here:

  • The "method" tag: it contains the name of the Javascript function that will handle the returned data
  • The "result" tag: it contains the actual data to be used
  • The "resultpos" tag is my own addition: if you want to have the contents of the "result" tag passed to the "method" Javascript function in some parameter position other than 1, set it here. ;)

This data has to be sent with a certain MIME type ("text/xml"). The following PHP code will achieve that:

header('Content-Type: text/xml;charset=iso-8859-1');
header('Vary: Accept');

So, we have two abstract functions for dealing with XML-RPC, a format for the XML data packets, and a snippet of PHP for header manipulation. Time to write a sample Javascript function to actually call something!

function get_message(message_number,response)
{
if(response!='')
{
//Deal with the response
window.alert("Received message: "+response);
}
else
{
//Make the query!
var url="sample.php?message_number="+message_number;
load_XML_doc(url);
}
}

This function is exceedingly simple, but it manages to deal with the sending and handling of the data.

Coupled with a PHP script ("sample.php"):

<?php
header('Content-Type: text/xml;charset=iso-8859-1');
header('Vary: Accept');

echo '<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
<method>get_message</method>
<result>';

switch($_GET['message_number'])
{
case 1:
echo 'Hello world!';
case 2:
echo 'Goodbye world.';
default:
echo 'Unknown message_number.';
}

echo '</result>
<resultpos>2</resultpos>
</response>';
?>

That should work, and give you a nice little spiced up "Hello world" script - using Ajax

To make things a little friendlier for the user, you could use DOM manipulation to place results in the page dynamically.

For some neat (even if I do say so myself!) examples of Ajax in action, see Helios :D

Firefox — 50 million

Mozilla Firefox, at 16:59 GMT, on the 29th April 2005, has reached 50 million downloads!

It would've reached 50 million a lot sooner, but the downloads just suddenly stopped at 49,999,999; a picture shows the download counter at this stage. It stayed like this for about half an hour, before Asa's frantic pleas managed to finally coax a Mozilla co-worker into re-downloading the browser.

Asa was said to be "heartbroken" as the downloads stopped, but was "overjoyed" when the last download rolled into place.

;)

I've just realised that the Slashdot article I posted about this was actually accepted! :D