No! Don’t groan! I can be long winded, yes, but this one’s short and sweet. There was a point I had wanted to add to the last post but as happens, it got left out. But it is a good one… why, exactly, do I care so much about which browsers user which rendering engines? Or even on their general history?

When I’m checking to see if my web pages work across various platforms and various browsers, I don’t have to start out by going through and checking how they appear in an all encompassing, exhausting review using each and ever on any and all. If I hit the four main engines in the order of their percentage of use: Trident, Gecko, Presto (Opera), and KHTML, I’m in a very good position. Granted, for more troublesome nit picky detail, it is possible for two different gecko-based browsers to have different problems with some bit of HTML or CSS or JS or other, but in the main, I’ve likely shaken out all the major glaring problems in the most efficient manner.

Knowing that Safari has the lion’s share of the Mac OS lets me ensure that I’ve taken care of the majority of Mac users by checking with that one. If there’s some issue with MacIE, I can pretty much leave it alone or let it degrade. Or if I’m pressed for time, I can choose Safari over MacIE or Camino or Mac Firefox and get pretty good Mac coverage.

Speaking of which, I’m aware that this blog doesn’t display well in Safari. I’m hoping to have some time on a borrowed Mac soon to figure out why.

One thing I find fascinating is the way in which browsers have gone forth and multiplied over this world. It’s not immediately obvious, but some browsers are actually quite closely related. What follows is a rough chronology of the more well known browsers. There were (and are) many more, of course, and a browse through the sources listed at the end may be of interest.

Read the rest of this entry »

For tables,

border-spacing: 0px;

works fine in every browser (Opera (PC, Linux), Firefox (PC, Linux, Mac), Safari) except IE6 to eliminate the bit of padding around the table and its border and around each table cell. For IE6, it’s necessary to use

border-collapse: collapse;

which works all of the above browsers. I even checked Mac IE which didn’t recognize either, but it’s so dead in the water it can be ignored at this point.

According to W3, both seem to be valid markup (as opposed to made-up stuff introduced ad-hoc that no one should ever use).

This is the start box with no properties specified. Note the table background color peeking around the entire table and between each cell:

With this next box, everyone but IE6 users should see a nicer alternating-row look:

With this one, everyone should see a nice alternating row color:

And now everyone (but the poor Mac IE users, of course) should see alternating rows:

One thing that tends to drive me nuts when putting a css file together is repetition of the colours. CSS has no mechanism to define constants or variables and it can be pretty tiresome playing around with resetting the colours and such when tweaking a web page.

So I made mine into a php file. There’s a few tricks, but it’s very straightforward. First, you call it in your main html file (or output) as with any other css file, only with it’s name:

<link rel="stylesheet" href="k9web-css.php" type="text/css" media="screen" />


Now here’s the fun part. The first line in the php file must now be:

<?php header("Content-type: text/css");
/* this tells the browser this is a css file! */
?>


Otherwise the file is sent as text/html and I get unhappy junk printed out. With that out of the way, the top of the file can contain something like this:

<?php
/* define colours, etc here */
$darkgrey="#555";
$lightgrey="#ccc";
$offwhite="#f6f6f6";
$cream="#ffffe7";
$brightred="#ff0000";
$darkred="#aa0000";
 
/* change these to change color scheme */
$bgcolor=$cream;
$fontcolor=$darkgrey;
$linkcolor=$darkred;
$hoverlinkcolor=$brightred;
?>


Now I proceed with the rest of the css definitions as usual, but when I want to use a defintion, I pop it in like this:

a:hover {
        color: <?php echo $hoverlinkcolor ?>;
        text-decoration: underline;
}


Looks like someone else (actually many people; try googling on “variables in css”) was addressing the same problem. My solution is pretty straightforward, although it does require access to php, etc. This solution hides it but amounts to using php to parse and replace behind the scenes, so I think my solution is at least more direct…

Ever since I first started scripting cgi to process forms I’ve used the two file format: the first file puts up the form and such and calls the second file to process the results of the form.

But it really doesn’t have to be like that. At work, I have a single program that lets you search through our database and display things, setting options and so on, and paging through the results. It only uses one executable (well there are a few more, but each one encapsulates a certain kind of function and as long as you’re doing that, you stay within that executable). Now admittedly I’ve torn my hair out more than once debugging this thing, so this idea can go too far in the other direction, but keep it to simple pairs of form/post and I’m liking it.

So I’ve started looking at my old sites and in particular the old one of mine that was offline for six years and rethinking how I did this stuff. And I’m thinking the single file form/post is a much better way to go. It’s fewer files for one thing. I’m not left having to grep through the file to see what it calls to trace down problems. They’re all there in one spot.

So for example I just redid the mail form which started out in mail.php that called sendemail.php (that’s another thing, it simplifies naming conventions — at another site of mine I’ve been trying to standardize to action_form.cgi and action_post.cgi but still it’s all a mess.

But this comes out nice and slick in one file. Start up the headers, check whether it’s a submit and the form goes in the first half the if statement, the post in the second half. Close off with the footers and it’s all set.

Now, let’s see, just how many more files are lurking around on this site? Sigh…