A liquid page will resize to fit whatever size browser window (within reason) that the user has available. … the real goal in building a website is to provide the user with a seamless interface to information. The site should not intrude on the user’s thought processes, but should gently guide them to their desired destination. If a site doesn’t look right because it doesn’t fit the user’s browser window, then the design has become intrusive to the user. — Glenn Davis, quoted in 15 Minutes, sometime in 1997.

TWO DECADES before Responsive Web Design, we dipped our toes in Liquid Layout — a similar but necessarily less refined concept. Glenn Davis of Project Cool fame coined the phrase in 1995 or 1996. (Glenn also came up with “Ice” to describe fixed-width layouts, and “Jello” for layouts that combined some fixed with some flexible elements.)

Liquid Layout was mainly what John Allsopp had in mind when he wrote A Dao of Web Design for A List Apart (quite possibly the most influential article we ever published). The most famous paragraph in that famous article explains…

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things.”

EVERYTHING NEW IS OLD

Modern designers look back at Allsopp’s article and think John must have been a time traveler who had seen the future of responsive design and mobile devices. In fact, though, John was simply a highly skilled (and extremely articulate) mainstream developer. As such, he was familiar with Liquid Design and frequently used it in his work, along with other ideas mentioned in “Dao,” such as not forcing users to see a particular type size or typeface. To a good developer in those days, what mattered was making something that worked for everyone. (That should still be what good developers care most about, right?)

Liquid design was part of a “works for everyone” approach to web design, but it had limitations. For one thing, breakpoints hadn’t been invented. CSS layout was in its infancy, used by almost no one, except in experimental work. The ability to separate content and behavior from presentation was nonexistent, unless you limited “presentation” to setting type in a single column, letting the user override the type setting, and letting the column reshape itself to fit any viewport.

With so few controls available, Liquid design tended to become unusable in certain settings, and was almost always ugly.

LIQUID DESIGN WAS RESPONSIVE DESIGN’S ROUGH DRAFT

Liquid design was immediately popular with developers when they were given permission to just make stuff — i.e. when they weren’t constrained by overly rigid Photoshop layouts. Designers almost never used Liquid design because the layouts moved so quickly into ugliness and unusability — too wide to read, or too narrow, or with overlapping columns in early CSS layouts. Designers also disdained Liquid layouts because most of us see our job as imposing brilliant order on ugly chaos, and fixed proportions always seemed to be part of that order.

Ugly on one side. Unusable on the other. It took a special breed of designer to forge ahead with Liquid Layout anyway.

Were it were not for the iPhone and the phones and tablets that rose quickly in its wake, the W3C would likely not have invented breakpoints. And without breakpoints, there could be no Responsive Web Design. And without Responsive Web Design, created by a visually gifted designer and with tools to satisfy his peers, the idea that drove Liquid design back in the 1990s would not, at long last, have caught on.

It’s easy to view our current design thinking as more evolved than what we practiced in the past. And in some ways, it is. But if you read between the lines, it’s fair to say that our thinking was always advanced. It’s only now that our tools are beginning to catch up.

READ MORE ABOUT LIQUID AND RESPONSIVE WEB DESIGN

• A Dao of Web Design by John Allsopp, A List Apart, April 2000
• Liquid Web Design: Build it right and it will work no matter what the container, by Nick Finck, Digital Web, August 1999
• What is Liquid Design? by Nick Wilson, November 2002
• Flexible Foundations by Trent Walton, 2013

☞ Illustration by Justin Dauer. Follow me @zeldman. A version of this article appears on zeldman.com. The 11th Annual Blue Beanie Day in support of web standards takes place November 30 on the internet.

A Dao of Responsive Liquid was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.

I HADN’T heard from her in years. Suddenly, there she was in my in-box. Tentatively proposing coffee. Maybe lunch. A dam broke inside me, releasing a flood of warm memories. Our first, tentative contact ten years or more ago. Getting to know each other. Endless, happy discussions about where this thing was going. Coming together on goals and brand; on voice and tone. Finally, the joy of designing and launching her website. And then, abruptly, the last invoice and the hurried departure.

My former client. She had a new job now. She wanted to catch up. And, sheepishly, she admitted, she might want something more. Advice about a design problem.

Over an unassuming wooden table laden with summer lunch — mine was Ramen, hers was salad — we shared personal updates. Kids, relationships, projects. And then we got down to the real agenda: an issue at work that was stumping her. Desire for an outside perspective.

Former clients often feel slightly embarrassed about reaching out for a little free advice. They shouldn’t. As a designer, one of my greatest joys is to reconnect with good people whose projects I loved working on. Design is a job, but it’s also a relationship. When design is going well, the exchange of ideas is almost addictively exciting. And then, all too soon, the project ends, and, if you’re a consulting designer, and you’re lucky enough to have a steady stream of business, you move on to the next gig.

We designers have built-in forgetters: super powers that enable us to care passionately about the problem we’re solving and the people we’re solving it for, and then, absurdly, to discard those feelings as we move on to the next client and design problem.

