Tag Archives: HTML5

HTML5 Boilerplate

Jan 19, 2011 by Matt | Posted in Design No Comments

HTML5 Boilerplate is a default template that you can use as a starting point to build HTML5-ready web designs around. It has a few neat features, like:

  • Full cross-browser compatibility…even with IE6. It uses some scripts to add support to those uncool browsers. You can use the new HTML5 elements today. Even the video element.
  • @font-face
  • Server configuration templates (available for Apache, NGINX, and other servers) to add caching and compression.
  • Mobile optimizations
  • Print stylesheet
  • IE6 pngfix is included
  • Plenty of utility classes like .no-js and .clearfix

It’s definitely worth checking out for future reference. The reset stylesheet is fairly similar to the one I tend to use, and the HTML seems fairly well-optimized, with the scripts loading in the footer and everything.

Apple iAd Producer Lets You Design HTML5 Ads Visually

Dec 22, 2010 by Matt | Posted in Design No Comments

Apple has just launched a new OS X application intended for advertisers looking to run ads on Apple’s iAd network. The software package, called iAd Producer, gives you an iLife-style tool to visually design interactive HTML5 ads.

The iAd Producer displays a chart giving an overview of the ad bundle, allowing you to double-click the different elements and make changes to them. You can drop in graphics and videos, choose from the common page types used in ads (such as photo and video galleries, wallpaper pickers, coverflow views, etc.) and then preview the final ad in the iPhone simulator. The application also allows you to build iAds for the iPad.

It’s a great idea, I think. It may mean more advertisers will join the iAd network, since they will have to invest less resources into their ad in order to get started. A lot of big-name brands probably don’t have serious web developers on their marketing teams.

MediaElement.js WordPress Plugin

Dec 3, 2010 by Matt | Posted in WordPress No Comments

MediaElement.js is a nifty jQuery plugin that allows you to use the HTML5 video and audio elements while still supplying a Flash or Silverlight backup for compatibility.

There’s now a convenient MediaElement.js WordPress plugin that gives you easy-to-use shortcodes for use in the post editor. To embed a video when you have the plugin installed, all you have to do is put this in your post:

[video src="http://example.org/video.mp4" width="640" height="480"]

The MPEG 4 video will be served-up to supporting browsers, and others get the Flash backup. Supported formats also include WebM, MP3 and Ogg Theora. Multiple formats can be specified in one shortcode, if you have encoded multiple versions. You can serve Safari and Mobile Safari an MP4 version, Firefox an Ogg Theora, and Chrome the little-supported WebM.

It’s Safe to Use the HTML5 Doctype Today

Nov 29, 2010 by Matt | Posted in Coding, Featured 2 Comments

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

Nov 10, 2010 by Matt | Posted in Coding 2 Comments

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.

MediaElement.js — HTML5 Video Player With Flash Backup

Aug 2, 2010 by Matt | Posted in Coding No Comments

Many modern web browsers have early support for the <video> and <audio> elements in the HTML5 spec. Unfortunately, their implementation varies depending on the ideals of the various browser developers. Safari expects video to be encoded in the high-quality H.264 codec, other browsers prefer Ogg Theora. Google is trying to push their own freely-licensed VP8 codec, which Mozilla is showing signs of adopting. Then there’s Internet Explorer, which doesn’t support the <video> element at all.

Thankfully, there’s a way to fairly easily support everything. You can offer HTML5 video in one or more formats and fall back on Silverlight or Flash if necessary.

MediaElement.js allows you to do that with a little bit of jQuery voodoo. After including all of the required files, you can serve-up an H.264 video for Safari and iPhone/iPad users like so:

<video src="myfile.mp4" type="video/mp4" width="640" height="360"></video>
<script>
jQuery(document).ready(function($) {
$('video').mediaelementplayer();
});
</script>

There is also a way to specify more than one video type in the <video> element, if you have re-encoded it into more than one codec:

<video width="640" height="360">
<source src="myfile.mp4" type="video/mp4" >
<source src="myfile.ogg" type="video/ogg" >
<source src="myfile.webm" type="video/webm" >
</video>

You will want to check it out if you’re interested in cross-browser compatible web video.

A Standard to Specify a Canonical Short Link

May 19, 2010 by Matt | Posted in Coding One Comment

There has been a small push to create a standard way for a web page to specify a preferred short link for use in places like Twitter. Something like the rel="canonical" trick that tells search engines which page on your domain is the one that should be indexed. Basically, a meta tag to put in the page header, which could then be read by Twitter applications. The end goal is to help reduce the issue of “link splintering,” where everyone ends up linking to the same page with a different URL. (For instance, I could shorten a link to this page with Is.gd, then three others could create their own different Bit.ly links…)

One proposal is rev=”canonical”, but I really don’t I don’t like that option. This comment sums it up pretty well. Rev is too easily confused with rel, and is deprecated in HTML5 to boot. The “canonical” terminology also isn’t fitting, since it implies that the short URL is the preferred URL for the page (i.e. “the short link is preferred over the full one”) rather than an alternate link.

I found it interesting to learn that WordPress 3.0 is going to start automatically including something along the lines of this on permalink pages:

<link rel='shortlink' href='http://fantasyfolder.com?p=32' />

There will be hooks to override it with your own URL (so a plugin could place a single Bit.ly or YOURLS link there on publication), but the URL is irrelevant for the purpose of this discussion. The rel='shortlink' part is what interests me. I think it’s the perfect term to use for this scenario.

I think, whether you use WordPress or not, rel="shortlink" is what you should go with. (If you’re worried about controlling short links, at least.)

Cufón JavaScript Font Replacer

Oct 9, 2009 by Matt | Posted in Design No Comments

Cufón is a neat font-replacement script that has been gaining popularity of late. It’s easy to set up, and works in modern browsers, and IE6+.

Cufon on ProBlogDesign.com

To use a custom font on a web page, you first run a TTF or OTF font file through the generator on the Cufón website (or your own instance of the generator), which will convert the and generate a JavaScript file named after the font.

Next you include the minified Cúfon script, and the font JS file, then call the Cufon.replace() function.

<script src="cufon-yui.js" type="text/javascript"></script>
<script src="Copperplate_600.font.js" type="text/javascript"></script>
<script type="text/javascript">
Cufon.replace('h1');
</script>

Easy enough. The only downside is that the text won’t be selectable after the replacement.

You can read more about Cúfon in the documentation.