The Unbearable Lightness of HTML5 – or, the priority of constituencies versus the great dictator

LET’S DIG A BIT DEEPER into the latest conflict between web developers who are passionate about the future of HTML, and the WHATWG. (See Mat Marquis in Tuesday’s A List Apart, Responsive Images and Web Standards at the Turning Point, for context, and Jeremy Keith, Secret Src in Wednesday’s adactio.com, for additional clarification.)

The WHATWG was created to serve browser makers, while its product, HTML5, was designed to serve users first, designers (authors) next, browser makers (implementors) last according to the priority of constituencies, which is one of its founding design principles.

There is a tension between this principle of HTML5 (to serve users above designers above browser makers) and the reality of who is the master: namely, browser makers – especially Google, which pays Hixie, the editor of HTML5, his salary. That’s not a knock on Hixie (or Google), it’s just the reality.

One way the tension between principle and reality plays out is in not uncommon incidents like the one we’re reacting to now. According to the priority of constituencies, designer/developer feedback should be welcomed, if not outright solicited. In principle, if there is conflict between what designer/developers advise and what browser makers advise, priority should be given to the advice of designer/developers. After all, their needs matter more according to the priority of constituencies — and designer/developers are closer to the end-user (whose needs matter most) than are browser makers.

Solicitiation of and respect for the ideas of people who actually make websites for a living is what would happen if the HTML5-making activity had been organized according to its own priority of constituencies principle; but that kind of organization (committee organization) echoes the structure of the W3C, and the WHATWG arose largely because browser makers had grown unhappy with some aspects of working within the W3C. In reality, there is one “decider” — the editor of HTML5, Ian Hickson. His decisions are final, he is under no obligation to explain his rationales, and he need not prioritize developer recommendations above a browser maker’s — nor above a sandwich maker’s, if it comes to that. By design, Hixie is a free agent according to the structure he himself created, and his browser maker end-users (masters?) like it that way.

They like it that way because stuff gets done. In a way, browser makers are not unlike web developers, eager to implement a list of requirements. We designer/developers don’t like waiting around while an indecisive client endlessly ponders project requirements, right? Well, neither do browser makers. Just like us, they have people on payroll, ready to implement what the client requires. They can’t afford to sit around twiddling their digits any more than we can. In 2007, the entire world economy nearly collapsed. It is still recovering. Don’t expect any surviving business to emulate a country club soon.

So, has this latest friction brought us to a tipping point? Will anything change?

In theory, if we are frustrated with Mr Hickson’s arbitrary dictates or feel that they are wrong, we can take our ideas and our grievances to the W3C, who work on HTML5 in parallel with the WHATWG. We should probably try that, although I tend to think things will continue to work as they do now. The only other way things could change is if Hixie wakes up one morning and decides benevolent dictator is no longer a role he wishes to play. If I were in charge of the future of the web’s markup language, with not just final cut but every cut, I’m not sure I’d have the courage to rethink my role or give some of my power away. But perhaps I underestimate myself. And perhaps Hixie will consider the experiment.

Redesigning in Public Again

I FINALLY GOT A COUPLE OF HOURS free, enabling me to do something I’ve been itching to try since I first saw the web on a modern mobile device: redesign this website.

First I cranked up the type size. With glorious web fonts and today’s displays, why not?

Then I ditched the sidebar. Multiple columns are so 1990s.

This site has always been about content first. But the layout was a holdover from the days when inverted L shapes dotted the cyber landscape; when men were men, and all websites bragged two columns, laid out with table cells as the Lord intended.

The previous redesign deliberately hearkened back to the old, old days of this site. It was fun (even if I was the only one who got the joke). But my journey down Retro Lane coincided unfortunately with the first big news in web design since the anchor tag (mobile-first, content-first, responsive, etc). Today’s little design exercise here redresses all that.

This is not a finished work. I may make some things squeeze-y that are now rock-hard. I might lock the viewport and play with padding and things. But the site is now much closer to where I’ve wanted it for the past two years.

Page backward, if you wish, to see how it rolls out so far.


Thanks to Tim Murtaugh, who helped me debug more than one maddening straggler.

Designing Apps With Web Standards (HTML is the API)

The Web OS is Already Here… Luke Wroblewski, November 8, 2011

