As I mentioned in Chapter 1, web designers and developers are an ever-resourceful bunch. Faced with spending a lot of time learning how to tame floats and coming up with other methods to enable complex web and application layouts, the community developed tools to help ease the way. These tools range from a raft of varying “best practices” in CSS architecture to pre- and postprocessors. They also extend to frameworks, and to the recent interest in design systems and pattern libraries, and working with reusable components rather than with finished pages.

In addition to a growing reliance on tooling, we are learning more about the implications of many of our choices in terms of performance and accessibility. The front-end development landscape of 2017 is complex and can seem overwhelming. This chapter will look at where we are today, to see how these new layout methods fit into the environment we have created.

Although the web-development community seems to love to polarize opinion, nothing that follows should be taken as an endorsement or condemnation of a tool or technique. Whether you should use any of these things is down to your individual project and team. What makes perfect sense for a team of fifty would probably be overkill for a solo developer. My aim is to assess the current landscape; whether you use these tools and techniques or not, the impact they have on how we do web design and development affects all of us.

CSS Architecture

Programming style guides have been around for a while. Sometimes they stick to established principles; other times, they adhere to a common set of rules agreed on by a team. With formal CSS architectures, teams go a step further by adopting a methodology developed and promoted by an external person or organization. The various approaches to CSS architecture—OOCSS (http://bkaprt.com/ncl/02-01/), SMACSS (http://bkaprt.com/ncl/02-02/), BEM (http://bkaprt.com/ncl/02-03/), and so on—may seem like overkill if you are the only person who touches the CSS on the sites you build. Why make things so complicated? If you’ve ever had to work on a project where lots of people get their hands on the CSS, you soon realize why such architectures are useful.

Love them or hate them, these formal architectures have had widespread impact. Even small CSS demos are commonly created using BEM-style selector naming, making these systems part of the language around CSS. A side effect of these systems, and of the frameworks discussed later in this chapter, is that CSS has become more tightly coupled to the markup, with descriptive class names identifying how elements should look. These systems also promote less use of the cascade. Rather than identifying an element according to its position in the document tree, they encourage identification by class alone. This fosters reusability; however, critics might claim that the cascade is an important tool in reducing the amount of markup required for each page.

Pre- and Postprocessors

Another part of the development toolchain in recent years has been that a growing number of people write CSS by not writing CSS.

A preprocessor is a tool like Sass (http://bkaprt.com/ncl/02-04/) or LESS (http://bkaprt.com/ncl/02-05/): you write CSS in a language other than CSS, and then compile to CSS. A postprocessor happens after you get to CSS—Autoprefixer (http://bkaprt.com/ncl/02-06/) is a good example of such a tool. Autoprefixer runs on your CSS file to add the required additional vendor prefixes for older browsers. It does this either on your handwritten CSS file or on a CSS file compiled by a preprocessor.

These tools are huge time-savers. Like formal architectures, they can help ease the pain of working with CSS on a team. One common way to use a preprocessor is to break the monolithic stylesheet down into smaller files so that people responsible for different parts of the application can work on individual files, which are then compiled. Pre- and postprocessors also enable maneuvers that, until recently, were impossible in CSS, such as setting variables for common colors, fonts, or sizing.

While these tools have had a net positive effect, they have changed the way many of us work with the core language of CSS. Instead of writing CSS every day, we write Sass. Having created our mixins for common tasks, we lean on those, rather than writing the actual end CSS that will be parsed by the browser. We’re now a level removed from the actual reality of our CSS specifications—and we risk limiting ourselves to what our preprocessor of choice can do and thus missing some of the newer techniques that are becoming possible. Or perhaps we have postprocessors running and are unwittingly adding prefixes that are no longer necessary.

None of this is an argument against using these useful tools. Instead, consider it a case for remembering to take a look at the world outside of those tools once in a while.

Component-First Design

Formal architectures and preprocessors alike have helped enable a trend in web design of breaking things down into smaller components. Brad Frost has described this technique as atomic design (http://bkaprt.com/ncl/02-07/). Pattern library tools such as Pattern Lab (http://bkaprt.com/ncl/02-08/) and Fractal (http://bkaprt.com/ncl/02-09/) provide a framework for working with the hundreds of small components generated by working this way (Fig 2.1). A related concept is that of a style guide or design system (http://bkaprt.com/ncl/02-10/), a document detailing each component, separate from the complete pages that are ultimately generated from these pieces.

Such methods encourage us to look at design from the smallest elements outward instead of starting with a blank page and creating a complete design. Once again, proceeding this way has much to offer front-end developers who are part of a team, and can produce deliverables that designers working separately can hand off to the people who will implement the work. These methods constitute quite a departure from the early days of the web, when we typically thought in “pages” rather than in components.

Frameworks

Any discussion of modern web design invariably comes around to the fact that all websites look more or less the same. The chief culprit behind these “identikit” websites are frameworks—Bootstrap (http://bkaprt.com/ncl/02-12/) and Foundation (http://bkaprt.com/ncl/02-13/) being key players. These incredibly successful projects enable designers to quickly develop sites with minimal front-end knowledge. They also enable developers to create sites without needing an understanding of web design. A site built on Foundation or Bootstrap might not look unique, but it’s less likely to look terrible than something made by a programmer.

Frameworks help mask a lot of the complexity that lies in creating float-based layouts. They do our calculations for us, so we get the number of columns in the proportions we want at each breakpoint. We can look up the pattern we want to achieve in the framework documentation and copy and paste the code. But because many front-end developers rarely write CSS outside of these frameworks, they risk being unable to think outside of them. It’s also worth remembering that all frameworks come with the opinions and requirements of what they were built for. These may or may not match your requirements.

Performance

Another facet of life as a web professional is an increasing focus on performance. As we have tried to create websites that will look great on everything from a watch to a large retina screen, we have added an ever-increasing amount of code and images to our sites. The HTTP Archive reported that in December 2016, the average webpage download was over 2.4 MB (http://bkaprt.com/ncl/02-14/).

These large download sizes may mean that sites load a little more slowly for those of us at home or at work on fast internet connections, but they have a real cost for users on any kind of metered data plan. That might be me, visiting the United States and having to pay for expensive global roaming (though I can usually duck in somewhere with Wi-Fi). Of far greater concern is the person in a developing country, whose only access to the internet is via a phone on costly mobile data. Tim Kadlec’s What Does My Site Cost? (http://bkaprt.com/ncl/02-15/) can give you an appreciation of what it costs people in countries around the world to download your website.

This is not a book about performance, but as we head into exploring all that is new in layout, we should keep the speed of our sites in mind. Let’s make sure that in our enthusiasm to embrace new techniques, we don’t build sites that are harder for people to use.

Accessibility

And speaking of ensuring that everyone can use our sites and applications, the subject of accessibility can’t be overlooked. Because of their capacity to disconnect the layout from the visual display and keyboard navigation, our newer layout methods also introduce potential accessibility issues. In Chapter 6, I discuss some of the powerful ways our new layout methods can disconnect the display order from the order in the document source. By giving us more power to rearrange our visual display, the specifications also require us to be more mindful of how we use it.

Evergreen Browsers

The existence of old browsers is a constant source of pain for web developers, and becomes an issue when large groups of users are “stuck” on some old browser version. We’ve seen this problem recur throughout the history of the web, with first Netscape 4 being the villain, then Internet Explorer 6.

For anyone running Chrome or Firefox, browser updates happen in the background, automatically. New browser features appear, and websites that take advantage of them will suddenly seem to be better. Safari and Edge update with operating system releases; users have grown more and more accustomed to running these updates to ensure for security reasons. They get a new browser at the same time.

Sadly, it is not as simple as everyone now having wonderful, self-updating browsers. A lot of our users do, yet we still see people chained to a browser version by internal policy. People also sometimes get stuck with a certain browser version because their operating system doesn’t support newer software. Users of old versions of Windows may be unable to install IE11 or Edge. This problem increasingly crops up with phone hardware, too; think of Android users who can’t update their OS, and therefore miss out on the new browser software that comes with the update.

Despite not having worldwide evergreen browser support, the situation has generally improved for most of us compared to a few years ago. It’s worth implementing a feature that perhaps Firefox has shipped and Chrome has stated they will implement. Assuming the design will be online for a couple of years, a few months down the road, all Chrome users will see that enhancement. In Chapter 7, we’ll consider modern ways of approaching browser support, and look at how we can create sites that enhance themselves as browsers update—without us needing to write any more code.

Outsourcing Our Understanding of CSS

There was a time, perhaps ten years ago now, when the real job of a front-end developer was that of a browser-bugs expert. The CSS we had to work with was limited. What separated the professional from the dabbler was knowing all the strange tricks that prevented mysterious disappearing content in IE6. Today, our browsers are far less buggy, but we still have to contend with the limited CSS layout methods of the past, plus the new innovations of recent years.

We’re also coping with the challenges mentioned in this chapter. We’re trying to create performant, accessible sites that deliver on business goals and delight users. We’re doing that work in every possible type of configuration—from the solo web designer who designs and implements her sites alone to huge teams where individuals only ever touch CSS at a component level.

There is nothing inherently bad about using a framework, a pre- or postprocessor, or any other tool to help ease your front-end development workflow. In the real world, we have to ship quickly, build things with unrealistic budgets, and deal with that client who insists a site look “the same” in IE8 as in the latest version of Chrome.

But if all your front-end development is in your preferred framework, how long will it be until you can’t remember how to sit down in front of a text editor and build a layout from scratch? How do you find out about new approaches and new specifications? How much are you limiting your creativity to whatever the framework you use enables?

I hope that the rest of this book will encourage you to look past your favorite tools and frameworks to see what is now possible. Perhaps you will realize that you don’t need to lean on the grid system built into a framework, or perhaps you will find yourself using it more lightly. I hope that however you build sites in the future, I’ll be able to demonstrate to you some of the potential of CSS, and increase your understanding of why certain things happen.