Tag Archives: (x)html

Easy CSS Sprites with Sprite Cow

CSS sprites are a commonly used technique to decrease page load times. One of the biggest hassles when setting them up, though, is figuring out the coordinates for the images in your sprite. (The other is rebuilding the sprite when you want to add new graphics…)

There’s not much to be done for the latter, but there is a handy tool that makes finding the coordinates painless. Sprite Cow intelligently draws a box around an image you select in your sprite sheet (after you load the sprite, of course) and writes the CSS for it. You can’t get any simpler than that.

I bet the developers could make some good money by making a Mac version and putting it up for sale in the App Store.

MacRabbit isn’t Dead!

Users of Espresso and CSSEdit have been complaining for some time about the lack of updates to the software. In a surprise announcement, MacRabbit (the developer) announced that Espresso 2 is on the way and that CSSEdit’s functionality is being rolled into it.

The long wait has grated both on our own nerves and those of our awesome users. But while we have kept quiet publicly about what we are working on, it is because privately we have been striving to transform our products into something new and even more awesome: Espresso 2. We are extremely excited to finally be able to show you what we have been working on, as this release will be of interest to both CSSEdit and Espresso users.

An early preview, the “kaboom” release, is already available for testing and upgrade path information has been posted.

Dive Into HTML5

Looking to bring your HTML skills up-to-date, now that HTML5 support is growing in modern browsers? Mark Pilgrim has a nice online book by the name of Dive Into HTML5 that covers most of the big new things. It is also available in print, published by O’Reilly, under the name HTML5: Up & Running.

The book, both the free online version and the print copy, cover things like HTML5 video, offline storage, detecting browser support of HTML5 features with JavaScript, as well as an overview of the new elements. An interesting chapter on the history of HTML is also included.

It’s a short book, not intended to teach newbies about HTML so much as to bring adepts up to speed with the latest advancements.

Tempo: A Tiny JSON Templating Engine

Tempo is a 4kb JavaScript library that renders JSON into an HTML template. Your script can take something like this…

<ol id="tweets">
 <li data-template>
  <img src="{{profile_image_url}}" />

…and populate it with JSON data from the Twitter API, which you could load with a couple lines of jQuery. It works with browser as far back as IE6 and doesn’t require any dependencies.

It seems like a friendlier way to deal with JSON data, and it offers the advantage of any templating system: you can separate the logic and data from the presentation.

Evil JavaScript Trick: The History Nuker

Remember back in the bad old days of the internet, when pop-up ads and other annoyances were around every corner? Some sites, by some flawed logic, would decide that you didn’t really want to leave their website when you clicked the Back button and would attempt to disable it with JavaScript. The technique they would generally use was to use the “unload” event handler to fire a document.location change, bouncing you back to the same page you were trying to leave. This, of course, was easily defeated by hammering the Back button, as a quick double-press of the Back button could override the JavaScript.

Fortunately the days when people thought that to be an acceptable practice are over.

While reading about JavaScript “hashbang” URLs, I had a thought. An evil thought. You could build a better Back button-disabling script by using the same technique used to enable the back button in AJAX-heavy websites. (Take a look at Google Instant Search’s pagination, or Twitter, to see it in action.)

I thought, what if you looped around a large number of times, changing the URL fragment, until the back button became useless? Not only would it be a pain to click the Back button, say, 300 times, the browser starts to “forget” the previous pages after one or two hundred pages. (They stay in the history, but the Back button only remembers a few.)

So I made a quick proof-of-concept. I used setTimeout() instead of an ordinary for loop, so the browser doesn’t hang when you push a few hundred items onto the history stack and window.location.hash to change the URL fragment.

var theURL = document.URL;

i = 0;
nukeBackButton = setInterval("addAFragment()", 1);

