Of Patterns and Power: Web Standards Then & Now

IN “CONTENT Display Patterns” (which all front-end folk should read), Dan Mall points to a truth not unlike the one Ethan Marcotte shared last month on 24 ways. It is a truth as old as standards-based design: Construct your markup to properly support your content (not your design).

Modular/atomic design doesn’t change this truth, it just reinforces its wisdom. Flexbox and grid layout don’t change this truth, they just make it easier to do it better. HTML5 doesn’t change this truth, it just reminds us that the separation of structure from style came into existence for a reason. A reason that hasn’t changed. A reason that cannot change, because it is the core truth of the web, and is inextricably bound up with the promise of this medium.

Separating structure from style and behavior was the web standards movement’s prime revelation, and each generation of web designers discovers it anew. This separation is what makes our content as backward-compatible as it is forward-compatible (or “future-friendly,” if you prefer). It’s the key to re-use. The key to accessibility. The key to the new kinds of CMS systems we’re just beginning to dream up. It’s what makes our content as accessible to an ancient device as it will be to an unimagined future one.

Every time a leader in our field discovers, as if for the first time, the genius of this separation between style, presentation, and behavior, she is validating the brilliance of web forbears like Tim Berners-Lee, Håkon Wium Lie, and Bert Bos.

Every time a Dan or an Ethan (or a Sara or a Lea) writes a beautiful and insightful article like the two cited above, they are telling new web designers, and reminding experienced ones, that this separation of powers matters.

And they are plunging a stake into the increasingly slippery ground beneath us.

Why is it slippery? Because too many developers and designers in our amnesiac community have begun to believe and share bad ideas—ideas, like CSS isn’t needed, HTML isn’t needed, progressive enhancement is old-fashioned and unnecessary, and so on. Ideas that, if followed, will turn the web back what it was becoming in the late 1990s: a wasteland of walled gardens that said no to more people than they welcomed. Let that never be so. We have the power.

As Maimonides, were he alive today, would tell us: he who excludes a single user destroys a universe. Web standards now and forever.

Marchgasm!

I’VE BEEN BUSY this month:

And March is only half over.

Lawson on picture element

Those eager to bash Hixie and the WHATWG are using the new spec as if it were a cudgel; “this is how you deal with Hixie and WHATWG” says Marc Drummond. I don’t think that’s productive. What is productive is the debate that this publication will (hopefully) foster.

Bruce Lawson’s personal site: On the publication of Editor’s draft of the element.

HTML5 Video Player II

JOHN DYER’S MediaElement.js bills itself as “HTML5 <video> and <audio> made easy”—and that’s truly what it is:

For complete information, visit mediaelementjs.com.

Hat tip: Roland Dubois.

Leo Laporte interviews JZ

IN EPISODE 63 of Triangulation, Leo Laporte, a gracious and knowledgeable podcaster/broadcaster straight outta Petaluma, CA, interviews Your Humble Narrator about web standards history, responsive web design, content first, the state of standards in a multi-device world, and why communists sometimes make lousy band managers.

HTML Marches On

IN A LETTER dated July 19, 2012, WHATWG leader and HTML living standard editor (formerly HTML5 editor) Ian Hickson clarifies the relationship between activity on the WHATWG HTML living standard and activity on the W3C HTML5 specification. As my dear Aunt Gladys used to say, you can’t ride two horses with one behind.


Facebook goes native

“IF I WERE advising them on these decisions, I would have had them look at what people actually want from Facebook — fast access to their friends’ photos and posts — and … helped them design an HTML5 web experience that actually works for mobile.”

.net magazine: Facebook iPhone app to go native By Tanya Combrinck on June 28, 2012

Publication Standards

ENJOY A LIST APART’S SPECIAL two-part issue on digital publication standards.

Publication Standards Part 1:
The Fragmented Present

by NICK DISABATO

ebooks are a new frontier, but they look a lot like the old web frontier, with HTML, CSS, and XML underpinning the main ebook standard, ePub. Yet there are key distinctions between ebook publishing’s current problems and what the web standards movement faced. The web was founded without an intent to disrupt any particular industry; it had no precedent, no analogy. E-reading antagonizes a large, powerful industry that’s scared of what this new way of reading brings—and they’re either actively fighting open standards or simply ignoring them. In part one of a two-part series in this issue, Nick Disabato examines the explosion in reading, explores how content is freeing itself from context, and mines the broken ebook landscape in search of business logic and a way out of the present mess.

Publication Standards Part 2:
A Standard Future

by NICK DISABATO

The internet is disrupting many content-focused industries, and the publishing landscape is beginning its own transformation in response. Tools haven’t yet been developed to properly, semantically export long-form writing. Most books are encumbered by Digital Rights Management (DRM), a piracy-encouraging practice long since abandoned by the music industry. In the second article of a two-part series in this issue, Nick Disabato discusses the ramifications of these practices for various publishers and proposes a way forward, so we can all continue sharing information openly, in a way that benefits publishers, writers, and readers alike.


Illustration by Kevin Cornell for A List Apart.

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.

Responsive Images and Web Standards at the Turning Point – Mat Marquis in ALA

IN A SPECIAL ISSUE of A List Apart for people who make websites:

Responsible responsive design demands responsive images — images whose dimensions and file size suit the viewport and bandwidth of the receiving device. As HTML provides no standard element to achieve this purpose, serving responsive images has meant using JavaScript trickery, and accepting that your solution will fail for some users.

Then a few months ago, in response to an article at A List Apart, a W3C Responsive Images Community Group formed — and proposed a simple-to-understand HTML picture element capable of serving responsive images. The group even delivered picture functionality to older browsers via two polyfills: namely, Scott Jehl’s Picturefill and Abban Dunne’s jQuery Picture. The WHATWG has responded by ignoring the community’s work on the picture element, and proposing a more complicated img set element.

Which proposed standard is better, and for whom? Which will win? And what can you do to help avert an “us versus them” crisis that could hurt end-users and turn developers off to the standards process? ALA’s own Mat Marquis explains the ins and outs of responsive images and web standards at the turning point.