Wisdump » Web Programming

rel, rev, and HTML5

Sophia Lucero — Thu, 02 Jun 2011 01:22:30 +0000

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.

Clarifications on XHTML & HTML5

Sophia Lucero — Tue, 10 May 2011 17:53:10 +0000

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 .

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?

WebKit: One browser engine to rule them all?

Sophia Lucero — Tue, 11 May 2010 13:16:05 +0000

Right now, so many major players in the web browsing space have turned to the WebKit project for its rendering needs—

Apple: Safari
Google: Chrome
Nokia: Symbian web browser for S60
Google: Android web browser
Research In Motion: BlackBerry web browser
and more

—that one has to wonder if web browsers should just stop running on their own and agree to just merge, possibly under WebKit, since it seems to be so popular across the board. To be clear, if Mozilla’s Gecko renderer had the same track record, I’d say the same thing.

It’s less a matter of killing healthy competition and innovation among vendors, more about eliminating the headache of rendering differences. People can probably file away all the browser bugs and inconsistencies across browsers and their various versions in a full encyclopedia set. (IE6 would take up at least a couple of volumes.) This tedious aspect of front-end development could be greatly reduced if all these browsers adopted the same rendering kit. Then the vendors can focus on improving and innovating in other aspects, like what Google did with its JavaScript V8 engine.

Mozilla can enjoy more time expanding its already large and loyal userbase, working on Labs products like Bespin and Weave, pushing for the WOFF web font format, and so on.

One can argue that if we should be able to choose browsers, then the same can be said for underlying rendering engines, and accept the differences as a a consequence of the freedom to choose. But does a consumer of the Web need to choose which rendering engine he prefers? Or are the differences something we can finally do without?

I, for one, would be thrilled if we didn’t have to worry whether websites looked the same in every browser, and just focus on making websites look and behave the best they can. And I’m pretty sure ordinary users don’t even think about rendering differences.

e-Book formats or HTML?

Sophia Lucero — Sat, 20 Mar 2010 20:35:17 +0000

So Mark Boulton decided to release his book, A Practical Guide to Designing for the Web, online and without cost. It’s not the only web design book available for free on the web, which this list and a previous encounter with two other online books prove, but all of them make me wonder, again, about the electronic book format.

In the examples above, said “books” don’t adapt official e-book formats, but stick with plain old semantic HTML and PDFs. Joe Clark, in an A List Apart article, explains that both standard and proprietary e-book formats are just more specialized versions of HTML/XHTML, so is there anything gravely wrong with creating webpages instead of actual e-book files?

As one who knows her way around HTML, taking an extra step into e-books (e.g. ePub) feels clunky and unnecessary. However, that is hasty judgment without first considering factors like audience. For web design books, perhaps it makes more sense to not bother with anything else and keep them as webpages because web designers work on sites all day long. That’s not to say they wouldn’t enjoy reading web design books in their e-book readers, but they may mind less having a book in one tab alongside other web design resources in other tabs.

Using proper formats also seems like a natural extension of web standards philosophy. If one were to publish a book online, why not go for the suitable format? There are scripts, extensions, and converters available. And with the ePub Zen Garden following in the steps of the CSS one, it may become the next worthy cause to root for.

Obstacles to HTML5

Sophia Lucero — Tue, 16 Mar 2010 16:37:18 +0000

I’ve sung praises over the Flash-based multimedia suite Aviary, but what’s more disruptive than an company using Adobe’s own technology to compete with them? Perhaps something that erases Flash from the equation altogether, which is what you get with Sketchpad. If enough effort is poured into this project down the road, taking desktop tools to the web browser may no longer need plugins like Flash and Air.

That still seems like a far away future, though. Even this ReadWriteWeb report, where HTML5 has been found to be sometimes more CPU-intensive than Flash, indicates it doesn’t even have that advantage in the bag.

Then there are others who can’t see how HTML5 and Flash can even be comparable, but here’s a compelling point for that argument: where are the tools for creating in HTML5? John Nack from Adobe has a few answers. Though as an Adobe guy, he advocates for Flash too.

Finally, there’s browser adoption as the biggest and most obvious issue of all. And sadly, that one might not even be resolved.

All of these beg the question: “Is it irresponsible to advocate using HTML5 before it is ready?” But when, pray tell, will it be ready?

IE6 = iPhone?

Sophia Lucero — Tue, 09 Feb 2010 05:29:04 +0000

The Apple stories just don’t stop coming, do they? Here’s yet another provocative issue concerning the company, but this time with web development: the iPhone is the new Internet Explorer 6, according to Peter Paul Koch.

The iPhone has become an obsession. If we don’t pay attention, we’ll have a mobile web that only works on the iPhone. And then we’ll have the real mobile web that wasn’t made by us and doesn’t give a shit about web standards and best practices.

