As I was testing a recent site I had designed in Internet Explorer for compatibility, I came across one of the forms which was apparently causing Internet Explorer 7 to crash. It put a real damper on the testing since it was causing a crash which I would consider to be pretty heavy on the “must fix” list before it goes live. The worst part was, I had done a lot of extensive testing with Firefox which showed no problems, and even Internet Explorer 8 was behaving as expected. Thankfully I have Internet Explorer 8 which finally has a decent set of developer tools built in, so I set forth to try and figure out what the problem was… hopefully!
My first thought was that it might be some code I had recently added to a JavaScript file which was responsible for capturing the name/value pair of the submit button pressed when you submit a form (which is the only way to get that information when using AJAX to submit form data). The code worked great in Firefox, but I hadn’t tested it yet for Internet Explorer at all, so I changed it around a bit to see if maybe some of that was causing it. My debugging progressed to completely commenting out that new code, essentially bringing me back to code I knew worked in Internet Explorer 7 before, but it was still crashing!
Read more…
In the middle of developing a web application and doing some routine testing just to make sure my AJAX code was working, I stumbled upon a rather odd and what seemed to be rather random error in Firefox 3. It took some debugging and a bit of speculation to figure out what the problem most likely was and how I hoped I fixed it.
Read more…
If you’re any sort of respectable web designer, you’ve obviously come across many situations when you’ve had to use divs as a sort of inline block and only wished that you could use display: inline-block to quite simply solve all your layout problems. Instead though, we’ve had to resort to using float: left and then inserting a float clearing div/br after all those floated divs. Sure, it works but it’s not what we really want to end up doing (especially having to throw in extra html markup just for visual correctness).
Well, I’ve since run in to a situation that using float: left wasn’t working for me (try centering a set of divs that have float: left – it’s a pain!), so I had to find some kind of way to use inline-block. Thankfully, Internet Explorer 8 and Firefox 3 support inline-block now, but we still have to deal with those hard-headed users that take forever (or never) to upgrade their browsers. To accomodate Internet Explorer 7 and Firefox 2 we have to use some CSS hacks (what else is new!); thankfully they’re not that bad (but it still invalidates your CSS… bummer).
Read more…
How would you like to join the Microsoft Web Solution Partner community and get your company name out there to clients you never thought of before? What if I told you you could get a free copy of Microsoft Expression Web 2, three 1hr training sessions on Microsoft Web Development tools (including Silverlight, Visual Studio, .NET and more!) and specially tailored hosting packages from the Microsoft Hosting Partner community? Not too shabby eh!
Read more…
Unfortunately, the WordPress online documentation is a mess of old, outdated API information and when I tried to make a little plugin today and have it put a little meta box in the sidebar of the edit/new post admin pages, I had one hell of a hard time getting things to work the way it was documented.
Everywhere I looked, it told me to hook on to the “admin_menu” event when I wanted to queue up my meta box using add_meta_box(). After a bit of messing around, it seemed as though I had it working for the edit post page, but then it wasn’t showing up on the add new post page. I did a bit of debugging and ensured that it was the fact that the add_meta_box() call wasn’t being queued properly – I assume it had something to do with when it was being added to the meta box queue… ultimately meaning that the “admin_menu” event was too early of an event for me to hook on to.
Read more…