It warms the cockles to see the heart-warming groundswell of support recently for discontinuing support for the fabled, flaky and flawed web browser Internet Explorer 6 with movements like IE6 No More and Hey I.T as well as daily stories from the tech press upping the pressure on web masters and corporate I.T departments to finally put a nail in IE6’s coffin. Now even the mighty Google’s You Tube is putting an end to IE6.
IE 6 is a notoriously unsecure, non-standards compliant internet browser that makes grown-up designers and developers cry into their pillows at night. And worse than the emotional trauma, IE6 often adds extra time (and lines of code) to a development project’s user interface development and testing cycle thereby increasing project cost and degrading end deliverable performance. Clients should hate IE6 too.
We nevertheless must exercise caution in our struggle as despite the technical cognoscenti baying for IE6’s blood, there are still users out there (still above 25% worldwide reported by Net Market Share this month) that prefer the sub-standard experience IE6 brings to surfing the web.
But that’s not quite fair because it is my belief that the vast majority of this body of IE6 users are either those who surf the web for celebrity news only or are locked into doing so by their I.T department.
But let’s not demonize slow I.T departments and throw them to the dogs just yet. There is some truth to the difficulty in these large scale upgrades. In corporate environments there is usually a default set web browser and over time other systems such as the intranet, CRM and so on are developed that take only that browser into account. Thus the web browser becomes entrenched and the job of upgrading becomes a bigger one where all systems must be retested with a newer version. I would probably balk at managing that task too. Perhaps however this difficulty is a promotion in disguise! The hero who dispatches with IE6 in a corporate environment does surely show a certain ballsiness that must end in promotion!
Nevertheless I.T departments must act to protect themselves and their users who will surf the public internet. The continuing decline of IE6 is encouraging however and one day we can all look forward to the panacea of an IE6-less world and we can all start complaining about IE7 
Unite behind IE6 No More
As designers and developers we must now unite to finish off IE6. The IE6 No More initiative provides a very useful snippet of code (implemented on this site) that will detect an IE6 victim and alert them immediately and provide links to newer browsers. Let us unite to finish off IE6.
We always try to design things so they are cross browser compatible and that things work and look the same for all user no matter what version or operating system they are using.
We encountered a problem recently with a site not rendering correctly in IE6.0 - of course our dev guys fixed this right up but this inspired me to get some stats on just what browsers folks were using on our clients web sites. I took a peak at the analytics for this across a range of our clients that have significant traffic volumes (in excess of 1M visit per month) and a varied demographic user base across a range of industry sectors (Fashion, Retail and Transport) to make these stats work as ‘real’ averages.
It made interesting reading and I thought you might like to see the results.
| ORDER |
BROWSER |
PERCENTAGE OF TRAFFIC |
| 1 |
Internet Explorer |
88.58% |
| a |
v6.0 |
57.71% |
| b |
v7.0 |
41.68% |
| c |
v5.5 |
0.37% |
| 2 |
Firefox |
9.00% |
| a |
2.0.0.6 |
37.79% |
| b |
2.0.0.5 |
30.91% |
| c |
2.0.0.4 |
11.84% |
| d |
1.5.0.12 |
7.97% |
| e |
1.0.7 |
2.13% |
| 3 |
Safari |
1.91% |
| 4 |
Opera |
0.29% |
| 5 |
Mozilla |
0.08% |
Based on this data we have decided to rule out IE5.5 from any design/dev decisions going forwards. Sorry to any of you still using this, but there just aren’t enough of you out there to warrant the additional tests.
If you like coding PHP the OOP way then you will often find yourself in the arduous position of needing to populate your object attributes (member variables) from database row data. And you do this again and again and again, and you find it all rather repetitive, which it is. And you don’t fancy looking at an object relational mapping solution for now, but promise yourself you will “Another Time”.
Here it is;
class MyObject {
function __construct($data = NULL) {
if ($data) {
foreach ($data as $ak => $av) {
eval("\$this->" . $this->db2Camel($ak) . " = '{$av}';");
}
}
}
function db2Camel($str) {
$str = strtolower($str);
$parts = explode('_', $str);
for ($i = 0; $i < count($parts); $i++) {
if ($i == 0) {
$parts[$i] = strtolower($parts[$i]);
} else {
$parts[$i] = ucfirst($parts[$i]);
}
}
return implode('', $parts);
}
}
This code relies on a number of assumptions. These are, but are probably not limited to;
- The data parameter to the constructor is an associative array, depicting a row from the database.
- That the database column names are lowercase, and separated by underscores, e.g. the_column_name
- Your attributes will be in camel casing as governed by the db2Camel function
- Your attributes will be public as they do not benefit from an explicit declaration of access scope such as private or protected.
- You will access the attributes direct on the object, not through get accessors, e.g. $obj->theAttribute
- A programmer would not know the attributes that an object contained from reading the code, they would need to understand the constructor’s function and consult the database column names to infer the attribute names.
If you are happy with all those assumptions, then this code might just prove quite handy in expediating the process of population of PHP object attributes dynamically from a database.
Getting XAMPP working on Vista requires 2 things as far as I can see. I tried a fresh 1.6.2 install today but it does not work out of the box. Vista complains only about the Apache web server.
Reading around, I saw developers saying all sorts, such as making copies of the XAMPP folder to ensure Vista had the right permissions, or turning Vista’s User Access Control mechanism off, or installing services from the command line and so on and fourth.
But amongst all these suggestions, only 2 things need to be done to get XAMPP (1.6.2 anyway) working on Vista.
First, don’t forget to run setup_xampp.bat in the XAMPP installation folder.
And secondly, you need a file called msvcp71.dll to reside in the root XAMPP folder. I copied this from my old XP Windows/system32 folder, but you might need to get it elsewhere.
If you do these 2 things, XAMPP should fire up no problem.