Custom modal windows using canvas and MooTools

I’ve built a simple modal window class named Modal using MooTools. This class combines a dynamic canvas drawing API (my Rectangle class) with dynamic DOM element generation to create on-demand modal windows using no external images. My goal was to make this about as easy to use as a normal JavaScript alert, prompt or confirm window.

Hawaiian diacriticals

This brings me to one of my pet peeves and the purpose of this post: misuse of the backtick (`) character. Many of the afore-mentioned well-intentioned folks mistakenly use a backtick to represent an ‘okina, and it drives me absolutely bonkers.

Fun with canvas and MooTools: a Rectangle class

Recently at work I realized I needed a good modal window that was more extensible than JavaScript’s built-in confirm and prompt windows. MochaUI looked like a handy way to get slick modal windows into my project, but I soon realized that MochaUI is designed to do much, much more than I need, and therefore is (for my purposes) bloated. So, in typical DIY fashion here at pipwerks, I decided to borrow a page from Greg’s book and make my own MochaUI-inspired modal window using the canvas element, CSS, HTML, and MooTools. After evaluating what I’d need for my little modal window, I whipped up a MooTools-based JavaScript class that produces canvas rectangles in the blink of an eye.

Constructive criticism for the new whitehouse.gov

The new whitehouse.gov site has received a lot of press since its unveiling a few days ago. Many have rightly given it kudos for bringing a modern sense of design and “Web 2.0”-style social practices to the White House. I agree that the new site is a big improvement, but upon looking under the hood, there are a number of things I’d have done differently. Here’s a quick-hit list (not comprehensive at all)…

Fixed-width layouts

While working on a recent web project at work, I wondered if I should go for a fixed-width layout or stick with my preference for fluid layouts. Fixed-width layouts are certainly easier to manage, but they just feel so… rigid. With the boom in larger monitors, I also wondered if fluid sites start presenting a problem due to being too wide. I decided to check around the web to see what others are doing.

Dealing with Internet Explorer in your JavaScript Code

It’s almost the end of 2008, and thanks to the hard work of web standardistas, browser vendors, and JavaScript framework developers, cross-browser JavaScript code is much less of an issue than it used to be. Even Microsoft is feeling the love — the upcoming Internet Explorer 8 will be a (mostly) clean break from legacy Internet Explorer releases and will behave much more like Firefox, Safari (WebKit) and Opera. …And they rejoiced.

So why is it that when I look under the hood of some recently produced web pages (learning management systems, courses produced by e-learning rapid development tools, general web pages, etc.), the pages’ JavaScript often includes incredibly out-of-date and bad-practice Internet Explorer detection?

Here’s a quick rundown on the dos and don’ts.

iframes and cross-domain security

I’m working on an HTML-based course interface that serves up content in an iframe. I had everything working great until I needed to move the content to one domain while hosting the interface on a different domain (kind of a simplified home-brewed CMS approach). BAM! Cross-domain security issues. Course interface dead in the water.