Worse, it seems web developers are happy with this state of affairs. It seems web developers are congratulating themselves on excluding 85% of the smartphone users. They certainly never bother to check their sites in S60 WebKit, the largest smartphone browser in the world.

Fucking dimwits.

We’re doing exactly the same as ten years ago. We now say “iPhone” instead of “IE6,” but otherwise nothing’s changed.

No, wait, there’s one more change: the iPhone has far less mobile market share now than IE6 had desktop share back then.

The once most advanced browser is now the most hated, and the same fate could happen with the iPhone and its mobile web browser. However, given that they were made by two very different companies—the oft-hated Microsoft and the much-adored Apple—it’s hard to imagine the revolutionary smartphone gaining a stigma someday. An interesting achievement if that does somehow happen, but what an unfortunate future that would be.

Still, I have two points to make. First: I’m glad that a reputable voice is finally calling out this obsession with creating custom-tailored websites for the iPhone, when it’s supposed to have the most advanced browser, displaying pages as they normally would on a regular computer. Chances are you don’t have to. That’s what the multitouch zoom gesture is for, so that the screen size wouldn’t be such a hindrance.

Second: hype, here we go again. PPK draws back the curtain and tells us that there are other devices far more popular than the iPhone, yet the buzz about mobile web development is strongest with iPhone apps and iPhone app-like websites. It goes against the very idea of web standards, of making websites work in as many platforms as possible, not just what gains the most attention and is considered cool. (As an aside: what can be said about implementing CSS3 properties via browser-specific extensions? Is it the same thing?)

Finally, a minor third point: Koch isn’t addressing every mobile web developer in his article, just the ones that are so caught up in this iPhone-loving bubble that it’d be a shame when they mislead impressionable developers branching out to the mobile arena.

And a far worse shame if because of the hype we somehow get stuck in the rut that is IE6 all over again.

Long live View Source!

Sophia Lucero — Fri, 15 Jan 2010 01:47:26 +0000

According to Ajaxian, the beloved tradition of learning by peeking at someone else’s source code is on the brink of extinction. Because Google is rewarding websites that load faster, people will stop at nothing to look good in the big G’s eyes, including code compression and more notably, obfuscation. This renders View Source useless.

While I feel it’s too early to call doomsday on View Source because of such speculation, like many I feel protective over it. It’s no surprise then that the Save View Source movement has been formed this early. The discussion is sparse, but Alex Russell elegantly explains why View Source matters, also reminding me why I love developing on the Web:

View-source provides a powerful catalyst to creating a culture of shared learning and learning-by-doing, which in turn helps formulate a mental model of the relationship between input and output faster. Web developers get started by taking some code, pasting it into a file, saving, loading it in a browser and hitting ctrl-r. Web developers switch between editor and browser between even the most minor changes. This is a stark contrast with technologies that impose a compilation step where the process of seeing what was done requires an intermediate step. In other words, immediacy of output helps build an understanding of how the system will behave, and ctrl-r becomes a seductive and productive way for developers to accelerate their learning in the copy-paste-tweak loop.

Even in compiling languages people learn better by looking at example code, but the culture of open learning can be felt strongest on the Web. Ajaxian posts a follow-up, in which I couldn’t agree more with this:

I personally feel like the ability to view source fit in perfectly with the culture of the Web, and was especially important early on. I am willing to bet that we have all learned from the notion of view source.

The freedom of access to tons of information on the Web is what it all boils down to. View Source is a sturdy consequence of that. It seems wrong to compare performance versus learning, but between those two, learning should prevail.

Then again, who can stand in the way of site owners desperate to turn up traffic and profit? Sounds like standards versus SEO all over again. What do you think—is the Save View Source movement an overreaction or a preemptive strike?

Mozilla Jetpack: jQuery-esque Firefox add-on development

Sophia Lucero — Tue, 08 Dec 2009 10:27:51 +0000

And by jQuery-esque I mean easy! The premise of Jetpack, Mozilla Labs’s latest creation, is that anybody who knows HTML, CSS and JavaScript can create Firefox add-ons.

It takes 80 lines of code to block ads on websites as shown in the demo above, and 14 lines to edit images from within Firefox. Granted, it just sends the data to Pixlr which does all the hard work, but lowering the obstacles to develop some fairly nifty scripts is a commendable effort, just as what jQuery did with JavaScript, Sass with CSS, and HAML with HTML. It’s made even more compelling with Bespin, Mozilla’s HTML5-powered web-based code editor.