Clients have a built-in forgetter too. They forget that our relationship, although partly monetary, was also very real. Many clients are self-conscious about reconnecting personally and asking for a small favor in the same breath. But I couldn’t welcome that more. If I can help people, it’s a joy to me. Collaborating on the discovery and solution to a problem isn’t just a stimulating mental exercise and a profession: it’s also a codependent rush.

Between the cracks of my studio’s bigger projects, I’m always looking for ways to help people. So, in the spirit of Ask Dr Web, I’m taking this opportunity to issue an invitation to folks located in or visiting New York. If you’re someone in my network — a former client or old friend or both — with a design problem to mull over, you don’t have to do the mulling alone. Ping me. And let’s do lunch.

Also published at zeldman.com.

I’m Jeffrey. I publish A List Apart Magazine and A Book Apart—“brief books for people who make websites”—and co-founded An Event Apart: three days of design, code, and content for web & interaction designers. Most recently, I opened the NYC design studio.zeldman. Follow me @zeldman. Let’s work together!

It’s just lunch. was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the beginning you went to school to match a curriculum to your passions. You deconstructed, merged theory with approach, and created layout from nothingness. And you saw it was good.

And you said, “I’ll continue this journey professionally.” With a career and a company Mac you designed and problem solved visually, leveraging your studies, intellect, and natural ability. You had a deep-seeded need to create with your hands that had to be fulfilled. And it was so.

And you said, “I want to continue to grow.” Over time from role-to-role there was an evolution both within, and in organizational seniority: junior-to-mid, mid-to-senior, senior-to-management. Now with a team of your own, a responsibility toward the growth of others began to comprise the majority of your time and energy.

And it felt…strange. It felt different.

An Evolution

When a parent welcomes their first child, there’s a moment of crystal clear learning: it’s no longer all about you. Though your own needs still must be tended to and respected, reward was now also distinctly — vitally — obtained through the growth and development of another. As that notion applies to your vocation, this realization is a personal, and career, milestone.

How does a painter transition to gallery owner / curator and remain fulfilled?

When I was a fledgling manager I noticed I had developed a gradual sense of emptiness. I would come home from a day’s work feeling unfulfilled. My days had become less inclusive of hands-on design the more I built out the team. I tremendously enjoyed, and valued, working with them to strengthen their work and provide for a phenomenal creative culture in which to thrive. But my mind hadn’t yet made the switch on letting go (of hands-on design), and refocusing my sense of creative reward. Always one to have a personal design project (or three) going, I found my “creative thirst” was still primarily being satiated through those after-hours initiatives.

How does a lead guitarist transition to producer and remain fulfilled?

All of this is a natural reaction, following years of personal identity and fulfillment that had been directly associated with hands-on design work. The 5th stage of grief in the Kübler-Ross model is acceptance; effectively embracing and owning the future. While “grief” isn’t the exact relational concept for what we’re talking about here, the recognition and respect of your career’s evolution is a more apt thematic takeaway. It may ultimately be inclusive of a eureka moment, but is actually a gradual shift in practice.

A Commonality

This is a theme I’ve chatted about with numerous peers in various forms of media, and one that’s well-resonated. Industry-agnostic, a Gallup poll from 2014 cited that 55% of workers in the U.S. obtain their sense of identity through their job. That’s over half of the 6.5 million people employed in the tech industry¹ alone who would likely associate self-image with their role.

In a previous position of mine, a team member who had recently ascended to management level (of our front-end developers) and I would go out for regular coffee breaks to touch base. Topics varied across how supported they were feeling in their responsibilities (by me), how their team’s energy was doing, if they had any issues to cite, etc.

A brilliant and passionate developer themselves, this person noted one afternoon chat that they realized they were coding less and less. It was something they genuinely enjoyed doing, improving at, and valued the sense of reward obtained through programmatic problem solving. They were feeling a bit thrown off by losing that part of their day (and self).

I began to set their expectations moving forward:

“With each person you hire, anticipate your direct involvement in hands-on development to continue to decrease by at least 25%.”

In the moment, the percentage was fairly arbitrary; the notion that a transition was already in progress, and would continue toward an eventuality of totality, was more important to convey.

We talked through the transition of fulfillment; how a sense of career reward ultimately evolves from hands-on creator to facilitator and teacher, and via imparting guidance from experience. And it is immensely rewarding — and a equally massive responsibility — to help foster and grow the passions of others. Once you realize the gift your career has yielded you, your sense of fulfillment will in fact be amplified.

An Honor

Designer or developer, it’s important to never lose the part of yourself that craves hands-on creative problem solving. In the office, a leader who “isn’t afraid to get their hands dirty” in contributing is one that’s valued. If time and responsibilities sometimes afford doing good work in that capacity, seize it. And if that’s not realistic, personal creative outlets are always available a night on the couch away. Evolving to the role of mentor and having your hands in motion needn’t be mutually exclusive.

How does a painter transition to gallery owner / curator and remain fulfilled?
By discovering other talented artists, promoting their work, and supporting their journey. And by still painting.

How does a lead guitarist transition to producer and remain fulfilled?
By leveraging a career’s experience in the studio to help other musicians achieve their vision. And by still playing.

