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...

We all know the scenario. Some movie protagonist is facing some movie antagonist, and the antagonist tells him to choose who dies, his (insert family member) or his (insert other family member). Always, always our good-hearted protagonist offers himself first. Only very rarely does this work.

Donnie Darko, because his enemy is metaphysical, chooses himself. Ontic enemies rarely allow this.

The rest of the time, our insidious villain makes some smart comment, and we're back to square one. The Internet Explorer team's smart response to our valiant attempt to save all our users was to provide us the conditional comments specification. Please note, the villain will never just decide to give up his evil ways at this point. Never.

Read More...