June 2, 2011 say something

rel, rev, and HTML5

Here’s the conclusion that all the web gurus seem to have drawn over the past months: HTML5 is the future, and that future is slowly creeping into our midst. This article by Dave Shea is the latest proof of that. Then there are inspiration galleries and blogs dedicated to the use of HTML5 for markup, plus hardly any mention of XHTML2 anywhere else.

rel and more meaningful links

But I’m not going to get into the war between the two here; I’ll just focus on a specific development in the arena: link relations. There’s more to it than rel=stylesheet and rel=alternate. About a dozen more.

For example, the Google-imposed rel=nofollow will be officially added in HTML5, but the seemingly convenient rel=feed may be dropped due to browser implementation. Other interesting link relations mentioned are rel=search, which obviously points to a search page, and rel=sidebar, which refers to a document “shown in a secondary browsing context (if possible), instead of in the current browsing context.” More are being proposed here, including rel=accessiblity.

rel seems to be what plugins are to web browsers, so it’s interesting to see how they can make a markup language as extensible as possible.

rev and a less rotten web

Still related to link relations is the rev attribute, which stands for a “reverse link”. It hasn’t been as popular as its cousin rel up until microblogging boomed, and consequently, URL shorteners and the threat of link rot.

Considering just how popular Twitter is these days, particularly as a social media marketing and SEO tool where links are the mode of currency, using rev=canonical to indicate one URL is a shortened version of the other:

Google introduced rel="canonical" recently. It’s a way of pointing from an alternate URL back to the canonical URL of the current document: the relationship of the linked document to the current document is “canonical”.

If you’re linking from the canonical URL to an alternate URL (like, say, a shortened URL), you could use rev=”canonical”: the relationship of the current document to the linked document is “canonical”.

People are also advised to check long URLs at this RevCanonical app to determine whether they already contain shortened ones.

May 11, 2011 3 replies

Clarifications on XHTML & HTML5

Although we’re now in this transitional stage of shedding off old browsers and web technologies that have been stumbling blocks to creating innovative new websites, there’s still confusion and fear that needs to be quelled. (Some people just can’t get excited that easily.)

Jeremy Keith’s article, Misunderstanding markup, seems like the ideal anchor at this point. First, it points out the differences between XHTML 1.0, XHTML 1.1, and XHTML 2:

  1. XHTML 1.0 = HTML4 with XHTML syntax
  2. XHTML 1.1 = XHTML 1.0 with the requirement that documents should be served with the XML MIME type
  3. XHTML 2 = a whole new specification that has little in common with XHTML 1.0/1.1/HTML 4
  4. XHTML has two types: pages that are actually served using the application/xhtml+xml MIME type; and pages that are actually served using the text/html MIME type but follow XHTML syntax.

Confusion? Fixed.

Second and more importantly, it emphasizes what the triumph of HTML5 means for XHTML:

  1. You can still use XHTML syntax on HTML5 documents; it’s flexible enough and backwards-compatible (unlike XHTML2) that way. You can also go back to old coding conventions like uppercase tag names, optional quoting of attributes, and the absence of trailing slashes, and that’s okay too.
  2. In fact, you can serve HTML5 documents as application/xhtml+xml and you get an XHTML document, affectionately called XHTML5. At this point, only XHTML2 is dead.
  3. Still scared about taking the plunge to HTML5? It’s as easy as replacing that long-winded strict, transitional, or (gasp) frameset DOCTYPE declaration to <!DOCTYPE html>.

Once you learn items 1 and 2, the third item is all you’ll need to focus on from now on. It’s a comforting message that if you think catching up to HTML5 will be difficult, rest assured that it’s not as scary as it looks.

Fear? Fixed.

Let’s move on, shall we?

July 4, 2009 10 replies

IE6 falls; XHTML2 cancelled.

In yet another interesting turn of events, two of the biggest issues when it comes to web design and development make way for the newer, better versions of themselves.

Goodbye, IE6!

IE6 denial message for Momentile.com

Asa Dotzler of Mozilla reports that IE6 usage has now been overtaken by IE8, based on the browser tracking data from Net Applications. This happened as recently as June 2009.

Of course, specific demographics on your respective websites will vary, but this trend is a sign of things to come. And we’re not talking about years anymore, but months.

I’d have to commend Internet Explorer team on their great marketing efforts to improve the IE8 adoption rate. Even if Microsoft’s latest browser is up to snuff compared to the likes of Firefox, WebKit (Safari/Chrome), and Opera—see these comparison charts for HTML5—it’s a big step.

This is it, guys. Freedom.

Goodbye, XHTML2!

XHTML and HTML5

Slashdot reports that the XHTML2 Working Group charter is expiring by the end of 2009, and it will not be renewed. The W3C has also decided to pour more resources into the HTML5 working group.

Those who weren’t paying attention to this seeming sibling rivalry between XHTML2 and HTML5 can now rest easy. Though I’m not sure if XHTML2 ever stood a chance given how all the web gurus were backing HTML5 as early as last year. Google is on board, too. And everybody else is starting cash in on its growing popularity.

The good thing about XTHML was that it enforced well-formed markup, with strict provisions for lowercase code, quoted attributes, and trailing slashes for empty elements. Thankfully HTML5 this coding convention too, and can be served as a serialized XML document dubbed XHTML5.

At least we wouldn’t be forced to choose between the two anymore. Competition is good, but not here. We need standards.

Unwanted competition eliminated

How convenient is it that we have two less things to worry about now? Very, but now that they’re gone, it’s time to make up for lost time:

  • Microformats. (This is the easiest to jump into.)
  • Fluid layouts.
  • @font-face and custom web fonts: this time it’s not just the browser makers that web designers and developers are up against, but the type foundries. TypeKit and Kernest are attempting to bridge that gap.
  • CSS nested declarations, variables, and operations: LESS
  • CSS if statements: Modernizr
  • Animated PNGs.

Exciting times, people!

/* */