In the end, at the office it’s about embracing a career’s evolution, and honor, to support your team’s passion toward their craft. And it’s about owning your responsibility to their successful output; leveraging your experience to their creative advantage and the betterment of the work you’re all producing.

¹ “United States Tech Industry Employs 6.5 Million in 2014”, CompTIA.org

The Transition of Fulfillment was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.

I wasn’t really comfortable in making it 40 minutes about what I and my friends thought. At this point I’m not representative, and neither are many of my friends who also speak. Many of us consider speaking and workshop leading as part of our businesses, part of our professional work. That makes us quite different to someone who perhaps speaks once or twice a year, at conferences that have grown from a community they are active in. To try and gain wider insight I put a survey online, and I am so glad that I did. Over 200 people completed the survey, 168 completed it fully. They ranged from people who have spoken at a single conference up to 100 conferences in the last 12 months.

Key Discoveries

Most people were hugely positive about their experiences as speakers. The survey was full of stories of helpful organisers going the extra mile to help out speakers.

The things people loved most were free or inexpensive for organisers to do

I’ve been asked on a number of occasions by friends who are organising conferences what sort of gifts they should give speakers, or do they need to do a flashy speaker dinner. I’ve always said no, gifts are completely optional and if you do them, something small and thoughtful is best. Speaker dinners are a great way to meet other speakers — especially if you are new to speaking — and also for organisers to check in with speakers, however they definitely don’t need to be expensive. If anything the environment, somewhere not too noisy, and holding the dinner not too late are the important things.

This was the general agreement in the survey, people were thrilled to receive practical items such as an umbrella as rain was forecast, sim cards and travel tickets. Successful speaker dinners were those where people got to meet and chat with other speakers — the actual content of the meal was rarely mentioned other than a note about food preferences and allergies being taken care of.

Standout experiences were most often due to small thoughtful gestures and good organisation. Spend time and thought rather than money and it is noticed and appreciated!

Focus energy on your newest speakers

The people who most need your help are the newest and least experienced of your speakers. If you invite someone like me to your conference, as long as I have the setup I was told I would have and the hotel isn’t completely awful (basic is fine, filthy or insecure is not) then I’ll show up and do my thing. I’m used to travel, used to being in cities where I don’t speak the language, I’m not really out of my comfort zone doing this. In addition if you speak at a lot of conferences you get into a position where you really do have “friends in every city”. I usually have friends attending or speaking at the conference, and if not help is often only a tweet away! That’s probably going to be the case for many of your experienced speakers who do this as part of their job.

For new speakers, this may be an experience where they are out of their comfort zone on many levels. Even before they give their talk, they may be far less used to travel and everything that goes with it. They may also not want to “make a fuss”, and talk to you about a problem with their hotel or travel. These are the people you should be making most efforts for, rather than worrying about your big names.

Paying travel and Expenses is a Diversity and Safety Issue

The previous point really leads onto this. We all want to encourage more diverse line-ups at our conferences, however commitment to diversity cannot end there. If you want to encourage a truly diverse line-up, then you are going to be bringing in speakers who are not only from different genders or ethnicities but hopefully also from different backgrounds. Not all of those people are going to:

• own a credit card
• be able to give your conference a loan by paying for travel up front and expensing it
• be used to travel
• have friends at the event
• have spare cash to fund safe cab rides, rebook travel, or bail on a dodgy hotel
• have the confidence to tell you this stuff, especially if they are just thrilled to have been asked to speak at all

The shocking thing about my survey is that there was more than one response that detailed a time in which that person had been put into an unsafe situation, because they did not have money to pay for a cab back from a conference organised event to their hotel.

This was something I had never imagined would come up. I’d expected the negatives in the survey to be dodgy A/V, lack of wifi and the occasional hotel horror story. Not stories of assault and of seriously unpleasant situations. I’m still personally processing how to deal with that, and the fact that I was unaware that this was happening to people, perhaps has happened to people at events I’ve been at. I never stand on stage and shake, but when I read one of these quotes to the ConfConf audience I really felt like I was trembling from head to foot. As I said at the event, I would rather I was never offered a speaker gift again and instead organisers made sure that the personal safety of each and every speaker was taken care of as they get to and while they are at your event. Make sure everyone has food they can eat and safe travel to and from any events. This should be the priority long before money is spent on speaker dinners, gifts or anything else.

Sharing the data

When I put the survey online I said I would share the data more widely than just the conference. I have started to do this with a website that I pretty much built while on a variety of plane journeys. I’ve now got half of the quotes and data online. To be completely honest when I put the survey online I thought I might get 50 responses at most so there were a lot of open ended questions. If anyone is good at wrangling that sort of data and wants to help, I’d be very grateful! I think there are a lot of interesting things to draw out — I’ve not even touched the information about CFPs and so on. However if not I will continue to add quotes as I have time. I’ve initially concentrated on the more positive statements and kudos (as these are easier to post without spending time anonymising data).

I think this site is potentially as useful to speakers as it is to organisers. You can see the sort of things that can happen, and what people expect. Use that as a basis if you feel you are not being treated fairly by an event.

Take a look at the Publicly Speaking site, you will find my slides from ConfConf there or you can see those directly on SlideShare.

