<geeknotes>

very OCCASIONAL notes on I-should-get-out-more kinda stuff

Peter-Paul Koch's site

NOVEMBER 01 03

Added a new site to my web-design links section that deserves a mention here too: QuirksMode. This is the splendidly opinionated and well-written personal site of Peter-Paul Koch, freelance web developer in Amsterdam, the Netherlands. In javascript, he says, rather amusingly, 'I function on international guru level'. If you want to learn about javascript this site should be your first port of call, he obviously knows his subject and is very readable.

He is certainly braving new ground by insisting on 'Quirks Mode' for CSS, but it's good he's thinking outside the box and it's interesting to read someone actually take issue with the web standards most designers have enough trouble learning without actually having to think through their worth. He's probably not going to turn back any tides, but good for the bigger picture. Attractive easy-to-read site too, that uses frames! (Make vampire presence crossed-fingers gesture.)

Thank god I'm not into breadcrumb menus, as his is magnificent, only drawback is that it requires frames to instigate, and the drawback of frames is that it makes individual pages hard to bookmark and search engines get headaches with them, and to me a great breadcrumb menu isn't a good enough trade-off. But I have to say this site works with an enviable smoothness and it's a good advertisement for the skills he's used to put it together, even though as he says himself some are out-of-fashion these days. I rather like his old-hand dissing of CSS zealots and wannabe web developers with bad javascript books, because it so clearly comes from superior knowledge. His recent article, The future of javascript, written in response to harsh criticism of his methods, is very thought-provoking, the kind of thing that simply isn't in the (bad) javascript books that I've read.

Revised javascript to kill the focus box

OCTOBER 22 03

A slight problem arose with boxkill3 and boxkill4 (see Oct 05 03) in Internet Explorer 6, which threw up an error on a single page for no apparent reason. In theory the error should have showed up before. Eventually this was ironed out, resulting in a revision, now called boxkill41. I have now updated all the pages throughout BIROCO.COM to use this improved javascript, but to save uploading everything again I have only uploaded the page affected (other/links.htm) and the new javascript, while leaving the perfectly functional previous versions on the server. This is just an expedient, I can upload the revised website as and when it might become necessary in the future. I now recommend if you wish to use this javascript that you use only boxkill41, and check back here periodically for any further revisions. Although we think we have it licked now.

To give you some idea of the problem, M G O'Farrell's email to me a little earlier, just before fixing it:

most curious. have spent the better part of the day now hot on the trail of this little beastie, and have come to appreciate what you window$ types go through. in all honesty, if i had to use a micro$oft product on a daily basis, i do believe i'd go mad.
so far, haven't even found out what the problem is, let alone discovered a solution. something about the way you've done the links on that page gives ie6 problems, ones that don't surface anywhere else. fuckin ie thinks that one or more of the links cannot receive focus - wch of course is absurd.

then again, we're told this by an absurd piece of software, so there you go. ie is shit, plain and simple. do you know that i remarked to a friend recently that ie "sucked bong water", and the son-of-a-bitch was actually offended? and get this: he is a salaried computer technician in the next county. go fuckin figure.

discovered the script was the problem by assuming, in a flash of brilliant insight, the worst-case scenario: it was my fucking fault and none of your own. when i removed every trace of boxkill3.js, the problem vanished.

had originally thought to make you a deal, about the time ie6 corrupted core memory and started spewing garbage to the screen: you bring me the head of bill fucking gates, and i'll gladly fix the script. while my machine rebooted, went and sat for a while, and have hit upon another, more humane, course of action. am writing some code to detect the use of ie, and when the test is positive, it blanks the screen and paints it with "LOSER", over and over, in 100px MS-Times New Roman, with the theme from the "mickey mouse club" playing merrily from a midi file. how's that sound? as i see it, if it saves one soul it will be well worth pissing off the rest.

more as it develops.

The fault eventually proved simple (!) to fix:

praise god almighty, i'm free at last!
why it worked on other pages and not that one alone i do not know, and for the moment at least, can live with my ignorance.

i fixed the fucking thing by formally declaring the indexing variable "i". why this would blow out now and not earlier is a mystery, but there it is. in desperation, made a test script that counted from 1 to 21, and then alerted the user, declaring its total. this generated an error too, until i added a single line of code: "var i;". i called it boxkill41.js, just to keep my own development directory in good order.

what a relief it is to return once more to the quiet comfort of linux. you really have no idea. for that matter, neither did i, until i spent today in computing hell. speaking of comfort, firebird 0.7 is out. slight differences, but looks good.

