Today I tackled another hurdle of my transition: PHP Debugging. When I first encountered PHP debugging through the DBGp plugin for Notepad++, I was thrilled, and I quickly came to rely on it. It’s especially useful for stepping through and exploring third-party PHP frameworks and applications. On my first major headache bug since I started vimming, I really missed this functionality and did a little Google search. I found several links pointing to Sam Ghods‘ script. It’s a great start, but it turns out this script is a no-go on Windows, at least as of this writing.

It took me way too long to find a proper solution, which is this revised script by Hadi Zeftin. Thanks, Hadi! I hope this post helps more people find your solution.

Adding AJAX to a website or application can improve a user’s experience, but it typically adds complexity to the coding process. For accessibility reasons, you can’t simply replace the old way with the new way. You need to make sure you offer a non-JavaScript option for accessing the information. This is part of the philosophy of Progressive Enhancement, which is central to the modern Web. More on that in a later post. To keep the increased complexity caused by Progressive Enhancement in check, we need AJAX code to be minimally intrusive.

With that in mind, we can start with the assumption that AJAX doesn’t exit. In this case, we just need to offer POURLs*, or Plain Old URLs that will be used in case the user has disabled JavaScript. Each tab setting must be addressable by a URL.

When the site works with JavaScript disabled, we need to decide on a URL syntax that causes only the unique HTML — the tab content — to be returned. In UCA’s case, we use a section identifier: “?ajsection=topic”. This gives us the option of choosing one of many sections of the page to return.

The simplest code to return the piece of content would be to put it in a function and use an if statement to filter it out:

if ($_GET['ajsection'] == 'topic') :
	printTabContent();
else:
	printFullPage();
endif;

This works, and is probably what you should do in some situations. But what if you have nested pieces of content that you want to AJAXify? What if you added complex logic and content surrounding this code? This method can end up pretty confusing. Content buffers can help keep the task at hand (returning specific pieces of content) separate from these other concerns.

First, we need the ability to stop the whole page from rendering when the URL specifies AJAX. Rather than starting with an if statement, we’ll just start a buffer for the whole page that we can later choose to throw away:

...

Next, choose a piece of content to be loaded via AJAX and capture it in a buffer. Buffers can be nested, but you need to have as many ob_end..() statements as you have ob_start() statements:

...AJAX section content...

Flushing the buffer lets the outer buffer have the full content of the page. If there is no AJAX request, it works just like it did before we started.

To separate the AJAX content, we’ll use the other buffer-closing option: ob_end_clean(). The following code runs after the full page has been rendered:

//Handle ajax section
if ($_GET['ajsection'] == 'topic')
{
	// kill buffered render for whole page
	ob_end_clean();
	// render topic section instead
	echo $ajsection['topic'];
}
else
{
	// Render entire page contents
	ob_end_flush();
}

To handle more pieces, you can change the logic in this one place.

* Pronounced like “pearls”, and yes, I did make that up just now. I would create an article on Wikipedia if this blog post met their “Reliable Source” guidelines. So picky.

Does your web browser look like this?

Do any of your friends or family members use a browser that looks like this?   If the answer is yes..

You’re killing the internet.

…

Well, OK, you’re not killing the internet. Microsoft’s Internet Explorer 6 is.

Consider IE 6 your state representative, and you’re casting your vote by using it.  Developers (at least careful ones) determine what browsers to support mainly by looking at statistics for their site, or from general web stats.  Currently, about 20% of people are voting IE 6, 50% vote IE 7, then Mozilla Firefox, then Safari. I’d like to note that IE 6, which arguably holds the #2 spot in browsers, is eight years old.

So, if you’re NOT a software developer, you may be asking, “What’s so bad about IE 6?”