Originally published at rachelandrew.co.uk on May 27, 2016.

A List Apart (ISSN: 1534–0295) explores the design, development, and meaning of web content, with a special focus on web standards and best practices.

What I Learned From Posting a Survey of Conference Speakers was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s always interesting to see themes emerge during an event, especially when those thematic overlaps haven’t been planned in advance. Jen noticed this one:

Jen Simmons on Twitter

The theme of this year's AEA (ideas emerging across talks) - do not just do a thing on your project because others do on theirs. #aeasea

I remember that being a theme at An Event Apart San Francisco too, when it seemed like every speaker had words to say about ill-judged use of Bootstrap. That theme was certainly in my presentation when I talked about “the fallacy of assumed competency”:

1. large company X uses technology Y,
2. company X must know what they are doing because they are large,
3. therefore technology Y must be good.

Perhaps “the fallacy of assumed suitability” would be a better term. Heydon calls it “the ‘made at Facebook’ fallacy.” But I also made sure to contrast it with the opposite extreme: “Not Invented Here syndrome”.

As well as over-arching themes, it was also interesting to see which technologies were hot topics at An Event Apart. There was one clear winner here — CSS Grid Layout.

Microsoft — a sponsor of the event — used An Event Apart as the place to announce that Grid is officially moving into development for Edge. Jen talked about Grid (of course). Rachel talked about Grid (of course). And while Eric and Una didn’t talk about it on stage, they’ve both been writing about the fun they’ve been having having with Grid. Una wrote about 3 CSS Grid Features That Make My Heart Flutter. Eric is documenting the overall of his site with Grid. So when we were all gathered together, that’s what we were nerding out about.

There are some great resources out there for levelling up in Grid-fu:

• Jen’s experimental layout lab shows what’s possible.
• Her exercises in Codepen are a great way to test your knowledge of Grid.
• So is CSS Grid Garden.
• Rachel’s extensive Grid by Example is the perfect way to find the Grid solution to your layout scenario.

With Jen’s help, I’ve been playing with CSS Grid on a little site that I’m planning to launch tomorrow (he said, foreshadowingly). I took me a while to get my head around it, but once it clicked I started to have a lot of fun. “Fun” seems to be the overall feeling around this technology. There’s something infectious about the excitement and enthusiasm that’s returning to the world of layout on the web. And now that the browser support is great pretty much across the board, we can start putting that fun into production.

This was originally posted on my own site.

A List Apart (ISSN: 1534–0295) explores the design, development, and meaning of web content, with a special focus on web standards and best practices.

Getting griddy with it was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.

AS THE HEAD of a newish design studio, I spend a fair amount of time writing proposals. And here’s how I like to do it.

I do it like a conversation, and that’s how we start: with phone calls and emails to one or two key decision makers, followed by a research period of about two to three weeks. And when I say research, what I’m really talking about — besides the usual competitive analysis, analytics, and testing — is even more conversations, but this time with a wider net of stakeholders and customers.

Some studios do this for free, and other studios only do it if the client has signed off on a huge project and paid the first big deposit. But we do this research for a fee. A small, reasonable, consulting fee. If the client then hires us to do the job, we deduct the research fee from the project cost. If they don’t, they’ve gained a lot of great information at a fair cost. (So far, they’ve never not hired us to go on and do the project.)

FROM INTAKE TO IDEAS

About two and half weeks into the research project, we have a strong idea of what matters most to the business and its customers, and we begin to have visions of solutions and innovations, large and small. We can’t help it. We’re interaction designers and it’s how our minds work.

After soaking in a potential client’s world for two-plus weeks, we can’t help beginning to invent designs that solve some of their big and small problems, and that enhance what’s already great about the client and their product. This happens in our heads whether we want it to or not.

At first, we are merely neutral listeners, forcing ourselves not to solve, not to imagine, but only to truly hear and understand. But within about fifteen days, we can’t help but begin imagining little modules and big sections, huge themes and tiny, innovative enhancements, which might please and help our client, their customers, or their staff. And so long as those ideas come from the product, come from what the client and their customers have told us, we feel free to begin sharing them.

THE FIRST DESIGN IS WRITTEN

We do that by writing a report where we share with the client what we’ve begun learning and thinking about their business. Although this report is structured like a business document, we think of it as the first part of design — the first written rough draft of articulating what the client’s business needs to do, and how design might help.

Because it’s a business document, and because we’re workers, not magical pixies, we share facts and data and things stakeholders and customers have said that ring true and that harmonize with other things other stakeholders and customers have said. But all that mustering of facts and data is in the service of a shared creative awakening to the design’s possibilities.

START UGLY TO STAY HONEST

Now let me tell you how we present our findings: we present them in a Google Doc that the client can access, share, and comment on. We know that many design studios spend much energy visually tarting up even their most basic client communications. Thus, even a humble invoice comes dressed for the prom.

But we don’t do that. We save aesthetics and beauty for the site design. We keep communications open and plain, like an Amish shirt. And we keep communications editable, because this is collaboration, this is conversation, this is not a dead artifact, a take-it-or-leave-it. And Google Docs is the perfect vehicle for it. Just as the traditionally formatted typewritten screenplay is the perfect, neutral vehicle for a writer to share with a director.

