As a community, we love to talk about meritocracy while perpetuating privilege.
This is playing out in full force in the front-end development community today.
Front-end development is a part of the field that has historically been at least slightly more accessible to women.
Shockingly, (not!) this also led to a salary and prestige gap, with back-end developers making on average almost $30,000 more than front-end.
(Don’t read the comments.)
Every single font-feature-settings value demonstrated in one single page.
Scores of people who just want to deliver their content and have it look vaguely nice are convinced you need every web technology under the sun to deliver text.
This is very lawnoffgetting but I can relate.
I made my first website about 20 years ago and it delivered as much content as most websites today. It was more accessible, ran faster and easier to develop then 90% of the stuff you’ll read on here.
20 years later I browse the Internet with a few tabs open and I have somehow downloaded many megabytes of data, my laptop is on fire and yet in terms of actual content delivery nothing has really changed.
In defence of the cascade (especially now that we’ve got CSS custom properties).
I think embracing CSSâs cascade can be a great way to encourage consistency and simplicity in UIs. Rather than every new component being a free for all, it trains both designers and developers to think in terms of aligning with and re-using what they already have.
Remember, every time you set a property in CSS you are in fact overriding something (even if itâs just the default user agent styles). In other words, CSS code is mostly expressing exceptions to a default design.
A handy pre-launch go/no-go checklist to run through before your countdown.
The beauty of this approach is that the site doesnât ever appear broken and the user wonât even be aware that they are getting the âdefaultâ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.
A case study in applying progressive enhancement to all aspects of a site.
Progressive enhancement isnât necessarily more work and it certainly isnât a non-JavaScript fallback, itâs a change in how we think about our projects. A complete mindset change is required here and it starts by remembering that you donât build websites for yourself, you build them for others.
A terrific piece by Hidde, about CSS grid, but also about a much bigger question:
I donât think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users donât mind, theyâve come for the content.
If users donât mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere.
This is great advice from Lindsay Grizzardâgetting agreement is so much more important than personal preference when it comes to collaborating on a design system.
When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, donât use BEM.
It’s all about the people, people!
A great long-term perspective from Rachel on the pace of change in standards getting shipped in browsers:
The pace that things are shipping, and at which bugs are fixed is like nothing we have seen before. I know from sitting around a table with representatives from each browser vendor at the CSS Working Group how important interop is. No-one wants features to be implemented differently in browsers. This is what we were asking for with WaSP, and despite the new complexity of the platform, browsers rendering standard features in different ways is becoming increasingly rare. Bugs happen, sometimes in the browser and sometimes in the spec, but there is a commitment to avoid these and to create a stable platform we can all rely on. It is exciting to be part of it.
This is an interesting tool: mess around with styles on any site inside Chrome’s dev tools, and then hit a button to have the updated styles saved to a URL (a Gist on Github).
This great post by Hui Jing is ostensibly about CSS shapes and exclusions, but there’s a much broader message too:
Build demos, and play around with anything that seems remotely interesting. Even if that feature is in early stages, or only supported by 1 browser. And then talk about it, or write and tweet about your experience, your use cases, what you liked or disliked about it.
We can shape the web to what we want it to be, but only if we get involved.
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
Another great video from Jen as part of her Layout Land series. This time she addresses the question of the overwhelming technology landscape for developers and where they should invest their time.
She references my most recent talk, where I’ve been drawing a distinction between “materials” (HTML, CSS, JavaScript) and “tools” (everything else).
The slides and video from a really great well-rounded talk by Aaron, filled with practical examples illustrating concepts like progressive enhancement and inclusive design.
Ethan’s ode to the fr unit in CSS grid.
Rachel follows up on my recent post about CSS grid in old IE with her thoughts.
As Jeremy notes, the usefulness of a tool like Autoprefixer is diminishing, which is a good thing. It is becoming far easier to code in a way that supports all browsers, where support means usable in an appropriate way for the technology the user has in front of them. Embrace that, and be glad for the fact that we can reduce complexity based on the increasing interoperability of CSS in our browsers.
A nice walkthrough of a CSS grid in production. I was surprised to see percentages used as unitsâI wonder if it would feel “cleaner” if they were converted to fr units?
A bold proposal by Heydon to make the process of styling on the web less painful and more scalable. I think it’s got legs, but do we really need another three-letter initialism?
We waste far too much time writing and maintaining styles with JavaScript, and I think itâs time for a change. Which is why itâs my pleasure to announce an emerging web standard called CSS.
Browser implementations of Sol LeWitt’s conceptual and minimal art, many of which only exist as instructions like this:
Vertical lines, not straight, not touching, covering the wall evenly.
Rob attended the excellent Ampersand event last Friday and he’s made notes for each and every talk.