Tom Mollerus' Weblog

I stumbled across Mark Pilgrim's Dive Into HTML5 last night, and what a great read it is. Not only is it informative, teaching you about new tags and their uses, but you also get to read the history of HTML, written in Mark's entertaining style.

If I asked you to fill out the following form to get information about an LDAP server that you were supposedly giving me access to, would you know what type of information to type in?

Chances are you could enter the first value, but the second is a little tougher to understand. It would be useful to be able to give supply an example to show you what type of information is correct, right? But how do you put in examples while keeping it clear to the user that they're just examples and need to be replaced with something else?

Internet Explorer 8 Beta introduces a new live bookmark feature they call "WebSlices". WebSlices actually subscribe you to portions of a Web page. It's a pretty cool idea-- with some easy mark-up in your page, you can allow users to subscribe to subscribe to your site's information without creating an extra RSS feed. And, users can view the feed not as a text list in a grey menu, but as a slightly larger window with its original HTML/CSS formatting. It's kind of like a graphical RSS feed, but without the work of maintaining the feed.

When you click on the "Member login" link on the Text Link Ads site or respond to a comment through the admin section of a Movable Type installation, you'll be presented with a new form in a slightly different manner than you're probably used to: instead of being sent to a new page, or seeing a popup window, the current page darkens, or "greys out", and a form appears immediately overlying it. It's a really neat way to keep the user in the current page context, and it neatly gets around the growing tendency for users to suppress popup windows.

They both do it with Lightbox Gone Wild, which is an adaptation of Lokesh Dhakar's Lightbox project. It's a very easy technique to pull off... link to three script files and one stylesheet in your main page; create a second page containing the code for your form; and then put a link to the second page in the main page with a class of "lbOn". Complete instructions can be found on the Lightbox Gone Wild page.

I know that cfwindow offers some of the same functionality, but it seems to me that cfwindow can't achieve the same level of flexibility as Lightbox.js can. For instance, I think cfwindow is somewhat more limited in how much of it you can style, and is also limited in whether forms in the dialog area can target the whole page.

Ben Nadel's post about parsing CSS rules in ColdFusion reminded me of some of the techniques I've used in the past to make dynamic stylesheets. I've since stopped that practice, though, figuring that for my needs it didn't make sense to create a secondary CF request for the stylesheet each and every time someone called a page. So, I switched to a static stylesheet and used some of the techniques I've found from around the web. Save yourself some CPU cycles by letting the stylesheet and browser do the work instead.

Take, for example, the navigation at the top of my blog. The code for the navigation bar itself and the code for the stylesheet are the same for every page, yet the highlighted tab changes depending on which section of my site that you're in. The one thing that does change is the id attribute of the body tag. Read on how to get this technique to work for yourself.

In a few of the apps I've written there's been the need to show users a preview of a newsletter email or stock alert email. Before AJAX was widely known and available, you used to have to provide some action that would submit a form and refresh the page in the browser, perhaps interrupting the flow of the user's experience in the process. But today I noticed that the email service provider iContact has a great way of handling one-off preview emails without making you leave the page you're on.

Rob Wilkerson reminded me in yesterday's post regarding XRAY to mention the MRI bookmarklet from Westciv as well. From WestCiv's site: "MRI is a free cross browser tool that lets you test selectors with any web page. Selectors, particularly complex ones can be difficult to get exactly right - MRI lets you experiment with them on any web page (local or online, static or dynamic).

Essentially, MRI lets you search and identify specific selectors on your web page. Selectors are the names or tags that you specify in your CSS so that you can "select" which elements to style. So MRI will help you find all anchor tags within a list item (li > a), or all elements with a certain class or ID.

I put this as a "nice to have" since I don't think it's as useful as XRAY is. It's more often that I'm wondering "why on earth is this particular element styled/not styled this way?", which XRAY will tell me, than I wonder "which elements have this certain selector?"

I've got to add to my list of must-have developer tools:

• XRAY: XRAY is a JavaScript bookmarklet which allows you to "see the box model for any element on any web page". That doesn't sound very sexy, but it is-- when activated, this bookmarklet brings up a modal dialog box that will show you the nested parents for whatever element you click on, and you can even traverse up. Whichever element you click on or is in focus will be outlined. It's fantastic for determining an element's exact height, width, nesting, and CSS inheritance.

In my recent post titled "Preventing multiple page requests after double-clicks", I suggest a way to use JavaScript to prevent multiple requests resulting from double-clicks on submit buttons or links. In the comments of my posting, Sam Farmer mentions the technique of putting "...the submit button in a span or div and after submission change the span or div contents to say 'Processing' or something like that." His is a great idea, and one that I've used myself in other sites. I responded that I'd blog about my technique for changing the appearance of a submit button to show that it's been clicked, so here goes!

I've posted an update to my microformats CFC today. There are two bugfixes and several XSLT updates (thanks to Gideon Marken for bringing my attention to most of these issues.):

Bug fixes:

1. microformat classes would not be found in a string if they were combined with other class declarations (i.e., the CFC would find <div class="hcard"> but not <div class="pagetitle hcard">). The regular expression to match classes was updated to fix this issue.
2. the CFC would fail to recognize microformat strings as valid XML if they contained an unescaped ampersand ('&', often found in URLs, should be '&'). The CFC now automatically escapes all ampersands when parsing microformats out of a string.

1. xhtml2vcard.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.
2. xhtml2vcal.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.
3. mf-templates.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.
4. hAtom2Atom.xsl was updated to the latest version as found on http://hg.microformats.org/x2v.

You can download the CFC from my microformats CFC project page.

Block-level elements treat multiple elements on the page as a single block, putting them all in one rectangular area (think <div>, <table>, and <blockquote>). Inline elements-- and this is the part that's easy to remember-- aren't treated as a block; instead, they fall within lines (ie, "in line") and can go next to other inline elements (think <span>, <a>, and <img>).

One thing to remember is that block elements cannot go inside inline elements.

I realized that I had better start updating the web site I work on, for several reasons: I should update my skills; I could make the site more modern; and, I could make the site's presentation code lighter and faster. So, I'll write about my experiences as I go in this blog.

@media print {
	.hideFromPrinter {
		display: none;
	}
}

Then I assigned the hideFromPrinter class to each and every image tag for those blue corners... but I'm sure that I didn't find them all.

But now I know about attribute selectors, and the task of hiding those rounded corners during print view becomes much easier. I just added a new clause to my @media print section, like so:

@media print {
	.hideFromPrinter {
		display: none;
	}

	img[src^='/images/blue_corners/'] {
		display: none;
	}
}

There you have it! All of the blue corners, whose src attributes start with "/images/blue_corners/", no longer show up in print view. This works across the whole site just from 3 lines added to my stylesheet instead of adding code to every image tag.