Mark Pilgrim has turned the WHAT Working Group’s blog into a tool of genuine outreach and tremendously helpful (even entertaining) information. His “Road to HTML5” column “explain[s] … new elements, attributes, and other features in the upcoming HTML 5 specification” with frank clarity and developer-focused practicality.
The April 17th installment all about link relations. And while that may sound confusing, boring, or pedantic, it is actually clear, fascinating, and quite useful. If you’ve dabbled in Microformats or used rel= in your header, you’ll recognize the material and appreciate the way HTML5 is attempting to bring order to it.
And speaking of HTML5, don’t just eat the sausage, help make it. Although not a democracy, the WHAT WG is the most open standards-making activity seen on the web. To participate (even just by following along), join the mailing list.
Opera loves my web font
And so do my iPhone and your iPad. All it took was a bit o’ the old Richard Fink syntax and a quick drive through the Font Squirrel @Font-Face Kit Generator (featuring Base 64 encoding and SVG generation) to bring the joy and wonder of fast, optimized, semi-bulletproof web fonts to Safari, Firefox, Opera, Chrome, iPhone, and Apple’s latest religious device.
Haven’t checked IE7, IE8, IE9, or iPad yet; photos welcome. (Post on Flickr and link here.)
What I learned:
☛ Even if manufacturer supplies “web font” versions with web license purchase, it’s better to roll your own web font files as long as this doesn’t violate the license.
An Event Apart Seattle
Above: Part of my deck for “Put Your Worst Foot Forward,” a talk on learning from mistakes at An Event Apart Seattle 2010.
Greetings, web design fans. I’m in Seattle doing the final prep for three days of kick-ass design, code, and content. Starting Monday, April 5 and running through Wednesday, April 8, An Event Apart Seattle 2010 features 13 great speakers and 13 sessions, and has been sold out for over a month. A Day Apart, a special one-day learning experience on HTML5 and CSS3, follows the regular conference and is led by Jeremy Keith and Dan Cederholm.
In Issue No. 302 of A List Apart for people who make websites, Joe Clark explains what E-book designers can learn from 10 years of standards-based web design, and Daniel Mall tells designers what they can do besides bicker over formats.
E-books aren’t going to replace books. E-books are books, merely with a different form. More and more often, that form is ePub, a format powered by standard XHTML. As such, ePub can benefit from our nearly ten years’ experience building standards-compliant websites. That’s great news for publishers and standards-aware web designers. Great news for readers, too. Our favorite genius, Joe Clark, explains the simple why and how.
You’ve probably heard that Apple recently released the iPad. The absence of Flash Player on the device seems to have awakened the HTML5 vs. Flash debate. Apparently, it’s the final nail in the coffin for Flash. Either that, or the HTML5 community is overhyping its still nascent markup language update. The arguments run wide, strong, and legitimate on both sides. Yet both sides might also be wrong. Designer/developer Dan Mall is equally adept at web standards and Flash; what matters, he says, isn’t technology, but people.
Illustration by Kevin Cornell for A List Apart.
Betting on the web
Must-read analysis at Daring Fireball anatomizes the “war” between Flash and web standards as a matter of business strategy for companies, like Apple and Google, that build best-of-breed experiences atop lowest-common-denominator platforms such as the web:
It boils down to control. I’ve written several times that I believe Apple controls the entire source code to iPhone OS. (No one has disputed that.) There’s no bug Apple can’t try to fix on their own. No performance problem they can’t try to tackle. No one they need to wait for. That’s just not true for Mac OS X, where a component like Flash Player is controlled by Adobe.
I say what Apple cares about controlling is the implementation. That’s why they started the WebKit project. That’s why Apple employees from the WebKit team are leaders and major contributors of the HTML5 standards drive. The bottom line for Apple, at the executive level, is selling devices. … If Apple controls its own implementation, then no matter how popular the web gets as a platform, Apple will prosper so long as its implementation is superior.
Likewise with Google’s interest in the open web and HTML5. … So long as the web is open, Google’s success rests within its own control. And in the same way Apple is confident in its ability to deliver devices with best-of-breed browsing experiences, Google is confident in its ability to provide best-of-breed search results and relevant ads. In short, Google and Apple have found different ways to bet with the web, rather than against the web.
Dan Benjamin and yours truly discuss the secret history of blogging, transitioning from freelance to agency, the story behind the web standards movement, the launch of A Book Apart and its first title, HTML5 For Web Designers by Jeremy Keith, the trajectory of content management systems, managing the growth of a design business, and more in the inaugural episode of the Pipeline.
Flash, iPad, Standards
As the percentage of web users on non-Flash-capable platforms grows, developers who currently create Flash experiences with no fallbacks will have to rethink their strategy and start with the basics before adding a Flash layer. They will need to ensure that content and experience are delivered with or without Flash.
Developers always should have done this, but some don’t. For those who don’t, the growing percentage of users on non-Flash-capable platforms is a wake-up call to get the basics right first.
Flash won’t die tomorrow, but plug-in technology is on its way out.
Plug-in technology made sense when web browsing was the province of geeks. It was a brilliant solution to the question of how to extend the user experience beyond what HTML allowed. People who were used to extending their PC via third-party hardware, and jacking the capabilities of their operating system via third-party spell checkers, font managers, and more, intuitively grasped how to boost their browser’s prowess by downloading and updating plug-ins.
But tomorrow’s computing systems, heralded by the iPhone, are not for DIYers. You don’t add Default Folder or FontExplorer X Pro to your iPhone, you don’t choose your iPhone’s browser, and you don’t install plug-ins in your iPhone’s browser. This lack of extensibility may not please the Slashdot crowd but it’s the future of computing and browsing. The bulk of humanity doesn’t want a computing experience it can tinker with; it wants a computing experience that works.
HTML5, with its built-in support for video and audio, plays perfectly into this new model of computing and browsing; small wonder that Google and Apple’s browsers support these HTML5 features.
The power shifts
Google not only makes a browser, a phone, an OS, and Google Docs, it also owns a tremendous amount of video content that can be converted to play in HTML5, sans plug-in. Apple not only makes Macs, iPhones, and iPads, it is also among the largest retail distributors of video and audio content.
Over the weekend, a lot of people were doing the math, and there was panic at Adobe and schadenfreude elsewhere. Apple and Adobe invented modern publishing together in the 1980s, and they’ve been fighting like an old unmarried couple ever since, but Apple’s decision to omit Flash from the iPad isn’t about revenge, it’s about delivering a stable platform. And with HTML5 here, the tea leaves are easy to read. Developers who supplement Flash with HTML5 may soon tire of Flash—but Adobe has a brief but golden opportunity to create the tools with which rich HTML5 content is created. Let’s see if they figure that out.
THE DEATHS of Leslie Harpold and Brad Graham, in addition to being tragic and horrible and sad, have highlighted the questionable long-term viability of blogs, personal sites, and web magazines as legitimate artistic and literary expressions. (Read this, by Rogers Cadenhead.)
Cool URIs don’t change, they just fade away. When you die, nobody pays your hosting company, and your work disappears. Like that.
Now, not every blog post or “Top 10 Ways to Make Money on the Internet” piece deserves to live forever. But there’s gold among the dross, and there are web publications that we would do well to preserve for historical purposes. We are not clairvoyants, so we cannot say which fledgling, presently little-read web publications will matter to future historians. Thus logic and the cultural imperative urge us to preserve them all. But how?
The death of the good in the jaws of time is not limited to internet publications, of course. Film decays, books (even really good ones) constantly go out of print, digital formats perish. Recorded music that does not immediately find an audience disappears from the earth.
Digital subscriptions were supposed to replace microfilm, but American libraries, which knew we were racing toward recession years before the actual global crisis came, stopped being able to pay for digital newspaper and magazine descriptions nearly a decade ago. Many also (even fancy, famous ones) can no longer collect—or can only collect in a limited fashion. Historians and scholars have access to every issue of every newspaper and journal written during the civil rights struggle of the 1960s, but can access only a comparative handful of papers covering the election of Barack Obama.
Thanks to budget shortfalls and format wars, our traditional media, literature, and arts are perishing faster than ever before. Nothing conceived by the human mind, except Heaven and nuclear winter, is eternal.
Still, when it comes to instant disposability, web stuff is in a category all its own.
Unlike with other digital expressions, format is not the problem: HTML, CSS, and backward-compatible web browsers will be with us forever. The problem is, authors pay for their own hosting.
(There are other problems: the total creative output of someone I follow is likely distributed across multiple social networks as well as a personal site and Twitter feed. How to connect those dots when the person has passed on? But let’s leave that to the side for the moment.)
A suggestion for a business. Sooner or later, some hosting company is going to figure out that it can provide a service and make a killing (as it were) by offering ten-, twenty-, and hundred-year packets of posthumous hosting.
A hundred years is not eternity, but you are not Shakespeare, and it’s a start.
You’ll always draw ire for having stumbled into being the Chief of the cargo-cult side of Web Standards, with so-called ‘XHTML’ as the false idol. You did a lot of good, but not without ambiguating the nomenclature with a lot of feel-good bullshit.
You often find yourself as a mediator between designery folks (who you have a strong grasp over) and technical implementors (who will always hold a grudge against you for muddying the discourse). Asking people to wear blue toques does not particularly affect this balance.
“Cargo cult.” I love that phrase. But I’m not sure I agree with your assessment.
XHTML, with its clearer and stricter rules, came out just as many of us were rediscovering semantic markup and learning of its rich value in promoting content. It wasn’t a coincidence that we took this W3C specification seriously and helped promote it to our readers, colleagues, etc. The stricter, clearer rules of XHTML 1.0 helped enforce a new mindset among web designers and developers, who had previously viewed HTML as an “anything goes” medium (because browsers treated it that way, still do, and quite probably always will; indeed HTML5 codifies this, and that’s not necessarily a bad thing).
Future versions of XHTML became a dead-end not because there was no value in strict, semantic, structural markup, but because the people charged with moving XHTML forward lost touch with reality and with developers. This is why HTML5 was born.
That’s history and it’s human behavior. But those subsequent twists and turns in the story don’t mean that standardistas who supported XHTML 1.0 (or still do) and who used it as a teaching tool when explaining semantic markup to their colleagues were wrong or misguided to do so.
That some technical people in the standards community think we were wrong is known, but their belief does not make it so.
That a handful of those technical people express their belief loudly, rudely, and with belligerent and unconcealed schadenfreude does not make their point of view true or persuasive to the rest of us. It just makes them look like the close-minded, socially maladroit, too-early-toilet-trained, tiny-all-male-world-inhabiting pinheads they are.