To become a better web UI engineer, study design, communication, and vocabulary. Even if you cut back on some extra technical training, it’s worth it. That’s because the difference between good and great UI work rarely comes from technical prowess alone. It’s distinguished by creativity, visual insight, and sound organization.
Yes, JavaScript and styling fundamentals are important. You need to understand the tech behind your craft. But the solution to a tech blocker can be a tool or coworker away. And once you learn the basics of one MVC JS framework or CSS coding methodology, you can learn another.
Reusability is a bigger issue. Every time you change styling or write a new UI element, consider its impact elsewhere. Think ahead to where the application will grow and how you can cut repetition. It’s more than an blind grep through the code. It’s finding patterns. And visual patterns or usage trends are especially tricky to detect.
Flexbox is a powerful web styling tool, one my favorite recent CSS additions. It’s an effective replacement for hacky, float-heavy layouts. Given its wide browser support and mature feature set, I lean on Flexbox for most project work.
However, I’m surprised many developers stay away from Flexbox. They’re worried about browser support, a big learning curve, or otherwise strange behavior. They shouldn’t. Here’s how to get started.
Inefficient web styling slows performance, adds inconsistencies, and harms developer and designer productivity. But many teams don’t prioritize CSS tech debt; gains are subtle and hard to measure. And CSS testing suites aren’t as robust as those for JavaScript, Rails, and other web languages.
Yet the effort necessary to keep web styling lean and efficient is overblown. The key is abstracting page level styling into reusable components.
Components are distinct groups of elements on a page. Common examples include navigation bars, carousels, and form sets. Components should be standalone, easily moved to different pages without breaking layout. Some styling methodologies substitute other terminology for components, calling them modules or blocks. And the size and scope of component usage differs widely among projects. Large projects, given their size and scope, tend to rely more on components than smaller works.
Web styling advances at a ferocious rate. Vanilla CSS is a rarity. Almost every web presence relies on new frameworks, preprocessors, and workflows. Yet even in the midst of progress, the fundamentals often trip up our work.
Our CSS fights against the natural DOM (Document Object Model) flow. The DOM flows from left to right, and from top to bottom. Block elements expand as wide as possible within a bounding container. Elements grow only as tall as absolutely necessary. The more we resist this flow, the more likely things break.
To avoid this, I follow three rules. Whenever my layout feels janky or otherwise hard to debug, it’s usually because I’ve strayed off course from these guidelines.
I recently attended the third annual CSSConf here in NYC. The conference scheduled sixteen speakers over two days with varied content and subject matter. Some speakers talked about the gap between design and development. Others touched on coworker relationships and styling for the web’s future, “post CSS”. Most focused on CSS-based web development. Here are a few takeaways that are easy for almost anyone to integrate into their workflow.
Object-fit is a CSS attribute that should have had widespread support a long time ago; super useful. It’s a bummer that Microsoft still lists the object-fit parameter as merely “Under Consideration”, but falling back for IE is easy and safe.
Excellent explanation of how the Flexbox CSS operator determines layout. I especially enjoy how the author breaks down the math calculations and proportion.
I’m not 100% onboard with everything developer Hugo Giraudel recommends in this long set of recommendations for writing Sass. Yet there’s an incredible amount of solid advice here, especially the bits on numbers, measurement calculations, and selector nesting.
Felicity Evans writes a “manifesto” for well written Sass in A List Apart:
Yet alongside the wide-scale adoption of Sass (which I applaud), I’ve observed a steady decline in the quality of outputted CSS (which I bemoan). It makes sense: Sass introduces a layer of abstraction between the author and the stylesheets. But we need a way to translate the web standards—that we fought so hard for—into this new environment. The problem is, the Sass specification is expanding so much that any set of standards would require constant revision. Instead, what we need is a charter—one that sits outside Sass, yet informs the way we code.
A simple web tool to create linear CSS-based gradients. It’s fast and just as effective (if not more) as almost any desktop graphical tool. Just enter a base and shift a few sliders.