Mobile First Responsive Web Design, Brad Frost, June, 2011

320 and up – prevents mobile devices from downloading desktop assets by using a tiny screen’s stylesheet as its starting point. Andy Clarke and Keith Clark.

Gridless, HTML5/CSS3 boilerplate for mobile-first, responsive designs “with beautiful typography”

HTML5 Boilerplate – 3.02, Feb. 19, 2012, Paul Irish ,Divya Manian, Shichuan, Matthias Bynens, Nicholas Gallagher

HTML5 Reset v 2, Tim Murtaugh, Mike Pick, 2011

CSS Reset, Eric Meyer, v 2.0b1, January 2011

Less Framework 4 – an adaptive CSS grid system, Joni Korpi (@lessframework)

Responsive Web Design by Ethan Marcotte, 2011

Adaptive Web Design by Aaron Gustafson, 2011

Web Standards Curriculum – Opera

Getting Started With Sass by David Demaree, 2011, A List Apart

Dive into Responsive Prototyping with Foundation by Jonathan Smiley, A List Apart, 2012

Future-Ready Content Sara Wachter-Boettcher, February 28, 2012, A List Apart

For a Future Friendly Web Brad Frost, March 13, 2012, A List Apart

Orbital Content Cameron Koczon, April 19, 2011, A List Apart

Web standards win, Windows whimpers in 2012, Neil McAllister, InfoWorld, December 29, 2011

Thoughts on Flash – Steve Jobs, April, 2010

Did We Just Win the Web Standards Battle? ppk, July 2006

Web Standards: Wikipedia

The Web Standards Project: FAQ (updated), February 27, 2002

To Hell With Bad Browsers, A List Apart, 2001

The Web Standards Project: FAQ, 1998

The Web Standards Project: Mission, 1998

HTML5 at A List Apart

Mobile at A List Apart

Browsers at A List Apart

CSS & Mobile To The Future | Embrace Users, Constrain Design | An Event Apart Seattle 2012 Day II

TUESDAY, 3 APRIL 2012, was Day II of An Event Apart Seattle, a sold-out, three-day event for people who make websites. If you couldn’t be among us, never fear. The amazing Luke Wroblewski (who leads a day-long seminar on mobile web design today) took excellent notes throughout the day, and shares them herewith:

The (CSS) Future is Now – Eric Meyer

In his The Future is Now talk at An Event Apart in Seattle, WA 2012 Eric Meyer talked about some of the visual effects we can achieve with CSS today. Create shiny new visual elements with no images using progressive enhancement and CSS that is available in all modern browsers.

A Philosophy of Restraint
– Simon Collison

In his A Philosophy of Restraint talk at An Event Apart in Seattle, WA 2012 Simon Collison outlined his design philosophy and how he applies it to web projects. Embrace constraints; simplicity and complexity; design aesthetic; design systems as foundations that prepare us for future projects and complexity; affordances and type; focus and content; audit and pause — prevent catastrophic failures and shine a new light on what you’ve learned with each project.

Touch Events – Peter-Paul Koch (PPK)

In his Touch Events talk at An Event Apart in Seattle, WA 2012 Peter-Paul Koch talked about touch support in mobile browsers and how to handle touch events in web development. Includes a ranking of current mobile browsers; interaction modes in mobile versus desktop (mouse) and keyboard — how do we adjust scripts to work with touch?; touch events; supporting modes; event cascade; and “stick with click.”

Mobile to the Future – Luke Wroblewski

Alas, Luke could not take notes on his own presentation. Here’s what it was about: When something new comes along, it’s common for us to react with what we already know. Radio programming on TV, print design on web pages, and now web page design on mobile devices. But every medium ultimately needs unique thinking and design to reach its true potential. Through an in-depth look at several common web interactions, Luke outlined how to adapt existing desktop design solutions for mobile devices and how to use mobile to expand what’s possible across all devices.Instead of thinking about how to reformat your websites to fit mobile screens, attendees learned to see mobile as way to rethink the future of the web.

What’s Your Problem? – Whitney Hess

