Crazy Opera and IE Display Quirks

Someone checking out my last entry about CDN performance helpfully let me know that my site was displaying horribly in Opera. I’d checked in Firefox, Safari, and Chrome and hadn’t noticed a problem and just assumed I was pretty safe in other browsers since I wasn’t doing anything especially amazing.

A few minutes with Browser Shots later and I found out that it was broken in at least Opera 10 (8 and 9 seemed to work fine, oddly) and IE – all versions, including 8. I confirmed the IE8 problems in a virtual machine (compatibility view didn’t help) and dug in with the Opera developer tool Dragonfly.

Curiously, Dragonfly’s DOM view only showed the first div in the HTML that contained the header. It took a few minutes of head scratching before I started toggling options and idly hit the button to expand the HTML tree… Suddenly everything was there. I ran the W3C Validator again, just to be sure it wasn’t my imagination, and it checked out fine.

It didn’t take long backtracking up the tree to find out where I’d gone “wrong”:

<button />

Apparently Opera 10 and IE wanted the full closing tag:

<button></button>

I’m not surprised IE choked on the short tag, but I’m really disappointed in Opera… I’ve never been happy using it, but I always respected their rendering engine.

Post Meta

10-23-2009
Date
11:06 pm
Time
2051
Views
218
Words
Comments
Comment Feeds

From WordPress to Habari

Back in February I started becoming interested in this new blogging project called Habari. I, like most people, had been using WordPress for years on what passed for my pathetic excuse for a blog.

Over those years I went through phases of love and hate for WordPress as they branched out and tried new things. Often it seemed that the good came hand-in-hand with the bad. While striving to improve their product and push adoption to the masses, many changes seemed to forsake those hard core users who had been loyal all along.

With the creation of the wordpress.com hosted platform and the funding of Automattic to continue to improve and pursue these ventures, things really began to take a turn for the worse. The line between open source and commercial venture began to blur, and continued development seemed to focus on the hosted aspect, rather than the self-hosted community. Some features did trickle back down, but the gap continued to grow as time went on.

Along the way, something totally unrelated to WordPress and the blogging world happened. My coding skills improved. While I had previously been content to harness the awesome power of the WordPress plugin system, I now felt the need to branch out and spread my coding wings. Realizing that the WordPress code base was a mess of PHP4 code, global functions and variables, and lacked any documentation at all, I became frustrated trying to make changes. Since that time, WordPress has attempted to make strides in the documentation and global functions areas, but for the most part the codebase remains as messy as ever.

Looking for alternatives, I happened to stumble upon Habari. Several people I’d known from the WordPress IRC channel had begun to frequent their IRC channel as well, and I migrated over mainly to have more people to chat with regularly. As I became more familiar with the people involved and started participating in some of the arguments happening around functionality and usability, I began to become more and more interested in the product as a whole.

Habari is totally PHP5-based. It doesn’t sacrifice functionality to appease a few misguided souls who believe PHP4 was the perfect development platform for an open source application. It’s also focused on providing the most reliable and flexible blogging experience possible (for example, it supports MySQL, SQLite, and Postgres out of the box). This kind of dedication to providing a system that will (eventually) run on any combination of technologies is really what sets Habari apart from most of the other platforms available. It’s not just about the database systems it supports, because that same approach is taken with everything: make it modular so people can substitute in their own pieces to create a system that works for them.

At the same time, close attention is paid to the quality and reliability of the code written to support these features. Not only is it heavily object-oriented, but it’s also very flexible (the two do generally go hand-in-hand) and of a high quality, which improves extensibility and performance greatly.

Don’t believe me? How about an example? Here’s a Pingdom response time graph of my blog moving from WordPress to Habari on the same Slicehost VPS:

Response Time Graph

Response times go from 900 – 1,250 ms on WordPress to 550 – 600 ms on Habari with the same content (and actually both were running their respective K2 themes) on the same server. Not only did Habari cut response times in half, but it is also much more consistent. Those 300 ms spikes are no longer a problem, it’s smooth sailing the blogging seas onboard the S.S. Habari.

If you haven’t given Habari a look, or have only tried an older version, I encourage you to test drive the latest development code straight out of SVN. It’s leaps and bounds beyond the 0.5 release and growing closer and closer to a 0.6 release every day. You should also take a few minutes to stop by the #habari IRC channel on irc.freenode.net and say hi – our community is half the value.

Post Meta

11-7-2008
Date
11:00 am
Time
546
Views
680
Words
Comments
Comment Feeds

A List Apart 2008 Survey

I just finished taking the 2008 A List Apart survey for people who are, one way or another, involved in web development. I didn’t take their survey last year, but I was surprised at the thoroughness of their questions in some areas. There was an obviously design-oriented bias in a few different places, but overall I think it should give some really great results.

Anyway, I encourage anyone else involved in web design or development to drop by and spend a few minutes answering their questions.

Post Meta

7-31-2008
Date
5:02 am
Time
195
Views
85
Words
Comments
Comment Feeds

Using CURL in XAMPP

There appear to be a lot of misguided people on the intarwebs claiming all sorts of varying things you have to do to get CURL to work on a Windows-based XAMPP install. I’d like to clear them all up here and now.

Using CURL in XAMPP

It’s really quite simple – uncomment extension=php_curl.dll in your php.ini file, then restart Apache1.

A lot of confusion seems to stem from the fact that there are multiple php.ini files in a standard XAMPP install. This really isn’t as confusing as you’d think it would be, assuming you – and I know I’m going out on a limb here – read the documentation.

There’s a straight-forward XAMPP FAQ Entry about their php.ini stucture. For those looking for the easy fix, ignore everything but the /apache/bin/php.ini file. That’s the only one that counts, regardless of which PHP version you’re currently using.

What about all the .dll files you need? Well, you don’t need them. Everything you need to run CURL on a XAMPP install is included in the download. Stop downloading extra crap and sticking it all over your system. XAMPP knows what it needs, where it’s at, and how to use it. End of story.

This is all based on the XAMPP Basic Package for Windows, version 1.6.1, released on 4/18/2007. YMMV.

Update for XAMPP 1.7.x: As of the 1.7.0 release, the php.ini file is found in /xampp/php. When in doubt, consult the FAQ entry linked above for help. Thanks to several commenters for pointing out this change!

  1. Restarting Apache is required on both Windows and Linux whenever you make configuration changes. []

Post Meta

4-21-2007
Date
12:04 pm
Time
5729
Views
276
Words
Comments
Comment Feeds