Javascript to kill the focus box

OCTOBER 05 03

As I state in the colophon on the 'about' page, this site uses javascript to remove the ugly dotted box that forms around clicked links. The script was especially created for BIROCO.COM by M G O'Farrell III. This original javascript file is boxkill3. However, I recently mentioned to him that it doesn't work on the form buttons on the contact pages, so he has now come up with boxkill4 that deals with that problem too. I think you'll find that this javascript is superior to any other solutions you are likely to come across on the web created for this purpose. It may be used by anyone on non-commercial sites, so long as the comments are not removed or the file name changed (to preserve the integrity of version numbers). I am still using boxkill3 for most of the pages here, as it does what it was designed to do, I am reserving boxkill4 solely for pages with 'input' and 'button' elements. [UPDATE: see Oct 22 03 above.]

type="image/x-icon" or type="image/ico"?

OCTOBER 04 03

I've been using type="image/ico" as the mimetype for favicons, now I notice some people are using type="image/x-icon". My favicons still display fine, my pages still validate. I'm not sure at present whether one is supposed to be better than the other.

In a rather unproductive search for information, I saw some people around the place were confused why a favicon sometimes shows in the address bar of Internet Explorer, but other times not. This one even I can answer. A favicon will not display in the address bar of Internet Explorer, unless the site is bookmarked as a 'favorite'. Of course, when you clear your cache by dumping temporary internet files to get rid of the porn you'll also dump all the favicons.

media="screen" – think again

OCTOBER 03 03

Don't use media="screen" use media="screen, projection". Why? Because 'full-screen mode' in browsers is counted as 'projection'. If the reader hits full-screen mode (F11 in Opera and Firebird) and the media has been specified only as "screen" then the stylesheet will fall away and the raw text will be delivered. Here's the relevant bit of code from my pages:

<style type="text/css" media="screen, projection">@import url(jb.css);</style>

You'd be surprised how many nicely designed CSS sites, by very skilled designers, overlook this simple thing and fail in full-screen mode (mainly because they haven't thought to test in full-screen mode and seen for themselves I guess).

Validation bugbears

JULY 21 03

At long last I have got my July 2003 page to validate. There were two problems. First, I didn't realise that an id attribute on an anchor link could not begin with a number. I was using for date anchors id values such as 20 and 18. So I have had to change the id and name values to, for example, jul20 and jul18. If you have used a permalink on your site linking to my July Journal entries you'll need to amend the end of the URL, from for instance #20 to #jul20.

The second problem was those URLs with '&' included. Some people have given up on validation because of 'the gibberish inserted into many links'. I nearly did too. Eventually though I realised that ampersands in URLs needed to be replaced with & and then the page would validate. So, for example:

http://www.googlism.com/index.htm?ism=biroco&type=1

becomes

http://www.googlism.com/index.htm?ism=biroco&type=1

When the browser reads the link it will convert & back to an ampersand and the coding of the page will also now validate.

Noarchive metatag, attack bots

JULY 17 03

I came across a metatag new to me recently. I noticed that my CSS design was badly cached in Google so have now used the following (XHTML) metatag to prevent caching by search engines:

<meta name="robots" content="noarchive" />

While some BIROCO.COM pages are still cached because they haven't yet worked their way out of the system (they've only just got into the system), I notice that it does actually work on pages that have been recently crawled. The page is still indexed of course, assuming you haven't disallowed that via a "noindex" metatag, it's just that the content is no longer available via Google's cache. I have noticed that the Google cache messes up the CSS design of other sites too, such as Zeldman's (only slightly), but it was particularly bad on mine. I can't say as I've seen much written on web-standards in relation to search-engine caching. What was curious was that the Google caching of this site in Mozilla and Netscape was okay, but not in IE6 and Opera 7 (on a PC). Not sure why that is, apart from the stylesheet not being read correctly from the Google cache in those browsers. If you want to just prevent Google caching a site, but allow other search-engines to cache it, you can use this metatag:

<meta name="googlebot" content="noarchive" />

Incidentally, Michael Zalewski wrote an incredible article in issue 57 of Phrack (the hacker's mag) on how search-engine spider bots like the Googlebot could be turned into an attack robot via 'zero-effort exploits' that could actually destroy the web: Against the System: Rise of the Robots. Generally speaking, if a thing is possible then you can be sure it's already happening. And you can be sure, also, that there's a war going on over it that you haven't heard about.