jQuery Application
February 10th, 2009 Filed under: News by Andrew
My recent dabbling with jQuery quickly lead me to a necessary application of my new learned skill. HomeOfficeSolutions.com utilized an outdated version of an “Amazon” style expanding menu that wasn’t getting along with IE8. With jQuery’s amazing ability to create animation effects on block level elements, I coded a new and much improved menu with better transitions and styling. View the live sample of the expanding menu on the HOS homepage.
OfficeDesignsOutlet.com
January 21st, 2009 Filed under: News by Andrew
Just completed another website for Home Office Solutions Group. OfficeDesignsOutlet.com is an e-commerce web store offering customers high end office seating for a fraction of the price. I was solely responsible for all design aspects of the website, as well as the front end development. The backend is managed by CoreSense, a proprietary PHP/MySQL CMS.
January 13th, 2009 Filed under: Uncategorized by Andrew
I decided to treat myself with the bonus I got from my job this Christmas. 50 piece brush set from Dick Blick. A nice way to get my ass in gear when it comes to painting.
Is Your Website Ready for Internet Explorer 8?
January 11th, 2009 Filed under: Tutorials by AndrewIf you’re a web designer who likes to stay on top of things, then you’re fully aware of the coming of Internet Explorer 8, and the devastating havoc it will bring to the world. Microsoft promises IE 8 to be fully standards compliant, which of course is a good thing. No more silly hacks to make a particular element behave correctly, right? The downside of things is that all that work you put into your website to look pretty and proper in IE 6 & IE 7, will completely destroy your layout in IE 8.
How is this possible you ask? When IE 7 was released, it carried over most of the annoying non-standards compliant behaviors from IE 6. In turn, the transition wasn’t as painful (it still hurt though, and there were many websites that still broke) and most of the IE 6 style fixes still applied to IE 7. IE 8 however, runs off of a completely different rendering engine.
Since IE 8 is standards compliant, it behaves just like any other browser, such as Firefox and Opera. But what happens to websites that were optimized for IE 7? They break! Microsoft knows this fact, which is why they introduced “Compatibility View.” This entails a button next to the browser’s address bar. When clicked, IE 8 renders the page in compatibility view, which is a fancier way of saying “IE 7 mode”. Awesome, so now the user will know to push the button when they encounter a website that is looking mighty disheveled. That is fine and dandy, but I feel the user shouldn’t have this kind of power, and it’s the web designer’s responsibility to make sure their websites look good, no matter which browser is being used. There are quick fixes that will keep your client from biting your head off, which leads to my next topic.
Microsoft knew that the transition into standards compliance would be difficult, so they enlisted the help of the Web Standards Project. “Browser Version Targeting” is the solution they came up with. With a brand spanking new tag, you can instruct Internet Explorer to render a page in a specific browser version. So the quick fix for any non IE 8 compliant web pages is to insert this new tag into the head section, and tell IE 8 to behave just like IE 7.
<meta http-equiv="X-UA-Compatible" content="IE=7" />
As a benefit, this tag also makes the Compatibility Button disappear. What if your site is IE 8 ready and you don’t want your pages to ever see the light of day of IE 7? Simple, tell the browser to render the page with IE 8’s rendering engine.
<meta http-equiv="X-UA-Compatible" content="IE=8" />
This is a good solution for the time being, but do we want our pages to always be rendered under IE 7 or 8? By the time IE 12 is released, why would we still force IE 7 mode? With the simple “edge” keyword, our sites will render in the latest browser version while killing the compatibility view option.
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
Since IE 8 is fully standards compliant, does this mean we can now forget about cross browser compatibility on IE 7? Absolutely not! I still check my pages under IE 6 because I know for a fact there are still people using it on older machines and operating systems. I’m afraid we’re not out of the woods yet; we still have a few years to go before earlier non compliant predecessors are phased out.
So in conclusion, I strongly recommend that you start testing your pages under IE 8. Beta 2 is currently available, although it is still awfully buggy. If you find layout issues under IE 8, the quick fix is to force an earlier version through browser version targeting. This of course is a temporary fix; you shouldn’t have your pages render under IE 7 forever, so the best course of action is to revisit your work and correct any problems for IE 8. Get rid of the compatibility view option, and you come out as a capable web designer who stays on top of things!
A List Apart features a much more detailed article on this subject, so please check it out if you would like to learn more about IE 8 and browser version targeting.
Using Blank Target with the Strict Document Doctype
January 4th, 2009 Filed under: Tutorials by AndrewOne of my biggest pet peeves with the strict document doctype is the inability to validate pages using the “target” attribute in your link tags. The World Wide Web consortium believes the user should be in control of the location of a new link, not the author. I personally don’t quite agree. Given a huge list of links, I find it annoying trying to navigate back to the originating page after visiting 5 or 6 pages. That’s a lot of clicks on the back button. I know that I should be a savvier internet surfer and utilize the browser’s history feature, but if I’m not doing it, then I know for a fact that the majority of users are also behaving in a similar fashion. As an alternative to reeducating the majority on how they should surf, the next best option is integrating a little bit of JavaScript code into you website to get around W3C’s specs, and still properly validate your pages.
The first think to consider is integration. I know a lot of the solutions floating around the internet consist of placing an “onclick” event handler right in the anchor tag, but we don’t want to do this. The first reason is that it makes ugly code that’s much more difficult to maintain, and second, we want to keep behavior and content as two separate entities, which means externalized JavaScript. Just as we try to keep visual styles and content as two separate entities through CSS stylesheets, so we should do with dynamic behavior.
To start things off, I create the basic html page with several links, as well as a blank JavaScript page named functions.js that is referenced in the head section.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <script src="functions.js" type="text/javascript"></script> <title>Using target with the Strict Doctype</title> </head> <body> <h1>Test JavaScript target using the Strict Doctype:</h1> <ul id="jstargets"> <li><a href="http://www.google.com">Google</a></li> <li><a href="http://www.yahoo.com">Yahoo!</a></li> <li><a href="http://www.live.com">MSN Live Search</a></li> <li><a href="http://www.ask.com">Ask.com</a></li> <li><a href="http://www.altavista.com">AltaVista</a></li> </ul> </body> </html>
Note that I gave the ul an id of “jstargets”. This is very important. We want to make sure that the links we want affected are encompassed by a parent element with a unique identifier that JavaScript can access. Otherwise, the code we use will affect every link in the document.
Now we start working on the JavaScript. Open the functions.js file. First we initiate a function when the window loads.
window.onload = initLinks;
Next, we define the initLinks function.
function initLinks(){
}
This function will initiate a loop that iterates through each link in the document. Then we check if the link has a parent element with the id of “jstargets”. If it does, we set the links to have a target of “_blank”.
function initLinks(){
for(var i=0; i<document.links.length; i++){
if(document.links[i].parentNode.parentNode.id == "jstargets"){
document.links[i].target = "_blank";
}
}
}
That’s it! Pretty easy and painless, best of all, our xhtml markup looks nice and clean, since we’re using an unobtrusive JavaScript technique. Also, this code is very flexible and will work no matter how many links we use, so there’s no need to edit it. Easy maintenance!
View a working example of this JavaScript technique.
Out with the old…
February 11th, 2008 Filed under: News by AndrewThanks for stopping by. I am currently working on version 3.0 for this site, so please stay tuned for the upcoming changes. It will all be for the better, trust me. In the meantime, the old site is still accessible here. Enjoy!