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?
Or as a like to call it: podcasts that have caught my eye in the past week or so. And they differ in several ways, so there’s sure to be something for everybody. Take your pick:
Confession: It took me a while to realize that this podcast is actually the previously-named You Suck at Web Design, relaunched as a new brand with a new site design. This show isn’t so much a bag of tricks on web design as it is a quirky, personal storybook told by Matthew D. Jordan, but still a must-listen.
This is not just one but seven shows tackling different topics, from photography to Ruby programming, founded just last year by Dan Benjamin. I love the idea of a whole network of shows about the internet, on the internet, and here we have a whole suite for people who make websites. I can think of few things better than that. More networks and more topics, perhaps?
In light of the “circuses” happening in both the Hollywood late night talk show circuit and the web working groups, standardista slash comic strip creator Kyle Weems aka CSSquirrel announced this:
I am in the process of devising a “late night” talk show that the Squirrel will host, featuring interviews with cartoon representations of various web designers/developers/standardistas. It’ll draw from the mighty traditions of the Tonight Show, The Daily Show and Space Ghost: Coast to Coast, and in theory will be a plug-in free experience brought to you in part by HTML5, JavaScript and vector tree-climbing rodents.
Check out the podcast over at SitePoint, titled HTML5 is a beautiful mess:
The podcast touches on that matter, and spins out to the state of the actual implementation of HTML5 itself, whether there’s a challenge in getting designers and developers to start using it, the issues of accessibility in <canvas>, and how delightful it’d be to move past plugins.
Truthfully, I’m trying to avoid getting caught in the sticky details of how HTML5 is developing at the moment because it only adds to the anxiety (isn’t stressing over Internet Explorer enough?) and diminishes hope (we’re supposed to be moving forward with these technologies already). But it also helps to stay realistic not just idealistic, and drawing back the curtain on how the working groups are actually working on the HTML5 standard is a good way to do that.
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.
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.
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.
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 <canvas> 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.
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?
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!
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!
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!
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.
Eric Meyer has started poring over the WaSP community’s suggestions for CSS3 with a series of posts on his weblog—3 so far in less than a week. The original feedback compiled by Fantasai is a monstrous read in itself, but all these are worth perusing if you care remotely about the future of web design.
It’s comforting to have one of the gurus like him to really go over this. Although he didn’t promise to address every single point on the list, what I’m seeing so far is extremely comprehensive. More importantly, we have a strong figurehead that’s rolling up his sleeves and setting up these blog posts as the stage for discussion with people who are not necessarily involved with the W3C and other stakeholders like the browser vendors.
Between debating over specific CSS features (e.g., containing floats, center positioning, selector blocks) and looking at the bigger picture…
Maybe CSS isn’t the place for this. Maybe there needs to be a new layout language that can be defined and implemented without regard to the constraints of the existing CSS syntax rules, without worrying about backwards compatibility. Maybe that way we can not only get strong layout but also arbitrary shapes, thus leaving behind the rectangular prison that’s defined the web for almost two decades.
I don’t have a concrete idea to propose here, because it’s not up to us any more. A solution was worked out over the course of several years and then found wanting by the implementors. Really, it’s up to the implementors to figure it out now. I personally would like to just lock the browser teams from Microsoft, Mozilla, Opera, and Apple in a room and not let them out until they’ve defined something that works and they’ve all agreed to implement soonest. I might even supply food and water.
…we have to keep talking and stay restless but hopeful. We may not be able to give the final word on the next version of HTML and CSS and the web browsers, but we can talk about what could go into them while the W3C listens.
IE6 is declining. HTML5 is gaining traction. JavaScript libraries and CSS frameworks abstract the process of squashing browser bugs and incompatibilities. And progressive enhancement reassures us that we don’t have to serve up exactly the same features in ancient browsers.
And maybe we can stop acting like the current technologies are our handicap and take the plunge. Okay, maybe splashing water all over might not be a good idea at once. Try dipping your toes. Try your left leg. Try wading. The key is to at least try.
All the hoopla over Everything You Know About CSS Is Wrong!, a book by Rachel Andrew and Kevin Yank (see also the Digital Web article) is making me feel uneasy.
We’re not wrong; the title is wrong
I detest the title of the book. No, I don’t think “everything” I know about CSS is wrong. I “know” about the display:table technique for months now (thanks to Sitepoint, again).
Neither do I think it’s a good idea to go around belittling people by telling them they are wrong, whether in printed book or online article format. It’s harsh and misleading.
We’ve got issues
As for the CSS Tables technique presented in the book, these are some of the issues plaguing it:
- tag soup
- lack of source order control
- the question of semantics and presentation vs. content: is making
<div>s behave like tables/table cells any different from using tables as layouts?
- IE6 and IE7 incompatibility (no surprise there!)
And not too long after the uproar, the authors have addressed the above problems:
Andrew Tetlaw responds to #1 and #3:
No one is negatively affected by the overuse of structural div tags. The same can’t be said for the use of HTML tables for layout.
And here’s an interesting quip which points out the very valid woe of web developers, who have had to adjust to all these changes in coding conventions because of our “flakiness”:
Congratulations on years of punishing web devs for using common sense. Finally the circle turns, but somehow you think that you were ‘right all along.
Matthew Pennell of Digital Web has this to say about those who question semantics and standards:
I must say that I’m surprised that an audience of (presumably) conscientious, standards-aware developers are almost all declaring that they will not use new features of CSS when they are available and supported. Are you all so short-sighted that you cannot see any application for the techniques discussed here beyond wholesale replacement of site layouts?
And Rachel has written this regarding #4:
Some commentators have suggested that we shouldn’t have put a book out about a technique that can’t be used immediately, that will require workarounds to still provide support for older versions of Internet Explorer. I disagree. Something I point back to in the book is how the web community began to use CSS for layout even though support in Netscape 4 was limited and buggy. If those of us who were building CSS layouts right in those early days had said, “nah, it doesn’t work in Netscape, can’t do it”, then our recent history would look very different.
Are we hesitant about change and innovation?
In a sense, browser usage does “cripple” our ability to look towards a future of web design innovation (and bliss) when IE6 is finally disappears. But are things right now are exactly the same as when Netscape Navigator 4 was the stumbling block?
More importantly, will the CSS Tables technique actually push our level of innovation by a significant degree? The past few months of new websites tell me innovation is not too hard to come by still.
And what about next-generation HTML5, which will have new structural tags like <header>, <section>, <article>, <footer>? Can one not feel guilty using all those <div>s in the midst of these elegant new tags? Perhaps that’s another debate for another day—in 2022.