The modern web is based on standards.  Browsers agree to render websites according to rules set forth by the World Wide Web Consortium. The goal is to keep websites working into the future, without costly modifications. New browsers can support older versions of the standard exactly as they did when the websites were first written.  This theory has been tested several times over the years.  Improved versions of Firefox and Opera added support for new standards (HTML5, PNG, and SVG to name a few), but the rendering of existing sites was unaffected.  New browsers (the Webkit-based Safari and Google Chrome, most notably) have emerged as well, with near perfect support for standards-conscious websites that existed long before the browsers themselves did.

Internet Explorer has been the major outlier in this regard.  Until the most recent version (IE 8, released just last month) Internet Explorer has had poor support for web standards, focusing instead on keeping backward compatibility with sites NOT coded to standards.  And even more devastatingly, what support exists in these browsers is extremely buggy, with IE 6 in particular being a serious mess.  Any web developer will tell you that working with IE 6 for more than the most basic site design is similar to dental work sans anesthetic.

Now this might start to sound like whining, and it absolutely is.  IE 6 does tend to make a me want to throw a fit, 2-year-old style.  You don’t want to roam these halls at “IE Time”.  It’s that bad.

But there’s someone else that IE’s problems affect: You, the paying customer.  Making IE 6 and 7 work well can take over 50% of the layout and styling time in a project, or it may require significant limitations on the complexity of the design.  As an example, the fancy shadows and curves you often see on our website designs often require such code gymnastics that it becomes cheaper to do another design just for IE 6.  Most of the time, that is prohibited by cost, in which case we simply remove the fancy elements from the main design.

We are slowly approaching the point where IE 6 usage is low enough that you may want to consider preferring a better and/or less costly design for modern browsers over complete IE 6 support.  I would never suggest removing content access to any users, but things like shadows or certain animations can be removed from IE 6 without affecting other browsers or accessibility.  It is also an option to accept less than perfect rendering of certain elements.  The more fancy stuff you cut for IE 6, the more time you can spend on the main design.

The problem with this is that users don’t typically understand that they’re using an outdated browser, and may blame any issues with the site on a poor design.  This is a real concern: I personally don’t enjoy disappointing 20% of my audience.  This can be mitigated somewhat with an unobtrusive message explaining the problem and suggesting an upgrade. This may not change people’s minds, but perhaps some pain in the short term is worth the long term benefits, to everyone, of getting people off of this browser.

I’d like to note that we haven’t really tried this with any sites at Softwyre, yet.  If it were 50% of users, as it was just a few years ago, no one would even suggest it.  At 20%, we start to see real cost advantages to dropping “full” support.  Again, 100% accessibility to content will always be what we strive for.  I will check for basic IE 6 support as long as any of our visitors are using it.   I’m just looking forward to the day when that’s ALL I have to do, and I think you should too.

End Note: Please note that while IE 7 has much better standards support than IE 6, it is still “buggy”, and in many cases purposefully so in order to support older sites.  The latest release, IE 8, fixes this issue, and seems to be  standards compliant.  For the record, I still prefer Firefox.

I’m writing this while lying in bed at home after spraining, breaking, and/or (thesaurus: destroy…) extirpating my ankle while playing frisbee at lunch. I had intended to write my first post™ about the psychology of development.  How wonderful that I can now share an aspect of it that I’ve just learned for myself:

You can’t code in pain.

Of course, many people have disabilities that can’t be fixed by a few aspirin, some ice, and a nice soft bed. That’s why accessibility is so important in the websites and applications we create. It’s one of the revolutionary aspects of computers and the web that those with impaired vision or hearing, or even diseases like arthritis aren’t prevented from participating as they are in many other areas of their lives.  That is, they don’t HAVE to be.

Developers and content creators simply need to care, to inform themselves, and to put in the effort to make it possible. The businesses and organizations that back websites need to treat accessibility as non-negotiable, to pay for the ‘extra’ time it takes to make their sites accessible. And it is the developer’s responsibility to push back and inform their customers when requested features affect accessibility.

I’ll probably have several posts on accessibility in the future.  For now, I’m going to do my best to make sure that those with minor injuries to their extremities have full access to the content on our sites.  I’m on a mission.