Not Just a Hat Rack » (X)HTML

Must-Read HTML5 Articles

andrew — Wed, 02 Sep 2009 23:14:58 +0000

An Introduction

HTML 5 differences from HTML 4 from the W3C. Fantastic summary of the stuff that HTML5 will eventually bring to the table. Take it with a grain of salt though… because as you’ll see, there isn’t a whole lot you can use right now, cross-browser, without hacks.

I mentioned the Misunderstanding Markup comic already, but definitely worth a read if you are still confused as to which markup syntax to employ.

Questions? Check the WHATWG HTML5 FAQ.

Keeping up with the Spec

Comparison of layout engines (HTML 5) on Wikipedia. As you can see, Internet Explorer doesn’t provide a whole lot of support for HTML5 features.

The spec itself is definitely worth a read. Or use the WHATWG version (it’s split into multiple pages, and updated more regularly). Obviously the most comprehensive source you’ll find.

Current Uses

HTML5 Doctor has some articles on things that are mostly cross-browser, and more or less safe to use now, like Native Drag and Drop and “Block-level” links. Unfortunately I can’t recommend utilizing much more of the tips on the HTML5 Doctor site, because they either rely on hacks, or could change as the HTML5 standard changes.

I can’t recommend using the new semantic elements from HTML5 yet, but it can’t hurt to begin preparing for HTML5 with semantic class names. If nothing else, you’ll be ready when the new elements become safe to use.

We Can Dream…

Automatic form validation? Yes please.

You can do really cool things with the canvas element apparently.

Web workers + video + canvas = pretty freaking cool.

Use the HTML5 Doctype

andrew — Tue, 25 Aug 2009 20:36:54 +0000

Yes, that’s right, you can use the HTML5 Doctype () now, if you want to. It’s certainly not necessary, but there’s several good arguments for implementing it sooner rather than later, and not many arguments against it. First things first, check out the incredibly insightful Misunderstanding Markup comic written by Jeremy Keith. Jeremy explains the differences between XHTML 1 and 2, and HTML, and boils down the “which doctype to use” argument to personal preference. So what are the reasons, if any, not to use HTML5?

There’s a good summary in a Stack Overflow question about using the HTML5 doctype:

Well consider this:

When serving as text/html, all you need a doctype for is to trigger standards mode. Beyond that, the doctype does nothing as far as browsers are concerned.

When serving as text/html, whether you use XHTML markup or HTML markup, it’s treated by browsers as HTML.

So, really it comes down to using the shortest doctype that triggers standards mode () and using HTML markup that produces the correct result in browsers.

The rest is about conforming, validation and markup prerference.

With that said, using now and trying to make your markup conform to HTML5 is not a bad idea as long as you stick to stable features that work in browsers now. You wouldn’t use anything in HTML4 or XHTML 1.x that doesn’t work in browsers, would you?

In other words, you use with HTML4-like markup while honoring things that have been clarified in HTML5. HTML5 is about browser compatibility after all.

The downside to using HTML5 now is that the spec can change quite often. This makes it important for you to keep up with the spec as it actively changes. Also http://validator.nu/ might not always be up-to-date, but http://validator.w3.org/ isn’t always up-to-date either, so don’t let that stop you.

Of course, if you want to use XHTML 1.0 markup and conform to XHTML 1.0, then you shouldn’t use .

Personally, I always use for HTML.

So there’s a slight chance you could have a problem validating your markup. And there’s a very slight chance that a change to the HTML5 standard will result in a different doctype. But mainly it comes down to personal preference. If you want to write XHTML syntax and have it validate against an XHTML DTD, then you would have to use an XHTML doctype.

Personally, I like XHTML syntax. I use self-closing tags, always write in lowercase, and use quoted attributes. But when I validate my markup, I’m mainly looking to correct issues that would break the document display. I dislike some of the more unnecessarily strict validation rules, like including a “type” attribute on script tags, and putting inputs inside block level elements. HTML5 offers the best of both worlds, allowing you to write XHTML syntax (which mainly means self-closing tags), while not requiring as many crazy rules. So why not have the option?