In her What’s Your Problem? Putting Purpose Back into Your Projects talk at An Event Apart in Seattle, WA 2012 Whitney Hess outlined the value of learning about opportunities directly from customers. Understand the problem before designing the solution. Ask why before you figure out how. There is no universal solution for all our projects, we need to determine which practices are “best” through our understanding of problems. Our reliance on best practices is creating a world of uniform websites that solve no one’s problem. Leave the desk and interact with people. Rather than the problem solver, be the person who can see the problem.

Properties of Intuitive Pages
– Jared Spool

At An Event Apart in Seattle WA 2012, Jared Spool walked through what makes a design intuitive, why some users need different treatment, and the role of design. Current versus acquired knowledge and how to bridge the gap (how to train users, thus making your site or app “intuitive”). Redesigns and how to avoid disaster. Design skills. The gap between current knowledge and target knowledge is where design happens. Why intuitive design is only possible in small, short iterations.


Day III begins in 90 minutes. See some of you there.

Photos: AEA Seattle Flickr pool or hashtags #aea and #aeasea on Instagram.

Big Web Show No. 65 | Tim Brown of Typekit and Nice Web Type

Tim Brown of Typekit and Nice Web Type

IN EPISODE NO. 65 of The Big Web Show (“everything web that matters”), I interview Tim Brown of Typekit and Nice Web Type on where we are with web fonts, real web type in real web context, using Dribbble to develop a tone of voice, how saving small snippets of other people’s content can turn you into a blogger, Samantha Warren’s Style Tiles, molten leading orbital content, pages versus chunks, the type-driven design, web font fallbacks, the connection between leading and font family, transitioning from university work to Typekit, and much more.

Listen to The Big Web Show #65: Tim Brown.

Show Links

Links mentioned in this show are numerous, enlightening, and available for your pleasure.

Subscribe to The Big Web Show

The Big Web Show features special guests and topics like web publishing, art direction, content strategy, typography, web technology, and more. Get episodes delivered to you automatically:

Web type links from an interview with Typekit and Nice Web Type’s Tim Brown

Tim Brown

MY BIG WEB SHOW INTERVIEW with Tim Brown of Typekit and Nice Web Type will be posted tomorrow. Meanwhile, here are some of the links our rapid-fire idea exchanged touched upon:

FacitWeb on Typekit:
https://typekit.com/fonts/facitweb

Responsive typography:
http://nicewebtype.com/notes/responsive-typography/

Modular scales — meaningful numbers for layout:
http://modularscale.com/

More Meaningful Typography:
http://www.alistapart.com/articles/more-meaningful-typography/

Build talk:
http://vimeo.com/17079380

Web Font Specimen:
http://webfontspecimen.com/

Real Web Type in Real Web Context:
http://www.alistapart.com/articles/real-web-type-in-real-web-context/

How I use Twitter:
http://nicewebtype.com/notes/2009/09/01/how-i-use-twitter/

On leaving Vassar:
http://nicewebtype.com/notes/2010/02/05/on-leaving-vassar/

Font Events – Typekit Blog:
http://blog.typekit.com/category/font-events/

Ffffallback – a webfont fallback app:
http://ffffallback.com/

Nice Web Type:
http://nicewebtype.com/

Typekit:
https://typekit.com/

Adobe:
http://www.adobe.com/

The Articulate Web Designer of Tomorrow – 24 Ways:
http://24ways.org/2010/the-articulate-web-designer-of-tomorrow

Orbital Content – A List Apart:
http://www.alistapart.com/articles/orbital-content/

Fonts in Use:
http://fontsinuse.com/

Facit web font:
http://www.myfonts.com/fonts/justanotherfoundry/facit/

Typekit blog:
http://blog.typekit.com/

Nice Web Type:
https://twitter.com/#!/nicewebtype

Build Conference:
http://2012.buildconf.com/

Design by Front:
http://www.designbyfront.com/

Typecast app:
http://beta.typecastapp.com/

Style Tiles – Samantha Warren:
http://badassideas.com/style-tiles-as-a-web-design-process-tool/

Responsive Summit:
http://responsivesummit.com/

Molten Leading – Nice Web Type:
http://nicewebtype.com/notes/2012/02/03/molten-leading-or-fluid-line-height/

Tim Brown on Dribbble:
http://dribbble.com/timbrown/projects

Principles of Typography on the Web:
http://webtypography.net/

Ding dong, SOPA is dead.

