A lot of web standards folk have been online a long time, coming from the era of Usenet, IRC, and listservs. That’s no doubt part of it.

Here’s the thing about mailing lists: they may feel clunky, although I’d argue that’s more due to email clients than the format, but the advantage is that they’re asynchronous. When you have people from all over the world participating, it makes a lot of sense to use listservs. Each message is self-contained, so there’s not the overlapping chaos of synchronous channels like Slack. It’s also a lot easier to isolate topic threads in email, whereas it’s practically impossible in synchronous communication. If you have an email client that will show you how a conversation’s threads branch out, you can be a lot more informed and focused than if you have to do the mental work of untangling a chat log.

Web forums also work, for the same reasons, and I suspect that’s why at least some of the CSS WG work has recently shifted over to GitHub. That allows people to participate in the specific topics that interest them, without having to get all the mail of a listserv. It makes a lot of sense, though there may be unforeseen downsides. I’ll be interested to see if using GitHub holds up over time for them.

Should be, sure. Will be, probably not. As my colleague Jeffrey Zeldman observes, there’s an Email Standards Project web site, and for years it’s lacked a style sheet. Now, the content is all still there and readable, but there’s a profound sense of neglect. That seems to sum up the state of trying to bring sanity and consistency (never mind elegance) to HTML emails.

Which is why I always configure my mail clients to show me plain text, by the way. MailMate, my preferred client, makes this pretty simple.

Thanks, Ida! I don’t use frameworks or recommend them, but I don’t necessarily recommend against them, either. I think they’re great prototyping tools, since they make it easy to get something spooled up really fast. The problem I see is when they’re used in production. The output is always distressingly clunky, and the layout often fragile. And that’s even assuming you don’t rely on Javascript to make them work, which is asking for trouble. Almost nobody intentionally disables JS, but slow networks can prevent loading, and older devices can choke to death on the processor demand.

No worries! No, schema tags aren’t enough. There are a lot of things that go into making a site accessible, but the fundamentals are still solid: clean semantic markup, ARIA where needed, clear content and design, and a strong focus on stress cases.

For example, Derek Featherstone has a great exercise: what is it like to try to fill out a form if you’re looking at it through a drinking straw? Does the flow make sense, or is it confusing? The answer matters because that’s what it’s like for someone with limited vision, who may have blown the zoom way up on your design. If they have to pan back and forth and back and forth, even if they’re using the keyboard to jump fields, it can be very disorienting.

That’s a stress case that can help you realize that a more linear flow is easier to understand. Which, incidentally, makes for a better mobile design. And so on.

Yes, though not like they used to. I think this is mostly because those are the fundamental components of the web that are robust. JS is often useful, but it’s fragile—one error, whether in your coding or the network’s performance, can break all the scripting. HTML and CSS, on the other hand, are almost pathologically fault-tolerant.

The difference is that the market demand for people who know only HTML and CSS exists at the mom-and-pop level: small projects for small rates, for local businesses and so on. If you want to work on big projects, or for a big company, you almost certainly need to know more than just HTML and CSS. That’s just where the industry had carried us, at this point.

I love them, but no, not necessarily. I’ve used them here and there for rebeccasgift.org, such as in the nav bar, but their limitation is that they’re meant to arrange elements along a line. They’re one-dimensional, in other words, in the specific meaning of that term. Grids, on the other hand, are two-dimensional, and incredibly powerful.

That said, flexbox is pretty much here now, whereas grids are still developing. So using flexbox now makes sense to me. Just don’t become reliant on it, because there’s a whole lot better coming up fast.

The first ten, in the order they came to me:

• “Watership Down” by Richard Adams
• “The Victorian Internet” by Tom Standage
• “Startide Rising” by David Brin
• “Spin” by Robert Charles Wilson
• “The Chronoliths” by Robert Charles Wilson
• “Mother Earth Mother Board” by Neal Stephenson (technically a magazine article, but at ~47,000 words, it’s verging on novel length)
• “Excession” by Iain M. Banks
• “Copper” by Kazu Kibuishi
• “The Atrocity Archives” by Charles Stross
• “The Westing Game” by Ellen Raskin

