For a long time I’ve been compiling my Sass into a single CSS file - styles.css, but recently, with our component based design/frontend process and Drupal 8’s lovely Library system I’ve been wondering if the single file was still a good idea. Looking at the amount of unused CSS loading into any given page was a little bit painful.
A common problem that I’ve faced, particularly in the last few years, is how to deliver the complex, component driven design that clients want while also giving content authors full flexibility with those components without creating an un-maintainable, or brittle product.
A recent Drupal 8 project of ours had some great requirements around it’s landing pages, aimed at reusing existing components in a range of layouts and combinations. Paragraphs quickly established itself as the site-building tool of choice and Flexbox always wins for me as the CSS grid/layout approach, so we looked at how the two could be combined to give the client the flexibility they needed, without over-complicating the editor experience.
Base themes in Drupal are incredibly useful but often add bloat to the finished sub-theme when care isn’t taken to remove unnecessary css files, or files that are 5% used and 95% overridden. When porting aGov to Drupal 8 we took the opportunity to improve how it’s theme inheritance is managed, making it easier to create trim, lightweight sub-themes.
typey has just turned 1.0, so I thought it would be a great time to show off some of its features.
A requirement that comes up from time to time is being able to use content stored in Drupal and produce rich HTML emails. In a lot of cases the design of these emails matches the design of the existing, already implemented front-end website.
In a recent project, we explored ways of creating HTML email’s which wouldn’t require us to start from scratch and would also evolve as the website’s look and feel did. Our design goals were thus:
Generally speaking hiding content goes alongside a bit of javascript that unhides the content under certain circumstances (think hamburger menu). Sometimes the content improves accessibility but is considered visual noise (says the designer). So as the developer you have a lot of ways to approach this.
At PreviousNext this past year, we have started using a style-guide-centric approach that matches our Agile development practices. We write our styles and markup as components and then use automation to build, test, and add them to a style guide.
Since we are a Drupal shop, you might expect that all our automation is done with PHP, but we’ve found, on the front-end side, the best tools are written in Node.js. Grunt, Gulp, Yeoman, Bower, Eslint and more are all written in Node.js and installed and distributed with its package manager, npm.
During PreviousNext’s weekly developers meeting I recently gave a lightning talk about how to use kss-node to auto-generate a website style guide. If you’ve even tangentially followed front-end development, you’ll find that this is yet-another blog post describing “project A implementing technology B with hip, new language/framework C.”
But kss-node is really cool and useful, especially if you understand how it fits into the larger picture of the new web development process. Fortunately, my previous post provides that big picture, so if you’d like to understand how Agile is turning web development inside-out and how style-guide-driven development is the new website development workflow, please go read that first. Then head back here for the screencast to get you started with kss-node.
If you’ve looked at front-end development at any time during the past four years, you know that there has been an explosion of new technologies. We are inundated with new projects like bower and cucumber and behat and KSS. It is a lot to take in. At the past two Drupalcons there have been sessions about this overload, My Brain is Full: The state of Front-end developement. Essentially those sessions are asking “What the hell is going on?”
“Everyone is describing the one little piece they’ve created, but don’t explain (or even reference!) the larger concepts of how all of these elements link together.” — Frank Chimero, July 2014 Designer News AMA
This is my attempt to explain.