This initial research report, this poem of business, this first, rough, written design, presented to the client via the homey simplicity of Google Docs, elicits more client/designer conversation, more emails, more Basecamp posts, more internal discussions in the studio.

And then, after about a week, we present the client with our proposal. Which is clearly the product of all our conversations, and particularly of all the important agreements we reached during that research period. By the time our clients receive the proposal, they are already nodding, as if they always knew what it contained. Because, in a way, they did. Because, if we did our research right, we’ve merely externalized and articulated what they already felt but had not expressed.

And even now, when we’re asking for serious money to do a serious job, we submit our proposal via Google Docs — because prettified, overly branded proposals are about the studio that produces them, whereas our work is about the client and their product. Because even the most painstakingly researched and written proposal, if it is too pretty and too studio-branded, feels like boilerplate, whereas an ugly Google Doc is clearly just work, to be modified or agreed to or argued about.

This is just what we do at our studio. You can try it or not. Personally, I like this approach and I’ve never had a client complain. I’ve always felt a little dirty when presenting a pitch that was too visually polished, and I’ve never won a single gig with boilerplate. Every job has to be earned by studying and understanding and knowing how to share what you’ve understood. At least, that’s how we do it.

I’m Jeffrey. Follow me @zeldman. I publish A List Apart Magazine and A Book Apart “for people who make websites,” and co-founded An Event Apart: three days of design, code, and content for web & interaction designers. Most recently, I opened the NYC design studio.zeldman. Let’s work together!

A List Apart (ISSN: 1534–0295) explores the design, development, and meaning of web content, with a special focus on web standards and best practices.

How We Write Proposals in My Design Studio was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.

@gabrieldance @digidave @pilhofer would love some suggestions and readings "why CMS' matter to newsrooms/content in student-friendly prose.

Once while going back and forth with a developer over CMS priorities I was told “hey, do I come to your team and tell you how to write stories.” My response was “yes, that’s exactly why we are discussing the CMS features.”

Technical features of a CMS dictate editorial. It’s as simple as that.

Almost everyone intuitively understands this when they think about the CMS’ they engage with on the daily. We don’t classify Facebook’s compose box as a CMS, but that’s what it is. It’s an “open” CMS where anyone can get functionality by signing up.

Most newsrooms have a “closed” CMS and only employees have access. But let’s focus on the open CMS’s for now, since they are a common technological touchstone.

The difference between Twitter and Instagram is ALL in the CMS. One starts with text, limits you to 140 characters and over time has allowed you to include multimedia. The other starts with a picture and you can add text only as a comment, but you have unlimited characters in those comments.

This is why we recognize an Instagram post for what it is and a Tweet for what it is. Take the design away and I suspect people would still be able to recognize which platform a piece of content was published with — because it fits the CMS better. That is called “Platform Intelligence.”

What is ‘Platform Intelligence’ — Embrace the constraints

Technology and editorial are two sides of the same coin. If you want to do something unique from an editorial front, you may have to create a custom CMS.

When Circa wanted to “atomize the news” that meant creating a CMS where “the article” was not the base of production.

While I’ve never seen “Chorus” the CMS of Vox, I’m confident the “Stacks” feature that was heralded when Vox launched was a core feature of the CMS.

Conversely, if you change something on the CMS, that will have an impact on editorial.

If Twitter changed its compose box to have no character limit, the “editorial” tone of Tweets would change. When Instagram allowed for 15 second videos, the nature of the content changed. Same for any change made on Facebook, Snapchat, etc.

If you are in the business of editorial, you must understand the publicly available CMS’s (social networks) and how they shape tone, content. This is a great opening to think about your own news organizations CMS and how it dictates the content your organization produces.

Another analogy: 50 years ago a reporter would work on a story. He/She would go back/forth with their editor and after a few rounds, it would be passed on to a copy editor and finally a page designer.

The page designer is really the first person to think about “product.” They were the first to really engage with a “CMS” (the analogue CMS for print at least). The reporter was divorced from this and really didn’t care besides hoping their content was as close to the front page as possible.

Today, the reporter, through the CMS, touches the product. It started with WYSWIG editing (‘what you see is what you get’) but has evolved from there.

Where you decide to publish, if a choice, should reflect the editorial you want to accomplish. Imagine if I tried to respond to Nikki on Snapchat!?!?

The features you fight for in a CMS reflect your future editorial aspirations.

A List Apart (ISSN: 1534–0295) explores the design, development, and meaning of web content, with a special focus on web standards and best practices.

The CMS is your first editor was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.

Usually I change the class of some HTML element like this:

<!--STARTING HTML-->
<p id="element-id" class="old-class">Some arbitrary text</p>

//Javascript
var htmlElement = document.getElementById(“element-id”);
htmlElement.className = “new-class";

<!--RESULT HTML-->
<p id="element-id" class="new-class">Some arbitrary text</p>

Recently I had occasion to implement something similar with an SVG Element. My goal was for a certain circumstance to display an SVG line on the HTML page. I did this by creating an SVG line on my HTML page with a class “invisible” The invisibility I set in css like so .invisible{display:none}