DING DONG, THE WITCH IS DEAD. For now, at least, the “ill-conceived lobbyist-driven piece of legislation” known as the Stop Online Piracy Act (SOPA) is no more:

Misguided efforts to combat online privacy have been threatening to stifle innovation, suppress free speech, and even, in some cases, undermine national security. As of yesterday, though, there’s a lot less to worry about.

…Though the administration did [not] issue a formal veto threat, the White House’s opposition signaled the end of these bills, at least in their current form.

A few hours later, Congress shelved SOPA, putting off action on the bill indefinitely.

Political Animal – Putting SOPA on a shelf

State of the web: of apps, devices, and breakpoints

IN The ‘trouble’ with Android, Stephanie Rieger points out the ludicrous number of Android screen sizes on a typical UK client’s website and comes to this conclusion:

If … you have built your mobile site using fixed widths (believing that you’ve designed to suit the most ‘popular’ screen size), or are planning to serve specific sites to specific devices based on detection of screen size, Android’s settings should serve to reconfirm how counterproductive a practice this can be. Designing to fixed screen sizes is in fact never a good idea…there is just too much variation, even amongst ‘popular’ devices. Alternatively, attempting to track, calculate, and adjust layout dimensions dynamically to suit user-configured settings or serendipitous conditions is just asking for trouble.

I urge you to read the entire article—it’s brief yet filled with rich chocolatey goodness.

Responding to it, Marc Drummond concludes that responsive web design default breakpoints are dead and urges designers to “use awkwardness as your guideline, not ephemeral default device widths” and return to fluid design. (I believe he may actually be thinking of liquid layout—the kind we practiced back in the early mid-1990s when cross-platform and multi-manufacturer desktop screen sizes and pixel-per-inch ratios—not to mention strong user font, size, and color preference options—made fixed-width layout design challenging if not impossible. As I understand fluid design, it is merely another word for responsive design, in that it relies on CSS3 media queries set to breakpoints.)

We’ve lost our compass

Rieger and Drummond are hardly alone in feeling that “our existing standards, workflows, and infrastructure” cannot support “today’s incredibly exciting yet overwhelming world of connected digital devices” (futurefriend.ly) and that something new must be done to move the web forward. And of course ppk has been warning us about the multiplicity of platforms and viewports on mobile since 2009.

Agreed: that is an exciting and challenging time; that fixed width layouts do not address, and adaptive layouts (multiple fixed-width layouts set to common breakpoints) do not go far enough in addressing, the challenges posed by our current plethora of mobile screen sizes, zoom settings, embedded views (i.e. “browser” windows inside app windows, often with additional chrome) and what Rieger calls “the unintended consequences” that occur as these various settings clash in ways their creators could not have anticipated.

As consumers, we’ve all had the experience of seeing the wrong layout at the wrong time. (Think of a site with both mobile and desktop versions—whether these versions are triggered by CSS3 media queries or JavaScript and back-end magic is beside the point because technology is beside the point—good user experience is all this is supposed to be about. On a Twitter app on a mobile device, the user follows a link; the link opens in the browser built into the Twitter app. Which version of the site does the user see? The mobile one or the desktop? Often it is the desktop, and that can be a problem if the app’s version of the browser does not permit zoom. Even if it is a mobile version, it may be the wrong mobile version, or it may not fit comfortably inside the app’s browser window.) Considering our own experiences and reviewing Rieger’s chart, it is easy to share Drummond’s conclusion that breakpoints are dead and that all sites should be designed as minimally as possible.

If breakpoints are dead, responsive design is dead

Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on.

But responsive design is not dead; it has only begun. It is not a panacea but was never intended to be. It is simply the beginnings of an approach.

I respect those colleagues who say breakpoints are dead, understand how they reached this conclusion, and am eager to see where it takes them in the coming months as they experiment with new methods, perhaps developing wonderful and unforeseen best practices. I hope design will be a brilliant part of these new methods, not something that gets abandoned to create a bland but workable lightweight experience for all.

But I also believe it is possible to draw a different conclusion from the same data. It is even possible, I believe, to say the present data doesn’t matter—at least not in the long run.

Tale of the chart

