“Cheap, complex devices such as the iPhone and the Droid have come along at precisely the moment when HTML5, CSS3 and web fonts are ready for action; when standards-based web development is no longer relegated to the fringe; and when web designers, no longer content to merely decorate screens, are crafting provocative, multi-platform experiences. Is this the dawn of a newer, more mature, more ubiquitous web?”
Originally written for .net magazine, Issue No. 206, published 17 August in UK and this month in the US in “Practical Web Design” Magazine. Now you can read the article even if you can’t get your hands on these print magazines.
The new Kindle has a lot going for it. It’s inexpensive compared to a full-featured tablet computer like the iPad; you can slip it in your back pocket, where it’s more comfortable than an old-style paperback; and it includes a Webkit browser. This last point is where folks like us start to give a hoot, whether we’re fans of epub reading or not.
The flavor of Kindle’s browser concerns us because it affords us the ability to optimize the mobile viewing experience with a single line of markup. You can see this in action in the photo at the head of this article (published and discussed on Flickr).
I made no tweaks for Kindle per se; the Kindle is simply responding to a line of markup I’ve been putting into my web pages since 2007—namely, the viewport meta element, which controls the width of the viewport, thus enabling mobile devices with a limited number of pixels to focus all available pixels on your site’s core content (instead of, for instance, wasting part of the small screen on a background color, image, or gradient). The technique is as simple as web design gets:
meta name="viewport" content="width=770"
(Obviously, the value of “width” should be adjusted to match your site’s layout.)
I learned this little trick from Craig Hockenberry’s Put Your Content in My Pocket (A List Apart, August 28, 2007), which I naturally recommend to any designer who hasn’t seen it.
You scream, I scream, we all scream for epubs. As with all internet bounty, it’s even more exciting to produce than to consume. So after you’ve glutted yourself on all those free Jane Austen novels and children’s books, and gone into hock re-creating your library on iPad, why not give something back by doing a little writing yourself?
What to write about, how to ensure quality, and how to identify and market to an audience are beyond the scope of this little post, but we can point to some dandy resources that tell how to create and test your epub. So let’s go!
Our first two resources come from Adobe and tell how to set up an Adobe InDesign file to produce a proper epub. There are other ways of creating an epub—for instance, you can author it in valid HTML, zip it up, and convert to epub using the BookGlutton API. For many readers of this site, that’s all you need to know.
But if you are a graphic designer or book designer, or if epub is only one format you are publishing to (i.e. if you are publishing traditionally printed books that double as epubs), then the next two resources are exactly what you need:
Join us for a lively discussion as we talk about designing and coding for the likes of the Sundance Film Festival and New York Magazine, and the joys of responsive web design, working remotely, and swearing profusely on Twitter. We may even get Ethan’s take on Microsoft’s dazzling new IE9.
As always, watch and participate in the live broadcast by tuning to live.5by5.tv at the appointed time.
The beauty of responsive web design becomes obvious when you see your site in smart phones, tablets, and widescreen desktop browsers. It’s as if your site was redesigned to perfectly fit that specific environment. And yet there is but one actual design—a somewhat plastic design, if you will. An extensible design, if you prefer. It’s what some of us were going for with “liquid” web design back in the 1990s, only it doesn’t suck. Powered by CSS media queries, it’s the resurrection of a Dao of Web Design and a spiffy new best practice. All the kids are doing it.
Well, anyway, some of the cool ones are. See also the newly retooled-per-responsive-design Journal by Mr Hicks. Hat tip: Mr Stocks. I obviously have some work to do on this site. And you may on yours.
Hot dang! Use fluid grids, flexible images, and CSS media queries to create elegant user experiences that fit any browser or device’s viewport. By Ethan Marcotte, co-author of Designing With Web Standards 3rd Edition.
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.
Being colorblind doesn’t mean not seeing color. It means seeing it differently. If colorblindness challenges the colorblind, it also challenges designers. Some of us think designing sites that are colorblind-friendly means sticking with black and white, or close to it. But the opposite is true. Using contrast effectively not only differentiates our site’s design from others, it’s the essential ingredient that can make our content accessible to every viewer, including the colorblind. By understanding contrast, we can create websites that unabashedly revel in color.
We take FAQs for granted as part of our sites’ content, but do they really work, or are they a band-aid for poor content? FAQ-hater R. Stephen Gracey explores the history and usability of FAQs. Learn how to collect, track, and analyze real user questions, sales inquiries, and support requests—and use the insights gained thereby to improve your site’s content, not just to write a FAQ. Find out when FAQs are an appropriate part of your content strategy, and discover how to ensure that your FAQ is doing all it should to help your customers.
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.
On a desktop browser, although it’s not an aesthetically pleasant experience, you can probably read it. On a small iPhone screen, you can’t. It’s a nightmare. It’s everything designers shouldn’t do when they have text by a good writer with an audience of eager readers.
So what’s a reader to do?
Without Readability, there’s nothing you can do, but sigh and close the browser window. With Readability, you can read and actually enjoy what Roger Ebert has to say.
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.
Since 1998, A List Apart has sought to serve the international web design and development community with educational, insightful, and sometimes visionary articles on web standards, emerging ideas and technologies, and best practices in content, usability, and design.
One barrier has long prevented us from fulfilling our goal to the utmost. But today we transcend it. Introducing A List Apart Arabic—an authorized A List Apart publication. Thank you and congratulations to Mohammad Saleh Kayali and his partners.
Look for additional international A List Apart editions, coming soon.
In Issue No. 288 of A List Apart, for people who make websites: Margit Link-Rodrigue advises us to integrate accessibility with front-end development instead of treating it as an afterthought—an item on a checklist. And Joe Clark analyzes why some forms of writing resist being expressed as semantic HTML.
It’s time we came to grips with the fact that not every “document” can be a semantic “web page.” Some forms of writing just cannot be expressed in HTML—or they need to be bent and distorted to do so. But for once, XML can help. Joe Clark explains.
To make accessible design an organic element of front-end development, we must free our thinking from the constraints we associate with accessible design and embrace the inclusion principle. Margit Link-Rodrigue tells us how.
A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to HTML 5 activity leader Ian Hickson’s comment here that, “We don’t need to predict the future. When the future comes, we can just fix HTML again,” Allsopp said “This is the only shot for a generation” to get the next version of markup right. Now Bruce Lawson explains just why HTML 5 is “several different kind of messes:”
It’s a mess, Lawson says, because the process is a mess. The process is a mess, he claims, because “[s]pecifying HTML 5 is probably the most open process the W3C has ever had,” and when you throw open the windows and doors to let in the fresh air of community opinion, you also invite sub-groups with different agendas to create competing variant specs. Lawson lists and links to the various groups and their concerns.
It’s a “spec mess,” Lawson continues, citing complaints by Allsopp and Matt Wilcox that many elements suffer from imprecise or ambiguous specification or from seemingly needless restrictions. (Methinks ambiguities can be resolved, and needless restrictions lifted, if the Working Group is open to honest, accurate community feedback. Lawson tells how to contact the Working Group to express your concerns.)
Most importantly, Lawson explains, HTML 5 is a backward compatibility mess because it builds on HTML 4:
You probably wouldn’t have loads of computer science oriented elements like kbd,var, samp in preference to the structural elements that people “fake” with classes. Things like tabindex wouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, and accesskey wouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.
But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. …
There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.
Damned if you do
The third point is Lawson’s key insight, for it illuminates the dilemma faced by HTML 5 or any other honest effort to move markup forward. Neither semantic purity nor fault-tolerance will do, and neither approach can hope to satisfy all of today’s developers.
A markup based on what we now know, and can now do thanks to CSS’s power to disconnect source order from viewing experience, will be semantic and accessible, but it will not be backward compatible. That was precisely the problem with XHTML 2, and it’s why most people who build websites for a living, if they knew enough to pay attention to XHTML 2, soon changed the channel.
XHTML 2 was conceived as an effort to start over and get it right. And this doomed it, because right-wing Nativists will speak Esperanto before developers adopt a markup language that breaks all existing websites. It didn’t take a Mark Pilgrim to see that XHTML 2 was a dead-end that would eventually terminate XHTML activity (although Mr Pilgrim was the first developer I know to raise this point, and he certainly looks prescient in hindsight).
It was in reaction to XHTML 2’s otherworldliness that the HTML 5 activity began, and if XHTML suffered from detachment from reality, HTML 5 is too real. It accepts sloppiness many of us have learned to do without (thereby indirectly and inadvertently encouraging those who don’t develop with standards and accessibility in mind not to learn about these things). It is a hodgepodge of semantics and tag soup, of good and bad markup practices. It embraces ideas that logically cancel each other out. It does this in the name of realism, and it is as admirable and logical for so doing as XHTML 2 was admirable and logical in its purity.
Neither ethereal purity nor benign tolerance seems right, so what’s a spec developer to do? They’re damned either way—which almost suggests that the web will be built with XHTML 1.0 and HTML 4.01 forever. Most importantly for our purposes, what are we to do?
As the conversation about HTML 5 and XHTML has played out this week, I’ve felt like Regan in The Exorcist, my head snapping around in 360 degree arcs as one great comment cancels out another.
In a private Basecamp discussion a friend said,
Maybe I’m just confused by all the competing viewpoints, but the twisted knots of claim and counterclaim are getting borderline Lovecraftian in shape.
[I] didn’t realize that WHATWG and the W3C’s HTML WG were in fact two separate bodies, working in parallel on what effectively amounts to two different specs [1, 2—the entire thread is actually worth reading]. So as far as I can tell, if Ian Hickson removes something from the WHATWG spec, the HTML WG can apparently reinsert it, and vice versa. [T]his… seems impossibly broken. (I originally used a different word here, but, well, propriety and all that.)
Such conversations are taking place in rooms and chatrooms everywhere. The man in charge of HTML 5 appears confident in its rightness. His adherents proclaim a new era of loaves and fishes before the oven has even finished preheating. His articulate critics convey a palpable feeling of crisis. All our hopes now hang on one little Hobbit. What do we do?
As confused as I have continually felt while surfing this whirlwind, I have never stopped being certain of two things:
That said, the creation of a new markup language concerns us all, and an informed community will only help the framers of HTML 5 navigate the sharp rocks of tricky shoals. Whether we influence HTML 5 greatly or not at all, it behooves us to learn as much as we can, and to practice using it on real websites.
Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009