Easy peasy, I thought I could use my usual strategy (see above) to wipe out the invisible class and therefore show the SVG line. In other words, I thought this would work:

<!-- STARTING HTML -->
 <svg id ="svg-parent" class = "invisible" height="210" width="500">
  <line id = "line-one" class = "invisible" x1="15" y1="15"   x2="300" y2="300"/>
  <line id = "line-two" class = "invisible" x1="15" y1="300" x2="300" y2="15"/>
</svg>

// JAVASCRIPT
//display svg line of element described by function parameter
 var svgParent = document.getElementById(“svg-parent”);
 var svgElement = document.getElementById("line-one");
 svgParent.className = “”; //remove class "invisible"
 svgElement.className = “”; //remove class "invisible"

<!-- EXPECTED RESULT-->
 <svg id ="svg-parent" class = "" height="210" width="500">
  <line id = "line-one" class = "" x1="15" y1="15"   x2="300" y2="300"/>
  <line id = "line-two" class = "invisible" x1="15" y1="300" x2="300" y2="15"/>
</svg>

<!-- ACTUAL RESULT (no change)-->
 <svg id ="svg-parent" class = "invisible" height="210" width="500">
  <line id = "line-one" class = "invisible" x1="15" y1="15"   x2="300" y2="300"/>
  <line id = "line-two" class = "invisible" x1="15" y1="300" x2="300" y2="15"/>
</svg>

In other words, it didn’t work, nothing happened. Upon further investigation in the console

console.log(svgParent.className )

//expected console result
invisible

// actual console result:
SVGAnimatedString {} ..

Well that’s goofy.

I struggled finding much information on this behavior. A few people were saying jQuery was doing jack with classes on SVG elements, but otherwise silence.

Thank god I found this guy and his never-upvoted post

The answer is really freaking simple. Grab the base value of the SVGAnimatedString with a simple .baseVal added to the end of .className.

Here is what finally worked:

// JAVASCRIPT
//display svg line of element described by function parameter
 var svgParent = document.getElementById(“svg-parent”);
 var svgElement = document.getElementById("line-one");
 svgParent.className.baseVal = “”; //remove class "invisible"
 svgElement.className.baseVal = “”; //remove class "invisible"

<!-- ACTUAL RESULT-->
 <svg id ="svg-parent" class = "" height="210" width="500">
  <line id = "line-one" class = "" x1="15" y1="15"   x2="300" y2="300"/>
  <line id = "line-two" class = "invisible" x1="15" y1="300" x2="300" y2="15"/>
</svg>

In case you’re curious about the application of this:

MDN Reference

Modify SVG element classes with JavaScript was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been using this technique since an ex-colleague introduced me to it in early 2015, but the disconnect between maintaining multiple lists was starting to bug me.

So, I’ve come up with a variation which uses Sass maps and lists, and allows me to clearly see the hierarchy of the different elements.

The Sass function

@function z-index($key1, $key2: null) {
    $map: $z-indexes;
    $found-index: null;

    @if (map-has-key($map, $key1)) {
        $found-index: index(map-keys($map), $key1);

        @if ($key2) {
            $map: map-get($map, $key1);
            $found-index: index($map, $key2);
        }
    }

    @return $found-index;
}

@function z($key1, $key2: null) {
    @return z-index($key1, $key2);
}

Our CSS

Then, we set up a $z-indexes map like so:

$z-indexes: (
    main: (
        foo,
        bar,
        tooltip
    ),
    header: (),
    modal: ()
);

and we can use it with:

/* .header */
.header { z-index: z(header); }

/* .main elements */
.main { z-index: z(main); }
.foo { z-index: z(main, foo); }
.bar { z-index: z(main, bar); }
.tooltip { z-index: z(main, tooltip); }

/* .modal */
.modal { z-index: z(modal); }

which results in:

/* .header */
.header { z-index: 2; }

/* .main elements */
.main { z-index: 1; }
.foo { z-index: 1; }
.bar { z-index: 2; }
.tooltip { z-index: 3; }

/* .modal */
.modal { z-index: 3; }

In this example, nothing within .main will ever be able to be above .header, and .modal sits atop everything.

Basically, you’ll never have z-index conflicts again \o/

Taking it further

If you didn’t want to be limited to 2 levels of nesting, this recursive z-index() version allows you to use as many levels as you like, with every level except the last being a map.

This article has been cross-posted on Codepen for better code formatting.

A List Apart (ISSN: 1534–0295) explores the design, development, and meaning of web content, with a special focus on web standards and best practices.

Sassier z-index Management for Complex Layouts was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you don’t want to read the preface, jump right to the tips.

This article is also available in Russian, thanks to Workafrolic, Korean, thanks to Yongui, in Portuguese, thanks to EmanuelG, and in Spanish, thanks to “Ibidem Group”.

Personal development and change in perspective

When I made my first website my highest priority was to get content online. I didn’t care much about usability, accessibility, performance, UX or browser compatibility. Why would I? I made a robust table based layout and I offered a 800×600 and a 1024×768 version of my site. On top of that, I informed users that the website was optimized for Internet Explorer 5.