The other big advantage of using the HTML5 doctype now, is that it allows you to implement some of the HTML5 components that are currently supported cross-browser. You can use native drag and drop, “block-level” links, and the new, more semantic elements with an HTML5 doctype now, but not with the XHTML doctype.

So I guess if you really want your markup to validate as XHTML, you can use the XHTML doctype. But otherwise, use the HTML5 doctype, and look forward to browser adoption of some of the cooler HTML features!

Benefits of CSS Sprites

andrew — Thu, 11 Sep 2008 19:55:24 +0000

I haven’t used CSS Sprites a lot in the past, but when I finally started to, the benefits were immediately visible. I won’t go into detail about how to use this technique as it’s been covered in detail. I will, however, try to elaborate on just how much of a benefit CSS Sprites can offer.

Page Load Speed

The first immediately noticeable benefit of CSS Sprite usage is the faster loading time of your page. It may seem counterintuitive, because you would think that the alternative (having many smaller images vs. sometimes extra images for Sprites) would be smaller in total size, but that’s not true. There’s a small amount of extra information in each individual image you use on your site, so depending on the number of images you may end up actually loading less when all is said and done.

Also, one of Yahoo’s best practices for reducing page load time is to minimize HTTP requests. Using the Sprites technique does just that, reduces HTTP requests by combining images in a single file. CSS Sprites are specifically mentioned in the same Yahoo article as a method to reduce image requests.

Accessibility

Depending on your alternative technique, using CSS Sprites could greatly increase the accessibility of your pages. Let’s assume we have the following navigation:

…and we want each element to light up on hover:

You could use individual images for each navigation element, and then switch them out with the latter treatment using JavaScript on hover. Your HTML would look something like this:


...



...

But what happens if a user’s browser doesn’t support JavaScript? Or CSS? Or images? Using CSS Sprites, your HTML code could look like this:



	Nav 1
	Nav 2
	Nav 3
	...

…which would degrade much better in older or alternate browsers.

Time

CSS Sprites are easier than the alternative. Slicing up and dealing with multiple images is time-consuming, as is any necessary JavaScript image manipulation. Plus, there are even several tools that will generate Sprites for you:

And these are just some of the benefits of this technique. If you haven’t at least tried working with CSS Sprites I highly recommend it.

Cross-Domain AJAX with DOMAssistant

andrew — Fri, 22 Aug 2008 19:37:20 +0000

In a previous post I mentioned that I would revisit cross-domain AJAX calls to measure the helpfulness of JavaScript frameworks like DOMAssistant and Prototype. In this post I’ll use DOMAssistant to perform the same basic tests I did previously, while evaluating the potential increase in efficiency.

Creating a `XMLHttp` Object

The first thing you’ll notice when using the aid of a JavaScript framework AJAX library is that you don’t have to bother creating a XMLHttp object. That means right off the bat you’ll save yourself some (often painful) cross-browser scripting. You can also be assured that any future improvements to this object implementation will be delivered to your code as long as you keep the framework updated. Thank you JavaScript frameworks!

Setting Up and Sending the Request

Here’s the code I wrote earlier to perform both get and post requests without the help of a framework:


// Create and send an XMLHttp request
function doRequest(url, postVars) {
	// Get the request object (see previous function)
	req = getReqObject()
	// Make sure we have a XMLHttp object created
	if (req) {
		// If it's a post, we have to create and send the request slightly differently.
		if (postVars) {
			req.open('POST', url, true);
			req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
			req.send(postVars);
		} else {
			req.open('GET', url, true);
			req.send(null);
		}
		// Set the function that handles the results
		req.onreadystatechange = function () { displayContents(req) };
	}
}

// Request via GET
doRequest('test.php?var=1', null);

// Request via POST
doRequest('test.php', 'var=1');

With DOMAssistant, you have to decide before your call what you are going to do with the data. For simple calls where you just need to return the text, you can use the library’s get or post methods:


// Request via GET
DOMAssistant.AJAX.get('test.php?var=1', displayContents);

// Request via POST
DOMAssistant.AJAX.post('test.php?var=1', displayContents);

However, if you need an XML result that you can parse (like in our working example), you’ll need to make more complex calls:


// Create and send an XMLHttp request
function doRequest(url, postVars) {
	// If it's a post, we have to create and send the request slightly differently.
	if (postVars) {
		DOMAssistant.AJAX.ajax({
			url: url,
			method: "POST",
			params : postVars,
			callback: displayContents,
			responseType: "xml",
			headers : {
				"Content-type" : "application/x-www-form-urlencoded"
			}
		});
	} else {
		DOMAssistant.AJAX.ajax({
			url: url,
			method: "GET,
			callback: displayContents,
			responseType: "xml"
		});
	}
	// Set the function that handles the results
	req.onreadystatechange = function () { displayContents(req) };
}

// Request via GET
doRequest('test.php?var=1', null);

// Request via POST
doRequest('test.php', 'var=1');

As you can see, if you need an XML document for additional post-processing, you’ll end up with almost as much code with DOMAssistant!

Handling the Result

Here’s the function I wrote to alert specific data from the response content:


// Display resulting content from req
function displayContents(req) {
	// Only do something when the request is done
	if (req.readyState == 4) {
		// Make sure it was a success
		if (req.status == 200) {
			// Traverse the resulting XML, alerting titles of items
			var xml = req.responseXML;
			var items = xml.getElementsByTagName("item");
			for (var i = 0; i < items.length; i++) {
				alert(items[i].getElementsByTagName('title').item(0).firstChild.nodeValue);
			}
		} else {
			alert('Problem with the request.');
		}
	}
}

An odd thing about DOMAssistant is that your specified callback function is hardcoded in the framework to be executed after the request is complete. This means you won’t be able to troubleshoot based on the ready state of the request. I also found that the callback function doesn’t have access to the status of the completed request, meaning you won’t know if your request was successful or not. I’m sure there were logical reasons by the developers for this, but in the meantime all you can do is work with the response text.

If you used the get or post methods, you’ll be provided the text of the response:


// Display resulting content from responseText
function displayContents(rText) {
	alert(rText);
}

For our example, we needed an XML document, and as such we need to loop through and extract the information in much the same manner as we did before:


// Display resulting content from req
function displayContents(rXML) {
	var items = rXML.getElementsByTagName("item");
	for (var i = 0; i < items.length; i++) {
		alert(items[i].getElementsByTagName('title').item(0).firstChild.nodeValue);
	}
}

As you can see there really isn’t any difference here except that DOMAssistant actually limits our troubleshooting capabilities.

Cross-Domain Requests

JavaScript frameworks don’t provide a built-in solution for addressing cross-domain request security issues. In fact, the Prototype documentation makes this extremely prominent at the top of their documentation:

Remember that for security reasons (that is preventing cross-site scripting attacks) Ajax requests can only be made to URLs of the same protocol, host and port of the page containing the Ajax request. Some browsers might allow arbitrary URLs, but you shouldn’t rely on support for this.

Conclusion

All in all I’m rather disappointed with DOMAssistant’s AJAX library. For very simple tasks like grabbing, posting and printing text it works great. But for complicated cases, it offers little to no benefit. It could be effective if used in conjunction with a more complex server-side proxy, so that the proxy could handle parsing and the DOMAssistant would just have to retrieve and display text. Next time I’ll take a look at Prototype, and see if it offers more flexible and comprehensive functionality.

Simple Color Selector Script

andrew — Tue, 12 Aug 2008 18:20:11 +0000

Recently I was tasked with creating a form that allowed the user to specify a color selection from a limited number of options. There are numerous scripts that display a popup color selection on the web, but I needed one that was limited to just a few colors. So I wrote a script that makes all text inputs in a form with the class name of “color” display a simple color selection box. Here’s what it looks like in action:

Implementation

Download and store the JavaScript and CSS:

Simple Color Selector (.zip)
Simple Color Selector (.tar.gz)

Then add the following references to your page:

Usage

The script creates the color table and assigns click events dynamically, so all you have to do is include the word “color” in text input classes like so:

By default, the script displays the following colors: White (blank), black, grey, red, yellow, and blue. You can easily replace the default colors by adding the following after you reference the main JavaScript file:

And that’s it! The user’s selection will be hidden within the text inputs, so upon submission you’ll be able to work with the resulting data. Feel free to modify functionality within the JavaScript file, or style within the CSS file.