Perhaps I’m still in a “standardize everything” mood, or envy this new doodad since I’m now using Chrome as my default browser, but don’t you sometimes wish all browsers could do this? Do the same set of things? We’re getting to a point where the level of HTML and CSS support is the same across every browser, so it makes me wonder what’s the next step for the idea of cross-browser compatibility.

It will probably depend on what the web browser means to its various makers. Google has unveiled the Chrome OS, which will run on a specialized version of Chrome. Opera is focused on its “web servers for everyone” feature in Opera Unite. (And Internet Explorer is playing catch-up, mostly.) Browsers are basically the gateways to the whole Internet, but they’ve become more ambitious than that and their vendors will attend to those ventures first before convening to create new cross-platform goodness.

Diving into HTML5 and riding the Google Wave – in book format

Sophia Lucero — Sat, 07 Nov 2009 01:29:50 +0000

Two cutting-edge web technologies, two water-related metaphors, two print and electronic book guides. HTML5 and Google Wave seem to have a lot in common these days.

HTML5

The Dive Into HTML5 site is the hub of Mark Pilgrim’s drafts for his book of the same name. He’s uploaded 4 chapters so far, and lays the foundation for building HTML5 pages from the ground up.

Aside from the excellent typesetting—feels wondrous to read it like a classic book, complete with old style illustrations and drop caps from public domain images—web designers and developers will definitely appreciate how the text will remain under a shareable, remixable Creative Commons license even when the dead-tree version comes out.

Google Wave

The Complete Guide to Google Wave site is also an unofficial guide to new Google product Wave. It’s created by Lifehacker editors Gina Trapani and Adam Pash, with 8 chapters and two appendices on maximizing the power of this real-time tool.

It’s published on a wiki, and true to its collaborative spirit and Wave’s, everyone is encouraged to contribute to the Guide. The DRM-free PDF comes out this month; the book version in January 2010.

Grab your copy

Publishing the contents of an entire book online is not new, and it is akin to artists give their music away digitally but charge for the physical version. But it garners attention because it’s not the same format as the constantly-updated blogs that pop up when hot, profitable topics do. You can rent these books online at textbook rental sites.

So compared to blogs, does the “online book” metaphor work? The wiki format does seem like a good way to go, but I would think the convenience of blogs both in the front and back ends wins out.

The more important questions however: will others follow in the footsteps of Mark Pilgrim, Gina Trapani, and Adam Pash? Which types of books should have an all-access web counterpart? When is it profitable enough to do so? As a consumer and a lover of all things free, it’s an attractive and admirably fearless choice.

The circus continues: Google Chrome Frame for Internet Explorer

Sophia Lucero — Wed, 23 Sep 2009 09:39:32 +0000

Google sfida Microsoft con Chrome by Federico Fieni

Guess whose turn it is to bring Internet Exploder into the 21st century. Google has been dipping its fingers and toes everywhere, including the browser market. But it wasn’t content with creating its own; it just had to meddle with everyone’s favorite browser, IE. And based on the name, Google Chrome Frame quite literally puts Google Chrome into Internet Explorer (versions 6, 7, 8). That is, Chrome’s support for HTML5 and its JavaScript engine.

For ordinary users, it means having to download a plugin for IE so it works just as well as any other modern, standards-compliant browser does. For developers, it means adding a meta tag so their websites ~~actually work~~ work better.

Mozilla has done something similar.

A few months back, Mozilla released a element plugin. It’s really not a new concept; clearly folks at Mozilla and Google are taking drastic measures so they can slap sense into IE.

Isn’t this Microsoft’s job?

And look how well they’re doing with that.

Let’s turn the tables on this one: would Microsoft even think of creating extensions for competing browsers? Would we even find this acceptable? Of course things are different; Firefox and Chrome work worlds better than Internet Explorer ever has. You don’t see Kill Firefox or Kill Chrome campaigns, do you?

This is not a cure-all

If you don’t have enough privileges to install plugins on your workstation, the plugin and meta tag combo is useless. It doesn’t solve the biggest roadblock to dropping IE6. And if you can install programs on your computer, why not just get Chrome anyway?

Though it’s a valiant effort to bring the IE6 user stats down by a few notches, web designers and developers would still have to test for browsers without Chrome Frame.

Can you say passive-aggressive?

But is it really a charitable deal with a hint of “desperate times call for desperate measures”? If anything, this move by Google (and Mozilla) is an elegant finger to Microsoft.

Google could just sit on its pretty throne, throw more resources into advertising its own browser, and wait ’til it eventually dominates the market. Search, email, advertising, online office suite, VoIP, real-time protocol: everything it touches turns gold. History is on Chrome’s side.

But there’s more to Google Chrome Frame as it seems to scream: “when will you ever get your act together, Microsoft!”—masked by a 24-karat, “we’re here to make the Web a better place” grin.