How to build up to good CSS
Avoid problems associated with a quick fix by creating a stable workflow.
Ice Curtain (source: Pixabay)
A long time ago (circa 1999) a creative director tried very hard to convince me how great working in print design was compared to web design. One afternoon before a big event for a Fortune 100 company, she showed me an invitation her team had been working on for the past 2 weeks. It had folds, panels, and colors that would wow anyone. It had just come back from the printing press and she was excited to show me how amazing it was. She began reading me the big invitation title first — to her horror she found that there was a spelling mistake on the cover. The entire set of 10,000 invites would have to be thrown in the trash and at the cost of $15,000 — that would be hard mistake to swallow. She was speechless.
My response to what had just happened was this…”That’s why I like designing for the web. I would have been able to change that spelling mistake in 5 minutes…”
Learn faster. Dig deeper. See farther.
At that point in the web’s history anyone with a web connection, an FTP program and a text editor could edit HTML code on the fly. It really was the wild wild west of web development — this was the web’s best and worst attribute. For many young developers and designers it gave us a chance to create, edit, and publish web pages as fast as we could code them.
So why was the creative director so high on print design? At that time web design was limited to using three fonts, using images of custom fonts, using a very limited color palette, and using simple coding techniques to make not so exciting web pages. The ability to quickly change our code was there, but the visuals of web design lacked the impact that we all wanted to attain.
One technique that was common at the time was creating a large array of table cells, fitting and cutting graphics, slicing them, and then dropping them into the table’s cells. It was the cheap and dirty approach to positioning images, text, and making dynamic visuals on the page. This web design technique was completely not scalable and not flexible to different screen sizes. If you were off by one pixel it would throw the entire table off, let alone if you used merged cells that made things unstable. I now laugh at that technique, but most pages at that time were built using that technology and code… I am guilty as charged for developing several sites like this.
Cascading Style Sheets’ (CSS) introduction was life changing to web developers and designers. For the first time it gave us an ability to create flexible web designs without having to embed styles into our HTML code. CSS was simple, easy to use, and it was flexible! It gave many of us a way of quickly editing our pages’ visual design without ever touching the HTML code. It introduced an entire new way of using the basic HTML code to create visual web pages and it gave us a whole new way of adding attributes to new classes and HTML code elements.
We quickly found entire new ways to push the boundaries of CSS by manipulating ids, classes, and divs. We found interesting ways of adding backgrounds, colors, images, text and AJAX to the equation. As we grew with CSS it expanded too and gave us more and more attributes with every new version. Yet as CSS became the standard for designing and coding visual web design it also created an entirely new set of problems. Browser support was spotty, tags that worked in one browser didn’t work in another, and more importantly the use of attributes was inconsistent. Padding worked correctly in Firefox, but in Internet Explorer the padding width would add itself to the total width of the div. In some instances CSS attributes worked on the PC while on the Mac they looked completely different. This drove many web developers to keep two workstations open (one Mac and one PC) with every browser open to check the code as the page got built.
As content management systems (CMS) got more commonly used on the web, we began using CSS style sheets to control dynamic page templates instead of static web pages. CSS played an integral part in the ability for the developer and non-developer to quickly change, edit, and publish both the design and content.
The CSS style sheets began controlling visual design flavors of themes itself — harnessing the power of the CSS. As this happened the use of multiple style sheets per page templates, themes and even pages emerged. Instead of one large style sheet, the dynamic nature of the CMS encouraged developers to create multiple style sheets that could be combined as appropriate. As these would be created automatically by the CMS itself, we would sometimes have to find a class style that might be hiding across multiple files.
CSS now influences how we design web pages themselves. A designer or developer can now use native CSS code to create the visual styling of page elements. A completely different approach than the technique we used in the past where we used images and markup to create those same page elements. For example, prior to CSS 3.0 we used tables and an image of a rounded corner to create a box with rounded corners. Now we use the “rounded corner” attribute to accomplish the same effect. The web browser does more and more heavy lifting for us, rendering rounded corners, colors, gradients, dropped shadows and even transparency. Newer CSS-based technologies are now looking at extending CSS to become a more dynamic programming language. Technologies like Sass add a scripting language into CSS, Mixins add object-orientated references, and while media queries give us the ability to change our CSS code for different browser sizes including tablets and smartphones.
As CSS has grown more complicated, so have the teams that build web sites. We have gone from a single developer who can edit code on the fly to a team that might include several web developers, UX designers, DevOps, performance engineers, prototypers, and UI designers. With all these people on your team, building for the web is complex, dynamic, and fast paced. It can also be an organizational nightmare. Who changed what page element, what changed to match design, versus what page elements were changed because they were too expensive (too heavy in size or load time). Teams have to take code that was built for a prototype and convert it into a production site. Having to optimize HTML code, JavaScript, and CSS to load faster. Having to change existing CSS and HTML code to respond to mobile devices and tablets. I would never have dreamed of these in 1999.
One thing hasn’t changed since I started writing CSS code.
You need to organize your code. Create a structure for yourself when working with CSS. Quickly changing code is great, but can sometimes be your undoing. To avoid those problems, create a stable workflow. I make myself organize my CSS coding into three stages.
-
Create a non-functional requirements document – Create a guide for yourself before you even start. Specify which browsers you need to support, accessibility requirements, screen sizes, and specific technologies you need to use or have available. This document is my road map for myself and I even have the team or a client sign off on it. It’s all about knowing what I am going to build first.
-
Create a style guide – Instead of jumping in feet first, you will need to focus on creating a style guide for every page element you will encounter, every font style, and every user interface element. You will use this as a library for the project. The goal is to create a style guide where you can focus on building these separate page elements and reuse them over and over again. It is also easier to build them without the pressure of trying to build them inside the pages you are designing. When you are done, get this approved by design and store it for future use in your library.
-
Create a page template – Now that you have your style guide and your roadmap of what you are building, you are off to the races! Focus on creating page templates for all of the page types you will encounter in your project. It is easier to build these separately and then copy them into your CMS. Once in the CMS you can combine your page template and style guide. Use your page templates to test, share, and create more page types.
Plan what you will be building. Take time to set up your project. Spend time breaking designs down to core page elements. Then structure pages correctly and choose the right classes and divs… This is the hardest part…
…Coding the pages is the fun and easy part.
Editor’s note: if you want to learn more about organizing, developing, and optimizing your CSS, check out Adrian’s CSS for Designers video workshop. It’s free to start and provides everything you need to quickly learn how to solve a wide range of style issues with CSS.
This post is part of our ongoing exploration into the relationship between discipline and long-term maintenance.
Public domain ice curtain image via pixabay.