Aug 26 2008 7:41PM GMT
Posted by: Jeffrey Olchovy
Web development,
Development,
CSS,
Javascript,
Web design,
jQuery,
Web standards
For quite some time there have been a few Javascript fixes freely available for download which can correct the lack of alpha transparency handling for png images in archaic versions of Internet Explorer (archaic, in my opinion being anything less than IE 7) - but even to this day, not one of these scripts completely solves this issue with seamless integration and out-of-the-box working functionality.
The best installations require the external linkage and path updating of lengthy Javascript file(s) and 1×1 pixel transparency blocks. While not entirely inconvenient, at times all this seems like overkill just to correct one or two images that require the correct use of alpha transparency on your Web site.
With this being so, I found it generally more convenient to just make the required fix myself for these simple images using a little jQuery and some guidance from Microsoft’s Internet Explorer knowledge base.
Since I usually only need, say, a container div with a drop shadow or a small graphic with known dimensions to require such alpha transparency (both being CSS background images), I constructed this little personal fix that will correctly handle full png functionality for one CSS background image in IE 6.
The (X)HTML:
<!–[if lt IE 7]>
<script src=”path/to/javascript/pngfix.js” type=”text/javascript”></script>
<![endif]–>
The Javascript (pngfix.js):
$(document).ready(function(){
$(’.pngfix’).each( function() {
$(this).attr(’writing-mode’, ‘tb-rl’);
$(this).css(’background-image’, ‘none’);
$(this).css( ‘filter’, ‘progid:DXImageTransform.Microsoft.AlphaImageLoader(src=”path/to/image.png”,sizingMethod=”scale”)’ );
});
});
Just add the class pngfix to the image that requires alpha transparency and update the path in the Javascript file. When you add the class png fix, our jQuery selector applies a ‘top-bottom-right-left’ attribute to it in order to be sure it has layout, removes its already defined background image, and applies the new fully functional PNG image to its filter property using Microsoft’s proprietary Alpha Image Loader.
I have thus far used this with little to no problems - but like I said this was simple personal fix that best works for background images that are attached to selectors that have layout or have known dimensions.
Customize it to meets your needs or use it as a base for a new out-of-the-box jQuery fix for the comprehensive use of alpha transparency in IE 6.
Jeffrey Olchovy is a Web developer, designer and marketing strategist.
Aug 25 2008 4:03PM GMT
Posted by: Jeffrey Olchovy
Apache,
.htaccess,
Development,
Web development,
Web standards
Whether cleaning up URLs to maximize user-friendliness or to promote greater search engine crawlability, the correct use of the mod_rewrite function inside of one’s .htaccess files is integral for any developer working on Apache Web Servers.
While this entry will not go into great lengths to teach you how to use regular expressions to match your URL names and desired aliases, it will instead point out caveats to consider if you are having trouble getting your RewriteRules to work.
If you are starting from a clean slate, be sure your RewriteEngine is turned on before adding any conditions or rules to your .htaccess file. From herein, the effectiveness of your RewriteRules is a matter of regular expression syntax.
Once you begin using multiple rules in conjunction with each other the greater the risk of your rules not effectively holding and executing their desired outcome.
Note that any proceeding rule can alter the entirety of the requests that come to your domain, such as when your 301 redirect all requests to a canonical URL or append site-wide trailing slashes. This latter case, in particular, as miniscule as it may sound, can be the sole reason why all of your requested pattern matches that begin with a ‘/’ no longer function.
The power that mod_rewrite has over your domain is truly immense, and should be treated with extreme caution and precision.
Jeffrey Olchovy is a Web developer, designer and marketing strategist.
Aug 23 2008 4:53PM GMT
Posted by: Jeffrey Olchovy
MySQL,
Development,
PHP,
Web development
When optimizing the load time of any given dynamic Web page, one should make sure that they are performing the minimum number of back-end database queries required in order to generate their desired result.
When reviewing my database integration classes from a PHP based application, I noticed that the method used to register a new user employed three individual queries: one to check if there already was a duplicate username in the system, another to check if there already was a project name assigned against the one requested, and one to insert the user’s inputted data. Granted, not all three would execute every time a user tried to register, but all three were required for a successful registration. Combine this with n amount of failed attempts, each resulting in either one or two added queries, and you can see that this particularly simple registration process was adding a lot of unnecessary overhead.
To minimize the above processing, I turned to custom exception handling with PHP.
By employing PHP 5’s exception class in simple Java-esque try/catch blocks, I was able to parse the MySQL error on a single failed insert query, returning the problem property (duplicate username or project name - unfortunately not both, if such was raised) back to the user. In order to do this, simply suppress any errors (use PHP’s @ operator) upon your INSERT query, and pattern or substring match the returned error. The MySQL error will return both the number of your key and the problem value. With such information, one can easily process the problem information and funnel it back in a helpful display to the user.
Jeffrey Olchovy is a Web developer, designer and marketing strategist.
Aug 22 2008 2:37PM GMT
Posted by: Jeffrey Olchovy
Development,
Javascript,
Web design,
Web development,
jQuery,
Web standards
jQuery is great for providing uobtrusive, progressive enhancements to your HTML pages.
If you choose to markup your data with a strict doctype, there are certain liberties that you can longer take on the front-end if you want your document to validate according to it’s specified recommedation.
One example of this is the target attribute for the anchor element in XHTML 1.0 Strict.
By employing jQuery, one can easily assign event handlers across selected anchors to make sure that they open in new windows without specifying a target attribute, thereby prompting a doctype invalidity.
With jQuery, one would assign a new window to open upon the click event of your links, whilst returning a value of false to override the anchor’s default behavior (opening the link in the present browser window).
The return value of false is jQuery’s method of overriding default behaviors for on page elements such as anchors and form submits.
Proper use of such methodology can help developers craft unobtrusive, accessible Web site that are compliant with standardized devlopment best practices.
Aug 20 2008 11:58PM GMT
Posted by: Jeffrey Olchovy
CSS,
Web design,
Web development,
Yahoo!,
Web standards
A great tool that should be in the arsenal of any Web developer is YSlow.
Developed by Yahoo!, YSlow is a Firebug add-on that analyzes every Web page you load in your browser, performing metrics and generating reports based upon many rules and heuristics set by high performing Web sites.
When you launch YSlow from your Firebug panel you have the opportunity to browse through your pages’ report cards, their protocol transfer summaries, and a listing of every constituent that makes up a given page.
In my opinion, every Web site can benefit from YSlow, especially large, high-traffic receiving Web sites.
If you have a small Web presence, YSlow can best be used for making sure that your page is efficiently optimized for every one of your visitors, as each visitor will make up a larger percentage of your total incoming traffic.
I personally like to use YSlow to consolidate and optimize my CSS background images. Once I find out how many CSS background images are truly necessary for my design to still be rendered viable by popular browsers, I head over to Dynamic Drive’s image optimizer to rework my graphics to the smallest possible file sizes without sacrificing their aesthetic quality.
Aug 20 2008 2:30AM GMT
Posted by: Jeffrey Olchovy
Development,
Javascript,
Web design,
Web development,
jQuery
Hot on the tail of Saturday’s Taming the Wild Wild Web blog entry comes another jQuery tutorial as to aid developers in their behavior-level endeavors.
Tonight, we’ll tackle how one can submit a user-defined set of input, like file uploads or an array of checkboxes, without sacrificing elements of onscreen presentation.
Not quite following? Here’s a hypothetical to help bridge you along:
Suppose we had a simple file upload form that allowed users of our site to upload no more than ten images. The files would have to be processed all at once, however, screen real estate is tight and there is no reason why ten ugly file input fields should mar the front-end of our display if there is a great chance that majority of these will go unused. By having the user select the amount of files they want to upload, we can adjust the display of the screen without forcing a page reload to delegate the proper amount of fields that each user requires. If the user changes their mind mid-stream (whether they want to add more or lessen the amount file entries), our script will adjust the display accordingly without losing their already entered file paths.
Sounds good? Then let’s take a look at our form:

Nothing special going on here. Just a typical form with a select box to govern the number of files to be uploaded, followed by ten file upload fields (the maximum amount allocated for our project). The class imageFile acts as a hook for our jQuery wrappers. Notice that the file upload name attributes end with an array minded sequencing beginning with 0 rather than 1. This is important for the backend handling of these uploads, however we will not get into that here.
This is a good time to note that if you plan on using this for a real, production-level file upload script, be sure to take all proper precautions to avoid malicious files being placed on your server. In the live demo I implement absolutely no checks only because it is a dummy form. No files will be processed there.
Now let’s see how our jQuery script can add some magic to this form:

Our onChange() function is the engine here. It simply grabs the value of whatever option attribute is selected and proceeds to slice up the wrapped set accordingly. File upload fields from the start of our input list up to and including the selected value will be shown, while the rest will be hidden from screen display.
We also make sure to run this function on page load in order to hide all but the first input field (there is no selected attribute in play on this form, and as such, the default selected value will be the first option present in our select element).
And there you have it. Short, simple and sweet. The user has the illusory power of governing their screen display and input options with this form setup. By making them declare how many files they wish to upload, or whatever situation you can think of that can effectively use this method, you are essentially adding tighter controls to your backend processing as well. Without counting the files that will post, you will already have a good metric for the user’s expected amount of input. Of course users can leave fields empty, but any backend script should check such happening by default.
That concludes this jQuery simple solution tutorial. View the live demo of this example at the flexible philosophy.
Jeffrey Olchovy is a Web developer, designer and marketing strategist.
Aug 16 2008 3:50AM GMT
Posted by: Jeffrey Olchovy
Web development,
Development,
Javascript,
PHP,
Web design,
jQuery,
Web standards
* I’m having a hard time describing this tutorial in the least amount of words possible. Think about it as a jQuery solution to a select box - input toggle, where if you don’t see the option you want in a given select box, you can write-in your desired option via an input element. - JO *
* Update: I did not anticipate the traffic that this article has been receiving, and as such I am sort of embarrassed by the rather inefficient coding and implementation. Like I said in the post, this was a scaled down, simple solution to a problem that I encountered on a larger project - but that does not make it the best way to go about it countering it.
Read the comments on Ajaxian, where you’ll find more efficient renderings of this code and a Prototype version as well (courtesy of davecardwell and jdalton, respectively) *
Recently, when scripting an application that needed to provide users with the functionality to either select an option from a drop-down list or to enter their own text as an option value for the same data item, I began to think that a solution to this situation was going to unachievable via front-end and behavior-level code alone.
You see, similar form field options also appeared in two other instances within the same form and each had to pre-populate themselves with results from a relational database. Things were starting to get a little murky.
Luckily, by employing jQuery for this project, I was able to solve this issue in a mere dozen or so lines of Javascript coding.
The example I will walk you through below will not feature the back-end database connection or the data pre-load, but alas, if requested, I’ll show how simple it is to cross that bridge after you utilize the following method:
First let’s create our form:

Notice that both the select boxes and their corresponding input elements have the same name attribute. This will be important for toggling between the select and input modes. You can find this same value attached to the id attribute of each select box as well. Again, these are key in the implementation of our model.
If Javascript is disabled, the input box becomes the sole provider of our data input. We can handle non-Javascript situations in any way, shape or form due to jQuery’s ability to separate the behavior level code from our front-end HTML structure. This example is not production level, and as such, I did not make all attempts to allow for maximum progressive enhancement. A quick and dirty accessible workaround would be to keep the input field onscreen while setting the default display of the select box to none, or vice-versa.
Also note that each select box gets the class ‘leader’. This class will be the hook for our onChange() function, which we will use to toggle between the two input options.
And now for the script:

In the most primitive sense, this script checks a given element with a class of ‘leader’ and assigns its name attribute to a variable. We check against that same select box via its id. If the select box was changed to ‘other’, we remove the name attribute from the select box and display the input field. If the select box is set to anything else, we remove the name attribute from the input field.
You may be wondering why I continue to wrap my elements via their attributes rather than using the $(this) selector (as it already is assigned to my select box). While testing a more complex application of this method, the $(this) selector did not provide the functionality I required of it and was therefore dropped for this slightly more verbose workaround.
If you test the script, you’ll notice that it indeed works! However, on document load, the input field is still present.
Let’s fix that:

We’ll use the same skeletal structure of our onChange() function, save for setting it to iterate over each instance of the ‘leader’ class on document load.
In my script I use the fadeIn() and fadeOut() functions, but show() and hide() will work just fine. (What can I say? I’m a sucker for jQuery’s mediocre effects).
So that concludes our tutorial, and with that - there you have it - a simple jQuery solution to your select-input field toggling troubles.
View the Live Demo at Flexible Philosophy.
Jeffrey Olchovy is a Web developer, designer and marketing strategist.
Aug 13 2008 4:00PM GMT
Posted by: Jeffrey Olchovy
Development,
CSS,
Web design,
jQuery
The advent of the CSS 2 and CSS 3 specifications brought designers a wealth of new methods for selecting various DOM elements and properties when crafting their Web pages. These advanced selectors allow for tighter control of your Web page’s design, whilst adding a high degree of precision to your element targetting.
However, not all modern browsers support this new level of selector specificity, making it oft times a bad choice for designing sites that need to be wholly accessible and usable (just about every Web site in an ideal world!).
Gladly though, developers and designers can both rejoice and get more acquainted with these advanced selectors since most of today’s popular Javascript frameworks take advantage of their pin-point DOM accuracy when defining their wrapped sets.
Utilizing these said frameworks will both sharpen your behavior-level skillset and your ability to traverse the DOM in a way that is gaining exponential popularity.
Some of the advanced selectors worth mentioning are as follows:
- Adjacent Sibling: ‘>’
Style an element by defining which selector directly preceeds it.
- Child: ‘+’
Style a group of elements in relation to solely their group parent.
- Attribute: [attribute=”value”]
Target on page elements via filtering of their attribute values
Aug 9 2008 11:24PM GMT
Posted by: Jeffrey Olchovy
Development,
PHP,
Web development
If you are losing data in your PHP session variables, chances are, something in your Web application has gone wrong.
Sessions are quite reliable and are, in my opinion, a better replacement than cookies for script control in your applications. Think of sessions as the new accepted standard for user-authentication and the like.
The first thing you should do when checking for problems is to make sure that your session initialization (session_start()) appears across the top of every page. session_start() must be present (and should appear as the first thing in your script) before any code is output to the screen, or it will cause a warning.
If this does not fix your problem, the next most likely happenstance that is causing your session data to be lost is that you are not properly closing your sessions before making a redirection request.
session_write_close() will end your current session and will properly store all session data. If you do not do this, there is a chance that your session variables may not make it through to the next location. Normally, it is not necessary to call session_write_close() as all session data is stored after your script is terminated, but when trying to redirect to a new location such is not the case.