function addAFragment() {
if (i > 300) {
 clearInterval (nukeBackButton);
window.location.hash = "#fragment" + i;

You can see it in action here. It works rather well, though of course tabbed browsing easily circumvents it. (Thankfully.)

Note: I do not advocate the use of this script, and anybody who does use it is a fiendish menace to the internet. This is to be used purely for academic purposes.

HTML5 Gets a Logo

The W3C has put up a microsite with the new logo for HTML5. It looks pretty good, certainly better than its predecessors, even if it does have a bit of the “Web 2.0″ look that is finally starting to lose its novelty. I like that they kept the gradients to a minimum, which is starting to become more common in the aftermath of the glossy “Web 2.0″ style.

You can pick up SVG and PNG versions of the icon there, as well as T-Shirts featuring the logo…and free stickers if you live in the U.S. and have some spare postage stamps laying around.

Webmonkey brings up an interesting, and troubling, point about the HTML5 Logo site. The FAQ calls the logo a “general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.”

It doesn’t really matter if the New York Times thinks CSS 3 or SVG are HTML5, but we’d like to think that at least the organization in charge of describing what is, and is not, HTML5 would make some effort to distinguish between tools. Lumping everything together is as silly as a carpenter referring to every tool in their toolkit as “a hammer.”

That doesn’t sound very good to me. Is “HTML5″ becoming the new buzzword to replace “Web 2.0,” and sanctioned by its own standards body?

Update: And now it sounds like the HTML spec is no longer going to have specific version numbers

Speed Up Your Site With Head JS

Head JS is a 2.3 kilobyte script that makes it easy to asynchronously load your JavaScript files to prevent blocking. It allows the browser to load the web page separately from the scripts, so the rendering process isn’t held up by the download.

Non-blocking loading is the key to fast pages. Moreover Head JS loads scripts in parallel no matter how many of them and what the browser is. The speed difference can be dramatic especially on the initial page load when the scripts are not yet in cache. It’s your crucial first impression.

If you have a JavaScript-heavy website, it’s worth taking a look at. If you take a look at the demo pages they have set up, the page that uses Head JS to load the scripts definitely displays much faster.

Head JS :: The only script in your HEAD [Head JS]

It’s Safe to Use the HTML5 Doctype Today

If you’ve taken a look at Google’s source code lately (and really, who hasn’t?) you may have noticed that they’re already using the HTML5 doctype instead of either HTML4 or XHTML.

<!doctype html>

It’s certainly much easier to type that then hunt down and paste in the monstrosity required for HTML4 or XHTML.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

From what I’ve managed to divine from the inter-tubes, the doctype is fully backwards-compatible with aging browsers like Internet Explorer 6. It will ensure that your document is not rendered in quirks mode. Modern browsers, and validators, should recognize it specifically as the new doctype used for HTML5 documents as well.

As a matter of fact, it’s quite all right to start coding your documents as HTML5, so long as you stay away from shiny new features that haven’t been implemented satisfactorily across browsers yet. You probably don’t want to be using the canvas or video elements, for example, for anything on sites that have visitors using older browsers. (Not to mention that there’s a silly standards war going on involving video codecs…) But for the most part, HTML5 works like HTML4.

HTML5 defines an HTML syntax that is compatible with HTML4 and XHTML1 documents published on the Web, but is not compatible with the more esoteric SGML features of HTML4, such as processing instructions and shorthand markup as these are not supported by most user agents.

Some elements’ definitions have been changed slightly, but for the most part things are as they have been. It’s probably worth reading up on the differences between HTML5 and HTML4.

John Resig said it pretty well:

What’s nice about this new DOCTYPE, especially, is that all current browsers (IE, FF, Opera, Safari) will look at it and switch the content into standards mode – even though they don’t implement HTML5. This means that you could start writing your web pages using HTML5 today and have them last for a very, very, long time.

HTML5 May Not Be XHTML, But That’s No Excuse for Sloppiness

I was reading an interesting post about HTML5 and the failure of XHTML strict parsing recently, and it reminded me of an issue I have with the HTML5 spec.

It really bothers me that the HTML5 spec permits the use of quoteless attribute values (e.g. class=blah instead of class="blah") and a lack of closing slashes in empty tags. I think we can all agree that strict parsing, like with properly-served XHTML, isn’t optimal. (XML pages are too fragile. Especially when you have user-submitted content, it’s all to easy to completely break the page.) But the coding practices encouraged by XHTML make it much easier to parse web pages and to maintain some level of source legibility.

I think the HTML5 specification should incorporate some of XHTML’s requirements, while dropping the strict parsing. Let’s have quoted attributes and slash-terminated <img /> and <br /> tags. Anything else is sloppy and all too reminiscent of the Geocities days.

Anyone aiming for some level of professionalism in their work should continue with current XHTML-style coding practices and apply them to HTML5 when it comes time for that.

In the words of Tantek Çelik:

I’m going to continue coding my HTML5 with quoted attributes, explicit closing tags, and self-closing empty elements, making them what I call “bi-glot” documents: both HTML5, and valid XML.

I’ve given up on “proper” XHTML (by any definition). Long Live XML-valid HTML5.

Generate QR Codes On-the-Fly With the Google Chart API

You’ve probably seen a QR code before, even if you didn’t know what it was at the time. It’s a little square matrix barcode that can be read by either a specialized scanner or a cellphone with the right software. UPS puts QR codes on their packages for tracking purposes, and many Android phones come with QR readers preinstalled for easily sharing links to apps.

A QR code can contain any sort of textual information, which will be decoded by a QR reader. A web address, a simple message, a phone number, etc.. A good QR reader should figure out what the decrypted data is and act upon it accordingly. If it’s a web address, it will display the web page. If it’s a phone number, it should display the number and offer to call it.

Users of the iPhone or fourth-generation iPod Touch can use a free app like QR Reader to scan QR codes.

What can you use a QR code for? There are plenty of possible applications. Magazines could print QR codes that let you quickly jump to a web page. (Anyone remember the CueCat?) Advertisements could have QR codes that offer more information. You could put a QR on your business card. Want to move a web page you’re reading from your computer to your phone? Create a quick QR matrix and scan it right off the screen!

Now for the fun part… How do you make your own QR codes?

Continue reading →