This was of course before I started to work professionally as a web designer and my perspective in what was important changed.
Years later, instead of dictating the requirements for my websites, I started to optimize them for all major browsers.
Beginning with Ethan Marcotte’s game changing article I started caring about devices as well.
Making websites for all kinds or browsers and devices is great, but pretty much useless if the websites are too slow. So I learned everything about critical CSS, speed indices, font loading, CDNs and so on.

Getting started with accessibility (a11y)

Recently my perspective has changed again and I realized that making a fast, responsive website that works in older browsers isn’t enough if e.g. it isn’t navigable via keyboard.
But accessibility isn’t just yet another item on our to-do list to cross off before we launch our website. Accessibility is the foundation of what we do as web designers and web developers and it’s our obligation to treat it as such.

I spent the last few months reading, listening and talking about web accessibility. It took me some time to get my head around a few things and I’m still at the beginning, but the more I learn the more I’m surprised how much I can do right now without having to learn anything completely new.

I’ve expanded my knowledge of HTML, CSS, and JavaScript, but the most important thing I’ve learned is that accessibility isn’t just a medical term that only applies to a certain percentage of people. Accessibility is something that concerns all of us, you and me, every day. What we create is useless if it isn’t accessible.

In this series of articles, I want to share some of my newly acquired knowledge with you. You shouldn’t treat the tips I’m going to give you as a check list but as a starting point. Incorporating these techniques into your workflow will get you started with accessibility and hopefully motivate you to learn and care more about your users.

Without further ado, here are my accessibility tips:

It’s important to define the natural language of your document

Telling the browser which language you are using in your document has many benefits. It’s good for SEO, it helps third-party translation tools and browsers to identify the right language and dictionary. Defining the correct language in an HTML page helps assistive technology to choose the correct voice profile or character set.(1) Adrian Roselli has gathered some more benefits of using the lang attribute on his website.

<html lang="en">
    …
</html>

Watch a demonstration of the lang attribute in use on YouTube.

If you switch language within a document you can use the lang attribute on specific tags.(2)

<p>There is a certain <i lang="fr" class="idiomatic">je ne sais quoi</i> in the air.</p>

Make sure to always define the right language. Steve Faulkner made a video that illustrates what happens if you don’t use the lang attribute correctly. All language codes are listed in the IANA Language Subtag Registry.

You can hide content using the hidden attribute

If you want to hide content visually and from screen readers, use the hidden attribute.

Browser support for the hidden attribute is very good, except for IE 10 and lower. You can provide support for older browsers if you add this fallback to your CSS.

[hidden] {
   display: none;
}

Sometimes it’s better to add a blank alt attribute to an <img> element

If an image is used as content, apply the alt attribute to describe the images content and function succinctly. When you do that don't start with „Picture/Image/Graphic of…“, because the screen reader does that anyway.

If the image is purely decorative or doesn’t add valuable information, consider embedding it with CSS as a background image. If you have/want to add it in HTML, don’t remove the alt attribute, but leave it empty.(3)

<img src="decorative_image.jpg" alt="" />

It’s important that you don’t omit the alt attribute.

Omitting this attribute altogether indicates that the image is a key part of the content, and no textual equivalent is available. Setting this attribute to an empty string (alt=””) indicates that this image is not a key part of the content and that non-visual browsers may omit it from rendering. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img

There are some more tips on using the alt attribute on the The A11y Project page „Quick Tip: Using alt Text Properly “.

If you need a button, use the <button> element

In general, you should always favor native HTML elements, if there is one, over faking your own. For example, if you need a button, use the <button> element and not a <div>.

Buttons have many benefits/crucial features, for example:

• Focusable
• Clickable (with mouse and keys)
• Screen readers identify them as buttons

Rob Dodson did a really great job explaining the benefits of an actual <button> over a <div>. Watch the A11ycasts episode „Just use button“ for more details and examples.

If you are not sure whether to use a button or a link, read Marcy Suttons post „Links vs. Buttons in Modern Web Applications“.

Structuring your markup correctly with headings is important

By creating a sound outline using headings <h1> - <h6> you are helping users to better understand the structure of your page and relationships between individual sections. On top of that, it will help users with assistive technology navigate. Screen readers provide different ways of moving from one piece of content to another. For example using the NVDA screen reader users can jump from heading to heading with shortcuts (H and Shift + H).

When you nest headings skipping levels should be avoided.(4) Also, don’t use multiple nested <h1> elements to create the outline. Adrian Roselli explains why in his articles There Is No Document Outline Algorithm and The Truth about “The Truth About Multiple H1 Tags”.

<!-- Don't skip levels: -->
<body>
    <h1>My website</h1>
    <h4>Heading</h4>
        <h2>Subheading</h2>
    <h3>Heading</h3>
</body>

<!-- Don't rely on inexistent outline algorithms: -->
<body>
    <h1>My website</h1>
    <section>
        <h1>Heading</h1>
        <section>
            <h1>Subheading</h1>
        </section>
    </section>
    <section>
        <h1>Heading</h1>
    </section>