At first, it was to create the kind of conference Jeffrey and I would want to attend, or to speak at. There were a lot of shows back then, but none were speaking to the designer/developer with experience and a passion for web done right, and few if any had the kind of respect for attendees and speakers that we thought there should be.

Things have come a long way since then; a lot of the shows we were side-eyeing back then no longer exist, for example. Our motivation is still what it was, but over the years it’s expanded a bit. We both have a deep passion not just for the web, but for all design. UX and design in general are becoming more and more important, as we think about desktop and mobile and physical interfaces (e.g. Amazon Echo) and watches and more.

How systems of interaction are built matter more than ever. We’re committed to pushing the state of that art forward, and . So we’re more than just web now. Web is always a big part of what we’re talking about, but it’s not just a web conference any more. It’s a lot more than that, and we love how it brings a few hundred people (never more than that) together to hear what’s coming next, and more importantly talk with each other about what they’re doing and looking to do next. The community is really amazing. Just that by itself would be more than motivation enough.

I’m honestly not sure how one might contribute to the official test suites these days. I don’t even necessarily how the suites work, now. It used to be, you just put up a bunch of pages and people would look at them to determine if a browser passed.

That said, I’m a big proponent of building test cases, even if they’re just for your own understanding. I maintain a set of test pages at http://meyerweb.com/eric/css/tests/css3/ and another collection one directory up, at http://meyerweb.com/eric/css/tests/ — they’re not meant to be a formal suite, but they help me work out how things are supposed to work.

I feel like preprocessors have been a big influence. Things that the WG has rejected for years (even decades), like variables and even logic, are now finding their way into the specs because they were implemented in preprocessors, and lots of authors used them. I love preprocessors for that.

The other huge influence has been, just as with everything else, mobile. A lot of things that would have been nice in the past were made critical by mobile. Responsive images are just one example of that. There are similar things happening in CSS, such as more powerful media queries.

I have a 2013-era MacBook Pro, bumped-up on the specs and using an SSD that I’m starting to get close to filling up. For software, the current set is Firefox Nightly, BBEdit, MailMate, Slack, a shockingly old version of NetNewsWire, Transmit, Photoshop when I need it, ImageOptim, Terminal for git and other command-line fun, and SuperDuper for backups, which I should run more often.

Email. Ah, email. I’d love to see email clients catch up with this millennium, and support something other than inline CSS and table markup. On the other hand, I can see why loading external CSS into an email message might be a bad idea. There’s a lot of opportunity for privacy and security violations there.

Perhaps I’m not understanding the point of css-modules, but it looks like a fragile way to inline all the CSS things. That feels like several steps backward to me. But if I’ve misunderstood what modules do, then I take that back. It often takes me a while to osmose the points of a new technique to the point that I can really comment on it.

I liked alistapart.com/article/meaningful-css-style-like-… very much, though probably because it’s the closest I’ve seen to how I write CSS.

But the real challenge in this question is that there are a lot of ways to organize CSS, possibly infinite ways, and what works for me may not—probably won’t!—work for you. I don’t think the divergence of work in CSS organization is a weakness of the language. It’s a strength, because it shows that CSS is flexible enough to support all those different patterns of work. There’s room for a lot more.

I usually use em, but most of the queries I inherit from others use rem. And I can see an argument for rems when trying to create a consistent visual rhythm, where you want a thing to have a width regardless of whether it’s an h1 or an ordered list. Of course, Grid layout might take us in a very different direction!

Full support for all of Grid Layout, like, yesterday. Seriously, the one thing I’ve wanted to change about CSS for 20 years now is to give it a Real Layout System™. Now it’s almost here, and I just want it to get here already.

If we take that off the table, then honestly? The stuff just beyond it: better/wider support for shapes, regions, multicolumn, exclusions, and so on.