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.
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:
- XHTML 1.0 = HTML4 with XHTML syntax
- XHTML 1.1 = XHTML 1.0 with the requirement that documents should be served with the XML MIME type
- XHTML 2 = a whole new specification that has little in common with XHTML 1.0/1.1/HTML 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:
- 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.
- 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.
- 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?
Jon Tangerine, David DeSandro, Trent Walton have all come up with ingenious ways to create image-free logotypes by pushing the limits of CSS (Sean Martell made a mouth-watering CSS-based logo too, but doesn’t contain text) that one has to wonder: is this the next step in online branding and identity?
The simplest argument against this could be that a logo must be constant. In the absence of CSS styling, possibly even helper JavaScript, an image will not suddenly morph into a default browser style and render a brand generic. See the image above for how the CSS-based Opera logo degrades in different browsers.
Now that excludes the scenario where images are turned off, and where text—styled text—can come in. Instead of simple image replacement techniques, we now have @font-face embedding and other advanced effects to bring the text as close as possible to the original design.
Text is great because you can read it, as can search engines. Another thing text based logos have going for them is they’re easier to make bigger; that’ll win over a lot of clients.
But there’s a great deal of extra markup required to achieve the necessary look. Does this make sense for the notion of a logo, which is inherently more portable with an image than with a bunch of divs, spans, classes and IDs? Should logos always be images and nothing but, or can they be both text and images? Which should come first, designing the logo in the browser or in a graphics program? Or should all of this experimentation remain just that: experiments?
Me, I just love we could be on the brink of shattering print conventions, yet again.
It’s April 9th somewhere around the world and that means it’s time for the annual CSS Naked Day. Just how elegant and semantic is your website’s markup? Stripping out your stylesheets will determine that. Good houses must have good foundations, and so must good sites.
The idea behind this event is to promote Web Standards. Plain and simple. This includes proper use of (x)html, semantic markup, a good hierarchy structure, and of course, a good ‘ol play on words. It’s time to show off your <body>.
As an aside, I like that this ‘Day’ is arbitrarily stretched out to 48 hours instead of the usual 24 to accommodate locations all over the globe. I think more worldwide events and holidays should be more timezone-neutral.
We need more standards-focused advocacies like Blue Beanie Day, the countless kill IE6 websites, and this.
The Web Standards Project (WaSP) has just announced that members of the Internet Information Security Consortium (I2SecC) have discovered the real purpose of the infamous Conficker Worm, set to wreak havoc on millions of compromised systems on April 1st.
WaSP has also discovered that the best way to fight this malware is to ensure your websites are standards-compliant:
In order to ensure you do not fall victim to the worm’s botnet, I2SecC recommends immediate validation of the markup and supporting stylesheets for any Web site that you maintain and correcting any errors that are uncovered. As yet, it is unclear whether the worm will target sites that make use of non-standard DOM scripting; however, a message found by I2SecC researchers in an online forum believed to be from the worm’s creator or a close associate hints that it will: “your document.all are belong to us.”
April Fool’s! If only we could save the world from malware with web standards!
Conficker is very real, however, so please exercise caution today.
Make love, not war.
Round one: logo vs. title inside <h1>
I like that The h1 Debate was created to tackle a very specific issue in HTML that affects standardistas and search marketers alike. It asks the question what should go inside an <h1> tag, a logo or page name?, then you cast a vote by tweeting.
I expect lot more discussion than that, though; a poll is not enough. How about answering this question: should the <h1> tag appear exactly once on a webpage? For the record, Molly Holzschlag disagrees:
@fineartdavid it is SEO folks who IMO started the “only 1 h1″. I see cases of multiple h1 use such as in projection media: h1=slide header 1
That’s comforting for me to hear, but it might not be for you. But don’t take it as gospel—unless you consider Molly as god! If you’re an SEO guy and have some other god, then by all means.
Round two: generic vs. semantic CSS classes
If you squint long enough, you'll see a dog. And a rabbit.
The h1 Debate reminds me of a recent post at Devlounge that condemns generic CSS classes. Sure, separation of content and presentation is supposed to make webpages more efficient and future-proof, but if you avoid using unsemantic names like “left”, “right”, “center” and end up with convoluted markup, are you really writing sensible HTML? You have a choice between being purist and being practical. As Simon Collinson says:
Leaving the h1 debate now. I do it my way for reasons I believe are common sense. The day there is one way to build websites I will quit.
Which one are you?
Round three: CSS vs. tables (again?)
This is exactly what iamelgringo is talking about.
And for the nth time this millennium, it’s CSS vs. tables all over again. Apparently the case against tables is not strong enough…
CSS is really cool. It is useful for a lot of things. The basic idea of separating content from presentation is sound. But when it comes to layout, the design of CSS is fundamentally flawed. Use tables instead.
…or maybe too strong:
So I don’t ever want to read how web designers who don’t use pure CSS in their layouts are lazy, stupid, don’t care about their craft, backwards or don’t bathe properly. Never again. People who post such things online are heretofore to be known as CSS Trolls and are to be banished from the internets for all time. Begone yea vile fiends!
I completely agree with Simon in that there is not one way to build websites. That’s the beauty of it. Now I won’t go so far as say that we should all go back to tables. I’m somewhat disappointed it’s still an issue but I understand where these people are coming from. Ron Garret is giving up, but iamelgringo is not, and is only pointing out that (1) the biggest websites out there still use tables and (2) the purists (“trolls”) give CSS a bad rap.
Now I won’t be swayed by the source code on Google.com as I don’t think it matters. Does it matter to you?
The winners? It’s your call
What are your priorities? Web standards? SEO? Efficiency? A clear conscience? Sanity? You don’t have to be a purist or a pragmatist all the time, and shifting gears on each project doesn’t mean a sellout either. List those down and rank them based on your needs and your client’s. Then code accordingly.
*/
