“IN AN INDUSTRY that extols innovation over customer satisfaction, and prefers algorithm to human judgement (forgetting that every algorithm has human bias in its DNA), perhaps it should not surprise us that toolchains have replaced know-how.”
Our addiction to complicated toolchains and overbuilt frameworks is out of control. Web-making has lately become something of a dick-measuring competition. It needn’t stay that way.
If we wish to get back to the business of quietly improving people’s lives one thoughtful interaction at a time, we must rid ourselves of the cult of the complex. For more about why and how, see my new article, “The Cult of the Complex,” in A List Apart, for people who make websites.
SORRY. I disagree. Nonsemantic classnames that refer to visual styles will always be a bad idea.
I’m sure you’re a good coder. Probably much better than I am these days. I know most of you weren’t around for the standards wars and don’t know how much damage non-semantic HTML and CSS did to the web.
I’ve worked on big sites and I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.
Slapping a visually named class on every item in your markup may indeed make your HTML easier to understand for a future developer who takes over without talking to you, especially if you don’t document your work and create a style guide. But making things easier for yourself and other developers is not your job. And if you want to make things easier for yourself and other developers, talk to them, and create a style guide or pattern library.
The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.
Employers who value quality in CSS and markup will insist that their employees communicate, think through long-term implications, and document their work. Employers who see developers and designers as interchangable commodities will hurry their workers along, resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.
The present is always compromised, always rushed. We muddle through with half the information we need, praised for our speed and faulted when we stop to contemplate or even breathe. Frameworks built on newish worst practices seem like the way out, but they end up teaching and permanently ingraining bad habits in a generation of web makers. Semantics, accessibility, and clarity matter. Reusability is not out of reach. All it takes is clarity and communication.
Ten Years Ago on the Web
2006 DOESN’T seem forever ago until I remember that we were tracking IE7 bugs, worrying about the RSS feed validator, and viewing Drupal as an accessibility-and-web-standards-positive platform, at the time. Pundits were claiming bad design was good for the web (just as some still do). Joe Clark was critiquing WCAG 2. “An Inconvenient Truth” was playing in theaters, and many folks were surprised to learn that climate change was a thing.
I was writing the second edition of Designing With Web Standards. My daughter, who is about to turn twelve, was about to turn two. My dad suffered a heart attack. (Relax! Ten years later, he is still around and healthy.) A List Apart had just added a job board. “The revolution will be salaried,” we trumpeted.
Preparing for An Event Apart Atlanta, An Event Apart NYC, and An Event Apart Chicago (sponsored by Jewelboxing! RIP) consumed much of my time and energy. Attendees told us these were good shows, and they were, but you would not recognize them as AEA events today—they were much more homespun. “Hey, kids, let’s put on a show!” we used to joke. “My mom will sew the costumes and my dad will build the sets.” (It’s a quotation from a 1940s Andy Hardy movie, not a reflection of our personal views about gender roles.)
Jim Coudal, Jason Fried and I had just launched The Deck, an experiment in unobtrusive, discreet web advertising. Over the next ten years, the ad industry pointedly ignored our experiment, in favor of user tracking, popups, and other anti-patterns. Not entirely coincidentally, my studio had just redesigned the website of Advertising Age, the leading journal of the advertising profession.
Other sites we designed that year included Dictionary.com and Gnu Foods. We also worked on Ma.gnolia, a social bookmarking tool with well-thought-out features like Saved Copies (so you never lost a web page, even if it moved or went offline), Bookmark Ratings, Bookmark Privacy, and Groups. We designed the product for our client and developed many of its features. Rest in peace.
In short, it was a year like any other on this wonderful web of ours—full of sound and fury, true, but also rife with innovation and delight.
As part of An Event Apart’s A Decade Apart celebration—commemorating our first ten years as a design and development conference—we asked people we know and love what they were doing professionally ten years ago, in 2006. If you missed parts one, two, three, or four, have a look back.
Position Wanted: Front-End Director
WE have creative directors and design directors, but we don’t seem to have any front-end directors. And maybe we should.
For years at big companies, people in different silos have written CSS with no information or understanding about each other’s work. This results in huge, sloppy files that have a negative impact on site performance, as folks write more and more complex rules trying to override pre-existing ones … or “solve” the problem by adding dozens or even hundreds of classes to their CSS and markup.
Professionals with serious front-end chops have tried to solve the problem by coming up with complex rules and systems which, by the time they filter their way down to less experienced developers, get turned into dogma. Every time I see a front-end article’s comments section rapidly fill with absolute statements about whether it’s okay or not to use id, I recognize that someone’s good idea has turned into somebody else’s religion.
And while I commend my colleagues who craft approaches to CSS that help avoid the inevitable problems large-scale enterprises encounter when many coders in many silos work on many components without talking to each other, I think there may be another way to look at the problem.
We all know having many people in many silos write CSS any old way doesn’t work, unless you consider bloat and poor performance working.
And while restricting how you allow people to write code solves some of these problems, it introduces others: too many class names is just another word for bloat.
So how about following the example of other creative endeavors, and putting a single mind in charge? After all, no matter how many disparate photographers, teamed with how many art directors, work on a given issue of a periodical, there’s always a lead art director who advises, helps plan shoots, and ultimately approves the work. Every orchestra requires a conductor. And no matter how many animators work on a film, there’s always a director. There’s a reason for that.
Imagine shooting a film with no director and no storyboards, in which each scene was written by a different screenwriter, and nobody knew the shape of the overall story. It wouldn’t make a coherent movie, much less a good one. Yet that’s how too many big organizations still approach front-end design and development.
So here’s a thought, big orgs. Instead of throwing a thousand front-end developers at your problem and seeing what sticks, consider creating a front-end director position as empowered as any other director at your organization.
Grid Layout & Flexbox City
CSS GRID LAYOUT is nearly finalized. Which means it’s time for designers and front-end developers to set the flags enabling their browsers to support the new specification, put CSS Flexbox through its paces by using it to create layouts, and see if anything breaks. This way, if anything does break, we’ll have time to tell the framers of CSS Grid Layout what happened, and get the spec (and browser support) fixed before it is released. Once Grid is finalized, it will be too late to fix oversights.
The links below can help you (and me) get up to speed with the new tech:
Though CSS Flexbox is better suited to laying out modules (rather than entire pages—that’s what Grid is for), Phillip Walton has used it to solve a classic CSS page layout problem: Holy Grail layout in Flexbox
RACHEL ANDREW—longtime web developer and web standards champion, co-founder of the Perch CMS, and author of Get Ready For CSS Grid Layout—is my guest on today’s Big Web Show. We discuss working with CSS Grid Layout, how Grid enables designers to “do something different” with web layout, why designers need to start experimenting with Grid Layout now, how front-end design has morphed into an engineering discipline, learning HTML and CSS versus learning frameworks, and the magic of David Bowie, RIP.
FROM THOSE WONDERFUL people who brought you Responsive Web Design, Design Is A Job, Mobile First, plus thirteen additional instant classics of web design and development, here come A Book Apart Briefs: even briefer books for people who make websites. Starting with the immediately useful and illuminating Get Ready For CSS Grid Layout by Rachel Andrew (foreword by Eric Meyer), and Pricing Design by Dan Mall (foreword by Mike Monteiro).
Web design is about multi-disciplinary mastery and laser focus, so we created A Book Apart to cover the emerging and essential topics in web design and development with style, clarity, and, above all, brevity. Every title in our catalog sheds clear light on a tricky subject, and fast, so you can get back to work.
With sixteen classics under our belt, and buoyed by your support over the years, today we take that mission one step further with our new, ebook-only guides to essential fundamentals, of-the-moment techniques, and deep nerdery.
There are no better writer/designers to present these topics. And there are no needless words to waste your time, because these are A Book Apart Briefs: same great writing, even more brief.
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.
CSS & Design: Blending Modes Demystified
IN AN IDEAL world, we’d be able to modify a design or graphic for the web while keeping the original intact, all without opening an image editor. We’d save tons of time by not having to manually reprocess graphics whenever we changed stuff. Graphics could be neatly specified, maintained, and manipulated with just a few licks of CSS. Oh. Wait. We can do that! Justin McDowell gives us the lowdown: read Blending Modes Demystified in today’s A List Apart.
ACUMIN by Robert Slimbach is a new type family from Adobe that does for book (and ebook) designers what Helvetica has always done for graphic designers. Namely, it provides a robust yet water-neutral sans-serif, in a full suite of weights and widths. And unlike the classic pressing of Helvetica that comes on everyone’s computers—but like Helvetica Neue—Acumin contains real italics for every weight and width.
Reading about the design challenges Slimbach set himself (and met) helps you appreciate this new type system, whose virtues are initially all too easy to overlook, because Acumin so successfully avoids bringing a personality to the table. Enjoying Acumin is like developing a taste for exceptionally good water.
Nick Sherman designed the website for Adobe, and its subtly brilliant features are as easy to miss at first look as Acumin’s. For starters, the style grid on the intro page dynamically chooses words to fit the column based on the viewport size. Resize your browser and you’ll see how the words change to fill the space.
Heaps of behind-the-scenes calculation allow the page to load all 90 (!) fonts without breaking your pipes or the internet. Developer Bram Stein is the wizard behind the page’s performance.
Nick uses progressively enhancedCSS3 Columns to create his responsive multi-column layout, incorporating subtle tricks like switching to a condensed font when the multi-column layout shrinks below a certain size. (This is something A List Apart used to do as well; we stopped because of performance concerns.) In browsers like IE9 and earlier, which do not support CSS3 Multiple Column specification, the layout defaults to a quite readable single column. Nick adds:
It’s the first time I’ve used responsive CSS columns for a real-world project. This was both frustrating and fun because the CSS properties for controlling widows and orphans are very far behind what’s possible in InDesign, etc. It also required more thinking about vertical media queries to prevent a situation where the user would have to scroll up and down to get from the bottom of one column to the top of the next. If the viewport is too short to allow for easy reading across columns, it stays as a single column.
We had to do some behind the scenes trickery in order to get the sliders to work for changing widths and weights. It’s a good way to allow people to type their own text and get a feeling for how the family can be used as a system for body text and headlines (unlike Helvetica, which is more limited to the middle range of sizes). Chris Lewis helped out a lot with getting this to work. It even works on a phone!
Book designers have long had access to great serif fonts dripping with character that were ideal for setting long passages of text. Now they have a well-made sans serif that’s as sturdy yet self-effacing as a waiter at a great restaurant. Congratulations to Robert Slimbach, Adobe, and the designers and developers mentioned or interviewed here. I look forward to seeing if Acumin makes it into new website designs (perhaps sharing some of Proxima Nova‘s lunch), especially among mature designers focused on creating readable experiences. And I pray Acumin makes its way into the next generation of ebook readers.
(Just me? In both iBooks and Kindle, I’m continually changing typefaces after reading any book for any period of time. All the current faces just call too much attention to themselves, making me aware that I am scanning text—which is rather like making filmgoers aware that they are watching projected images just when they should be losing themselves in the story.)