This book assumes certain pieces of knowledge on the reader's part. This section aims to ensure that you are aware of these pieces of information, and explain what you can get out of this book. Seasoned developers or anyone who has been working in the web industry for a reasonable amount of time should be able to safely skip to the first chapter.
Although we will be providing examples of CSS code to demonstrate techniques and subjects we are covering, these are not to demonstrate the latest selectors or properties, but instead to demonstrate how to format, comment, and model your code to keep it sane and follow best practices in your processes. To that end, this book is about the entire team as much as it is about the developer and should be of value to all of its members.
This book is for the following:
Anyone working on a high-traffic website. This is any website expecting upward of 10,000 unique visitors per day, or with occasional spikes of traffic higher than this amount.
Anyone working on a very large website one with perhaps upward of 2,000 individual pages or with more than 30 minisites.
Anyone working on websites in companies with large amounts of staff modifying the same codebase, with upward of 30 developers working on the CSS.
Anyone working for a company with the capacity to become a very large company and wanting to build a good basis for its web development processes.
Developers without previous experience of working in large teams.
However, the practices involved are best practices for websites of any size.
Throughout the course of this book, you will learn the following:
The value of process
How to share knowledge among staff and teams
How to quickly get new CSS developers up and running
How to incorporate CSS into builds and deployments
How to write reusable and modular CSS
How to maximize performance of your website(s)
How to keep branding consistent
Best practices for cross-browser and accessible CSS
Dynamic CSS techniques
The final chapter provides a simple CSS framework we developed specifically for this book that demonstrates many of the things that we touch upon, as well as the process we have followed to build it. The four appendices provide concrete examples of guides and processes that you should find useful.
Before embarking on the writing of this book, we did much investigation into which alternative resources were available. A plethora of books on learning the basics of CSS, advanced CSS techniques, CSS3 selectors/properties, and different CSS design patterns are all easily obtainable.
This book does not compete with or replace these titles. This book instead explores the challenges of working in large teams or among large numbers of individual teams, on sites with many pages or subsites that receive considerable traffic. This book is not about using the latest and flashiest techniques for image replacement or cross-browser rounded corners; rather, it is focused on making it easy for newcomers to teams to easily comprehend and add to existing code, and for CSS within your infrastructure to be considered from the outset and built in a sane and performant manner.
Even though this book is aimed at both beginners and experts alike, we assume that you are comfortable using HTML and CSS, or are at least familiar with their syntax. We will be discussing the usage of modular, reusable code that is both robust and practical throughout the chapters in this book.
Separation of concerns is an important concept to understand when writing CSS. Many different architectures for applications and systems exist. The justifications and benefits of them are far beyond the scope of this book; however, it is worth giving a very simple explanation of multitier architecture since the logic behind it is easily applicable to CSS and the browser application model.
A multitier architecture approach is a design that separates logic, data, and presentation.[1] This usually describes a client-server system, where there is a client application and a server application. The majority of the processing takes place on the server, and the client is concerned with displaying the information and giving the user an interface to manipulate it. The multitier approach applies as such:
Client application: presentation
Application: logic
Server: data
Separating the tiers in this way gives clear ownership of any particular piece of code, function, or task. It also keeps everything reusable and easily maintainable.
This is how more traditional client-server applications would typically behave. This approach obviously applies to a web browser, web server, and database, but the code that runs in the web browser can also be broken down this way. We typically write our front-end code in three "languages": HTML, CSS, and JavaScript. It is possible for our code to be all jumbled up together, much like the following example:
<a id="clickableAnchor" href="#" style="color:blue;" onclick="alert('clicked!'),">Click me</a>Technically there is nothing wrong with this; the text will be blue, and the JavaScript will run when it is clicked. However, there are several reasons why this kind of code is bad practice:
There is no clear separation of the different types of code. When CSS developers want to change the color of the text, they cannot do so without modifying that page. When JavaScript developers want to change the text in the alert box, they cannot do so without modifying that page.
There is no way this code can be reused. If all our code was written like this, and it was decided that all anchor text should be red, we would have to modify the code in every single place where there was an anchor.
The more code there is on the page, the larger the file to download. In a way, this is restating the previous point because reusable and external code need be downloaded only once. This, however, also has implications for search engine optimization (SEO).
Fewer types of code in a document make it easier to read, parse, and edit.
A more appropriate solution would be the following:
In the head:
<style>
#clickableAnchor {color:blue;}
</style>
<script>
$('#clickableAnchor').click(function(){
alert('clicked!'),
});
</script&gr;[2]In the body:
<a href="#" id="clickableAnchor">Click me</a>
This method breaks our three languages apart; it is much tidier, but there's an even better solution:
In the head:
<link rel="stylesheet" href="/css/screen.css" /> <script src="/js/main.js"></script>
In the body:
<a href="#" id="clickableAnchor">Click me</a>
This solution finally separates our three tiers; it creates separation of concerns. Now these files can be easily shared across many pages and cached for better performance. Our tiers relate in the front-end realm like so:
HTML: data
CSS: presentation
JavaScript: behavior
Let's touch on these in a little more detail.
For the purposes of websites, we usually refer to this as content rather than data. You will often hear the phrase "Content is king," and this is good advice. Your markup should be semantic and well structured; on its own, it should read as a valid and sensibly ordered document. This ensures that machines as well as humans have a good chance of understanding both the intent of the content within the document and the words. If a piece of content is a heading, it should be marked up as such (instead of being marked up as, for example, a paragraph set in bold); if it is clearly a list of items, it should also be marked up as such (as opposed to a succession of divs or some other less relevant element), and so on. When machines understand our intent, they have the ability to do the following:
Understand what a page is about and which parts are more/less important—this is especially important for search engines and assistive devices.
Display the page in different ways without affecting legibility (for example, by using user style sheets). This also means that your website can degrade gracefully in older browsers and display your content in a way that does not impede comprehension.
Allow access to the data in a nonlinear fashion, which is, again, particularly useful to assistive devices.
This layer concerns itself only with how the page looks. Anything superficial or purely decorative goes here. If you are choosing the font, laying out a page, or changing colors, this is the appropriate layer. If your branding calls for text to be in lowercase or for very small headings, we can do that in CSS without ruining the semantics of the "true" content in our page.
This is sometimes called the Logic, Business, or Business Logic layer. Where we are interacting with the page in nonstandard ways—for example, dragging and dropping, or making Asynchronous JavaScript Across XML (AJAX) requests (a method of fetching information from the server without requesting an entirely new page), the JavaScript is the part responsible for this.
Although the resulting benefits of the tiered approach are clear, it is never as clear-cut as we have just made it seem. Expressions can reside in CSS files, making calculations (although we do not advocate it). JavaScript can be responsible for presentation (such as the appearance/animation of menus). Sometimes JavaScript is responsible for adding new content to the page. There are many other examples. However, intending and attempting to separate the layers in this manner gives us a good starting point, and approaching web development in this way can often result in new and clever ways to avoid duplication of content and maintain high performance.
With these basic pieces of information under our belt, we're ready to get started. The first chapter will introduce you to the importance of process. Although not strictly a CSS subject, it is an important base to build your projects upon.