</body>

<!-- Do this: -->
<body>
    <h1>My website</h1>
    <h2>Heading</h2>
        <h3>Subheading</h3>
    <h2>Heading</h2>
</body>

tota11y provides a nice way of checking if your outline is persistent. Another way is to disable CSS and check if the page is readable and the structure makes sense.

Using landmarks helps people navigate your site

It is possible and advised to mark up thematic sections with HTML5 (<article>, <aside>, <nav>, <section>). You can also use WAI-ARIA role attributes for older browsers or sections that don't have an explicit tag like search.(5) Sectioning elements are not a replacement for the <div> element. Use them to mark up bigger chunks of related content which are distinct from other content. Don't overuse sectioning elements. Use <div> for CSS/JS only purposes and sections for semantics.

One of the main benefits is that screen reader users will be able to navigate pages by jumping from section to section. These navigable sections are called landmarks.(7) Watch a demonstration of landmark navigation on YouTube.

<body>
  <header> <!-- landmark --> 
    <nav> <!-- landmark -->
      ...
    </nav>
  </header>   

  <aside> <!-- landmark -->
  </aside>
</body>

You can simulate the feature of jumping from landmark to landmark with a browser extension called Landmarks. Press Alt + Shift + N to move to the next and Alt + Shift + P to move to the previous landmark.

If you want to learn more about sections, check out the Web Accessibility Tutorials page about sections.

Please note that not all software will treat every potential landmark as such.

The main page content, header, and footer are also landmarks

By wrapping the main content of your site in a <main> element you give some screen users the ability to jump directly to your main content using a shortcut. „The main element represents the main content section of the body of a document or application“ and must not be used more than once per document (5).

As already stated splitting up your content into landmarks is a good thing. <header> and <footer> behave in all major browsers like landmarks if they are not nested in a <section> or <article> element. If you need support for older browsers, you can turn your main site header and footer into landmarks using the role attribute with the values banner for the header and contentinfo for the footer.(6)

<!-- The extra role attributes are only important for older browsers -->
<body>
  <header role="banner">
    <h1>My personal blog</h1>
  </header>
  <main>
    <section>        
      <h2>Blog posts</h2>
      ....
    </section>
  </main>
  <footer role="contentinfo">
    &copy; 2016 Me
  </footer>
</body>

Fieldsets are great for grouping form elements and giving them more context

You’ve probably been at the point where you had to add several radio buttons or checkboxes to a form. Adding the form elements and the corresponding labels usually isn’t a big deal. But which element do you choose, if you want to label the whole group of radio buttons or checkboxes?

<form>
  Shirt size
  <input type="radio" id="s" name="shirtsize" />
  <label for="s">S</label>  
  <input type="radio" id="m" name="shirtsize" />
  <label for="m">M</label>  
  <input type="radio" id="l" name="shirtsize" />
  <label for="l">L</label>   
</form>

How do you mark up Shirt size? A <p> will probably work, but it isn't associated with the group of radio buttons.

A much better approach is to wrap everything in a fieldset and put T-Shirt size in a <legend> tag. Screen readers will know that <legend> is associated with the radio buttons and read out its value whenever a radio button is selected.

<form>
  <fieldset>
    <legend>T-Shirt size</legend>
    <input type="radio" id="s" name="shirtsize" />
    <label for="s">S</label>  
    <input type="radio" id="m" name="shirtsize" />
    <label for="m">M</label>  
    <input type="radio" id="l" name="shirtsize" />
    <label for="l">L</label>   
  </fieldset>
</form>

Like with <section> be considerate when wrapping form elements in fieldsets. As a rule of thumb only use <fieldset> if you have multiple form elements that form a group and a corresponding label for that group, something that fits in a <legend>.

Going beyond

That’s it for now. I hope that these tips will help you write more accessible HTML. A big thanks to Heydon Pickering, because his book „Inclusive Front-End Design Patterns” built the foundation of most of the stuff that you’ve just read. If you want to learn more about accessibility and inclusive design I highly suggest you read his book.

More accessibility tips

This article is the first one in a series of four. The last two articles are in the works and soon to be released.

1. Writing HTML with accessibility in mind
2. Writing JavaScript with accessibility in mind
3. Writing CSS with accessibility in mind
4. Up next: Learn how to design and develop with accessibility in mind

Thank you for reading and please don’t forget to like and share this article if you enjoyed it.

While I work on the next post, you can check out some other stuff I wrote:

• Getting started with CSS Font Loading
• I totally forgot about print style sheets

As always thanks to Eva for proofreading my writing.

(1) Pickering, Heydon; Inclusive Design Patterns, p.5
(2) w3.org Wiki — i element
(3) WebAIM — Alternative Text
(4) Web Accessibility Tutorials — Headings
(5) WAI-ARIA — main (role)
(6) Using navigation landmarks
(7) Landmarks must identify content regions

A List Apart (ISSN: 1534–0295) explores the design, development, and meaning of web content, with a special focus on web standards and best practices.

Writing HTML with accessibility in mind was originally published in A List Apart Sidebar on Medium, where people are continuing the conversation by highlighting and responding to this story.