I am Eric A. Meyer. Ask me anything.
Eric is an internationally recognized expert on the subjects of HTML, CSS, and Web standards. Eric has been working on the web since late 1993. He is the founder of Complex Spiral Consulting, a co-founder of the microformats movement, and co-founder (with Jeffrey Zeldman) of An Event Apart, the design conference series for people who make web sites.
Shoot any questions you want Eric to answer!
Hey Eric. There's a lot of divergent work in organizing CSS right now, such as BEM, SMACSS, Inline Styles, CSS-in-JS, ITCSS, and Atomic CSS. Still, there are not a lot of conceptual design patterns for how to organize your CSS (if you're using stylesheets) in an efficient and scalable way. Meanwhile, design patterns in JS, Java, and PHP such as Flux/Redux, MVC, and functional programming are now the way of things. Do you see a way forward for design patterns for how to organize CSS in stylesheets utilizing the core features of CSS? Are there any promising organizational patterns out there that might not be as well known? Thanks.
I liked http://alistapart.com/article/meaningful-css-style-like-you-mean-it 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.
Nice to see you here. :) I am your huge fan. Congrats for the success of Designing For Real Life.
It's strange no one has asked you questions related to CSS Frameworks so far. What are your thoughts on frameworks like Bootstrap, Foundation, etc? Do you use them or recommend them?
Hey Eric! :)
Which do you think has influenced CSS specs more in the last few years: engagement between working groups and developers, or industry trends like CSS preprocessors illustrating demand for features? (Or has something else entirely been the biggest driver?)
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.
Hey Eric! Thanks for doing this AMA. If you could change one thing in CSS today, what would that be?
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.
ay yo eric
em for media queries?
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!
Hi, What's your thought about
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.
How would you describe the role of test suites in W3C standards development? ...are they something developers should consider contributing to? ...and if yes, how should they start?
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.
Thanks for doing this AMA.
What's your opinion on CSS Flexboxes? Do you think we should start using them as a default way of structuring web pages?
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.
Eric, Do you think there should be a web standard for HTML Emails also? This is the most ignored part of the internet.
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.
- What's the idea behind inline CSS and email templates?
- Are there any plans for allowing email templates to use external CSS links and make designing email templates a little bit more modern similar to how CSS is used to design web applications today?
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.
What are your favourite books - both technical and non-technical?
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
What's hardware and software you use?
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.
What was the motivation behind creating "An Event Apart"?
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.
Do you think people with only HTML and CSS knowledge have a demand in the market?
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.
Eric, Why are Web Standards discussions so hung up on Mailing Lists? It strikes me that once you enter the world of “Web Standards” it’s inevitable that discussions are done via the extremely clunky format of mailing lists. Do you think it's time to upgrade?
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.
Another question, sorry for pestering you.
What are things you follow to improve website's accessibility? Do you think only following schema tags is enough today?
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.