The author, Dean Edwards, claims that "it fixes many HTML and CSS issues and makes transparent PNG work correctly under IE5 and IE6."

It's apparently been updated fairly recently. If it works, to quote Eric Meyer:

In the main, it will be a lot less painful to clear out the hacks with IE7 (the script) available than without it. A lot.

Charles Cooke wrote a nice introduction to using the library.

We’ve been talking this week about the little things in design, those small pieces that must come together to create the big experience. When they go AWOL, customers get frustrated. As I wrote on Tuesday, no hardware; no bookshelf.

Yesterday, Paul mentioned a few things designers could do to prevent or mitigate the damage from missing parts. In today’s post, I want to draw attention to his second white-hat solution: using standardized parts in designs.

There are a lot of non-standard parts floating around today’s designs: strange battery types; odd Scandinavian screws; hacky code. These may allow the designer more freedom (or just make their job easier), but they take freedom away from the end-user.

If a customer can’t wait for the company to respond with a missing part, they should be able to go to the store and quickly get a replacement. Whenever possible, using standardized parts instead of that 15/16″ septagonal bolt is bound to save the day even when your company can’t.

But standards alone aren’t enough. It is possible to use standardized pieces that customers can’t understand and/or easily replace at the store. I’m talking about proprietary standards.

Read More...

I spent Monday griping about those little bags of screws that come with Target DIY pressboard bookshelves and their like. I also intimated then that the (if not flatly unethical) lame strategies behind them have a couple of lessons to teach us all: Wordpress template factories, real estate agents, Etsy store proprietors, and big three automotive companies alike. As promised:

Be generous

Send me an extra screw, you jerks. (Image via.)

If you make design and logistical decisions using a mentality of maximizing profits, the logical conclusions will all have zero tolerance for error. Case in point the bag of hardware: There is no doubt that sending exactly the correct amount of hardware is the most cost-effective option for these companies, which is why that's what they do. However, when the factory screws up, it costs them huge, leading to frustrated customers, employees, and balance sheets. If they had just planned to throw an extra washer in every bag, they wouldn't have any of these problems.

Read More...

One particular point of pride for us here at DLB is the fact that we post on BlogLESS six days a week, and we simultaneously manage to keep it valid.

For the most part, once you've mentally committed to valid HTML, this kind of feat rarely causes a problem. However, for a very brief moment this fine Wednesday, I thought I'd share with you three fairly non-intuitive things that we've run into that caused us validation errors, and what you can do to prevent them.

Read More...

About a month ago, I wrote a post for BlogLESS about how to display video content from Vimeo with Valid XHTML using Drew McLellan's Flash Satay technique.

Recently, it occurred to me to make this explicit: You can do the exact same thing with videos from YouTube! So, in the interest of continued blog validation, let's take another look at what makes an embedded video invalid, and how to avoid it. We'll start with the generics, and then move on to the slightly more finicky YouTube requirements.

Read More...

Last week, I posted a video hosted on the video-sharing site Vimeo, only to be met with irritating XHTML validation errors.

The W3C XHTML Validator FAQ suggested I try Drew McLellan's famous Flash Satay method, but I just plain don't have the patience to wrap every embedded video on this blog in another Flash movie, and besides IE7 fixed the problem that motivated the Satay technique in the first place.

On top of all that, this particular error was incredibly easy to fix. (Which does make you wonder why Vimeo didn't just fix in the first place!)

Read More...

Background

reCAPTCHA is a free CAPTCHA service that helps to digitize books.

A CAPTCHA is a program that can tell whether its user is a human or a computer, by asking the user to copy some distorted text. You've probably seen them, either here, or elsewhere on the web. If not, just click here for an example.

The Internet Archive is going to help Spidey enter "the digital age".

reCAPTCHA gets these words from books that the Internet Archive is digitizing. Digitizing books is done by photographically scanning the book's pages, and then transforming these scans into text using "Optical Character Recognition" (OCR).

All this together means that when you leave a comment, in addition to contributing to the discussion, you are both proving you are a person, not a spambot, and helping humanity's effort to archive it's knowledge digitally.

The Problem

Which is all milk and honey, but there's a problem. As good citizens of the web, and as Wordpress users, BlogLESS utilizes reCAPTCHA's handy Wordpress Plugin. But, as good citizens, BlogLESS is further committed to web standards. This means that all our HTML and CSS needs to be valid. Unfortunately, the Wordpress reCAPTCHA plugin doesn't validate XHTML out of the box. (As it turns out, this is not its fault. It actually can't validate out of the box, which we'll see.)

The good news is, the fix is easy, once you understand the problem. You don't need to be a pro to make your Wordpress comments template valid again.

Read More...

Now more than ever, our clients want cool AJAX components for their sites. It seems like more often than not, we find ourselves creating whiz-bang image galleries, file upload forms, and a variety of other interactive components. These components can be tasteful and add much-needed fun to an otherwise run-of-the-mill interaction experience, so we like doing it.

One of the things we don't like about it, however, is the ease with which web standards can be thrown out the window in the "getting it working" part of the component development. One of the most frustrating culprits is often the family of tags that are required to generate CSS-based opacity effects for interaction elements.

Now, I am generally against using Javascript to apply unsupported CSS definitions as a salvo against the mean red screen of the CSS validator. This is usually a bad idea because, among other reasons, it can fail to degrade gracefully if the user doesn't have Javascript, and it provides a strategy to allow invalid CSS validate in cases where it really shouldn't, it's a little bit clunky when compared to other available methods, and frankly, introducing Javascript into the equation just to validate CSS rarely seems worth the trade-off. That said, in this situation, I think it's legit because:

1. The opacity definition(s), while being supported by all current major browsers and darn useful, isn't included in the CSS 2.1 spec, despite apparently being part of the jetpack-esque CSS 3 spec (::someday::), and doesn't validate.
2. In the case of an AJAX component, you're already requiring that your users have Javascript enabled, and hopefully you have a graceful exit strategy already in play if they don't.
3. Your only other choice to achieve the effect you want is to use something like Flash, which is certainly worse even than invalid CSS.

So let's take a look at how to save your opacity effects and your valid CSS using some handy DOM scripting.

Read More...