Thursday, 17 March 2011

What to do with CSS3?

Recently, there has been a lot of activity on the CSS3 front.  W3C have only just released a new set of CSS3 specifications ( that will already change the level of support that the newer generation of browsers can offer.  The change fundamentally means that only updates to these new browsers will enable support for these new specifications.  There aren't any massive changes in there so there aren't any nasty surprises for those learning the new specifications.

These changes are great in terms of moving forward with standardised specifications, but also potentially harmful with the lack of support currently out there. Only a couple of days ago (15th March 2011), Microsoft released their latest and greatest weapon in the browser wars, Internet Explorer 9.   

The release of IE9 is a massive roll of the dice for Microsoft.  Microsoft has seen the market share for Internet Explorer slowly erode over the past few years with the continued efforts of the likes of Firefox, Chrome and Safari, all of which have had CSS3 support for quite some time now though.  By all means, none of these browsers are perfect, and all have their own small problems supporting the CSS3 specifications.  They aren't problems as such, more like, their own interpretations of the specifications.  Personally for me, this is potentially worse than the old 'IE box model' problems that plagued earlier versions of Internet Explorer.  What I really don't want to happen is for me to suddenly have to adopt several standards of the CSS3 specifications.  For example, to have rounded borders for an element, we have to look at the following:
  • border-radius (Real CSS3 / IE9 specification)
  • -moz-border-radius (Firefox specification)
  • -webkit-border-radius (Safari / Chrome specifiction)
So now we have the situation whereby if I want to go down the route of making my site work compltely with CSS3, I have to add all of the above just to get rounded borders without having the hassle of using images to make the rounded corners.

To be fair to Microsoft on this, they have correctly followed the specification laid out by W3C.  You never thought that you would see that did you?  Early reviews and personal testing have found that IE9 is a massive improvement in many aspects such as speed, security and usability.  I actually prefer this browser to any other now.  IE8 was too buggy and would eat memory like there was no tomorrow and Firefox would crash for no apparent reason.  I do like Safari, but things sometimes look a bit odd in it, as does in Chrome.  Saying this, Microsoft have done themselves no favours by restricting the platform for IE9 to Windows 7 - probably to encourage those who are still on XP to upgrade.

What I have done so far is give in to these horrible new varied specifications.  A new site that I am working on for myself employs all of the bulleted list above.  I believe that we are currently at the turning point for moving to CSS3, although HTML5 is further away I feel.  All of the latest browsers support CSS3 whilst support for the older browsers will suddenly start to slide.  From what I have read already, IE9 already has 2% of the market.  Not a bad achievement for a product released only two days ago.

Saturday, 5 March 2011

The return of Service Unavailable HTTP Error 503

For those of you that have read my first article in this blog, one of the reasons for the migration to a new server was because I was plagued with Service Unavailable HTTP Error 503, which would forever get under my skin and just 'error' for no real reason at all.  Nothing in the error logs, no software errors, nothing.  I was aware of the IMAP PHP module being faulty, whereby if the headers of an email were over a certain length, this would result in the 'Error 503'.  I could replicate this just fine, but the server would still fall over for no reason, even if I disabled the IMAP module.

This started on Server 2003r2 with IIS6.  Some time ago, after Googling around for a little while, I eventually found that other people experiencing the same issues with some people were saying this was down to a corrupt IIS configuration.  I had never experienced this before so it eventually started to turn into a bit of a headache trying to pin this down.  It had been on the cards for some time to move the server to a new box so for me to waste time reinstalling IIS was pointless.

Moving forward a year or so, and the problem had gradually been getting more frequent.  In the end, I just made a small VB Script as a workaround that would run every few hours to restart IIS in case this had happened which always cured the problem.  This had worked fine and my hope was that a planned server upgrade would solve this issue along with an updated version of PHP.  Wrong.  A few days into the new server being in production, what happens?  Yep, you got it.  Error 503.  Great.

Only this time there was a log entry in the Windows application log.  The shortened error looked like:
Faulting application name: w3wp.exe, Faulting module name: php_imap.dll
Google again came to the rescue, with the top result pointing at this PHP bug article about IMAP headers being too long - the same bug that was present before.  It looks as though the old problem had not been cured and it seemed that the only way to fix this would be to go up a major point release of PHP to PHP 5.3.5 (current release as of now).  ISAPI was always my favourite method for PHP use on Windows, but since this has now been retired as of the last branch of 5.2, FastCGI was now my only option.

FastCGI wasn't a problem though and it does work just as well as ISAPI although it does require a bit more of a tweak to get it set up out of the box.  So far so good though.  No more 503s.  I do think that originally the 503s were the result of the faulty IMAP module, but there still must have been a massive fault with IIS6 which is now now present in 7.5.

I would just like to say thanks to everybody who has been clicking on the sponsored adverts on this page.  It's very much appreciated.