There was a time in the late 1990s when industrious web designers showed how atrocious CSS support was in browsers. Eric Meyer’s Master Compatability Chart for Web Review, formerly at http://www.webreview.com/pub/wr/style/mastergrid.html, was one of the best, but is no longer available for your historical viewing pleasure—not even at the mighty Wayback Machine. That’s too bad, as it would have perfectly illustrated my point. The chart used a variety of colors to show how each detail of the entire CSS specification was or was not supported (and if supported, whether it was supported correctly and completely, partially and correctly, partially and somewhat incorrectly, or completely incorrectly) in every browser which was available at the time, including, if memory serves, close to a dozen versions of Netscape, Explorer, and Opera.

Looking at that chart induced nausea and vertigo. It was easy to draw the conclusion that CSS wasn’t ready for primetime. (That was the correct conclusion at the time.) It was also easy to look at the table and decide that table layouts and font tags were the way to go.

That’s what most designers who even bothered looking at Eric’s chart decided, but a few (Eric and me included) drew a completely other inference. Instead of trying to memorize all the things that could go wrong in each browser, we created general rules for what worked across all browsers (e.g. font-size in px, floats for layout) and advocated design based on the things that work. This, I believe, is exactly what the futurefriend.ly and Move the Web Forward folks are doing now: trying to figure out commonalities instead of bogging down in details. (This is why some in our community have labeled futurefriend.ly and Move the Web Forward “WaSP II.”)

The other inference Eric, I, and others in the 1990s drew from Eric’s chart was that browser makers must be petitioned to support CSS accurately and correctly. We and many of you reading this engaged in said petitioning, and thanks largely to help from with the browser engineering community (from people like Tantek Çelik and Chris Wilson and organizations like Mozilla) it came to pass.

Of mice and markets

We cannot, of course, petition all the makers of, say, Android devices to agree to a set of standard breakpoints, because there are over 500 different Android devices out there, many of which will fail in the coming months—or if not outright fail, simply be replaced in the course of planned obsolescence AKA upgrading that drives the hardware segment. And each new product will in turn introduce new incompatibilities (AKA “features”).

In the short run it’s going to be hell, just as the browser wars and their lack of support for common standards were hell. But it is the short run.

500 standards is no standard. Give a consumer 500 choices and the price-driven consumer picks what comes with her plan, while the selective consumer begins gravitating toward a handful of emerging market leaders. Eventually this nutty market will stabilize around a few winning Android platforms (e.g. Kindle Fire) and common breakpoints will emerge. What The Web Standards Project achieved with browser makers, the market will achieve with phones.

Until that time, designers certain can abandon breakpoints if they can find a way to do good design under purely fluid conditions—design that pleases the user, satisfies the client, and moves the industry forward aesthetically. But designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports. This I believe.

When I see fragmentation, I remind myself that it is unsustainable by its very nature, and that standards always emerge, whether through community action, market struggle, or some combination of the two. This is a frustrating time to be a web designer, but it’s also the most exciting time in ten years. We are on the edge of something very new. Some of us will get there via all new thinking, and others through a combination of new and classic approaches. Happy New Year, web designers!

OFF MY LAWN!

IT IS NOT “IRONIC” when an article about web standards is published in an online magazine formatted in Flash, or PDF, or some other non-HTML format. It is not “ironic” when an article on responsive design appears on a website that is not responsively designed. It is not “ironic” when an article on three essential principles of usability appears on a website that violates all three principles. It is not “ironic” when an article bemoaning the overuse of “Share” buttons appears on a website that overuses “Share” buttons. It is not “ironic” when an article advocating long form reading on the web gets chopped into multiple pages that discourage reading for the sake of a few ad views. It is not “ironic” when an article about microformats appears on a site that does not use microformats. It is not “ironic” when an article advocating HTML5 appears on a website formatted in XHTML. It is not “ironic” when an article about web accessibility appears on a website that suffers from serious accessibility problems. It is not “ironic” when an article about the importance of proper semantic markup appears in a magazine whose markup would make a goat cry. It is not “ironic” when an article about progressive enhancement and unobtrusive scripting appears on a website that fails if the user disables JavaScript.

It is publishing. It is humanity. It is the vanguard of ideas clashing against the rearguard of commerce. This is not new. This is all to be expected. We must stop raising our eyebrows and chuckling at it. We must decide to accept the world as it is, or to roll up our sleeves and help.