The Future Of CSS: Embracing The Machine

Advertisement

Designers hold CSS close to their hearts. It’s just code, but it is also what makes our carefully crafted designs come to life. Thoughtful CSS is CSS that respects our designs, that is handcrafted with precision. The common conception among Web designers is that a good style sheet is created by hand, each curly bracket meticulously placed, each vendor prefix typed in manually.

But how does this tradition fit in a world where the websites and applications that we want to create are becoming increasingly complex?

Looking Back

If we look back in history, deep into the Industrial Revolution, we will see a parallel with what will happen with our handcrafted style sheets once the complexity of the products that we want to build becomes too great.

The Industrial Revolution1 (which took place approximately between the middles of the 18th and 19th centuries, starting in the UK) was a period of upheaval in society; several aspects of life were changing. Much of this was due to the way people produced goods: during this period, manual labor started to become mechanized. The textile industry, for example, moved from primarily human- to machine-based production, and its artisans started looking at ways to be more efficient.

C. P. R. passenger train at Donald Station, BC, about 18872
One of the many products of the Industrial Revolution. (Image: McCord Museum3)

These machines that were created with efficiency in mind were initially quite primitive, and the public didn’t know what to think of them. It took us some time to adapt the way we worked with them and the way we thought of them.

Jobs that previously required human labor now didn’t require anyone; a machine could do the job cheaper and faster; employees became redundant. But the jobs in which people were being replaced by machines were mainly repetitive ones, jobs for which manual labor didn’t necessarily make for better products — at least not in any significant way.

Some argued that the output suffered in quality, that machine-made objects lacked personality, that craftsmanship was being lost, and yet production improved and evolved. We were also getting to the point that some products were getting too complex to be made by hand anymore.

This revolution shaped the world we live in today and gave us access to things that were until then too expensive or even non-existent.

Getting back to our topic, we’re seeing increasing complexity in the world of Web design and CSS. We want to create increasingly complex websites and apps — systems so complicated that they cannot be made entirely by hand.

MobileMe Calendar app4
MobileMe5, with its extensive functionality and comprehensive interface, is an example of a complex Web application.

The World Of Developers

Developers and programmers are already inclined towards automation. Developers instinctively avoid reinventing the wheel. They understand the need to automate production (at least some stages of it); they understand that hand-crafted code is not needed at every step of the process.

Even if you are a great front-end developer who knows JavaScript like the back of your hand, you still defer a lot of your work to jQuery86 or some other library. Even if you’re able to write the code yourself, the time you’d save by not doing that frees you to deal with more significant problems. The gains in writing a script from scratch are no match for the gains in being able to focus attention on problems that no machine or automated process can solve.

jQuery website7
jQuery86, a well-known developer’s tool.

The skills and knowledge you’ve gathered through the years are not in vain, though. This knowledge is what makes you the best person to decide whether to choose jQuery; it’s what makes you able to adjust a plugin that doesn’t quite do what you need; and it’s what makes you capable of determining the best tool for the job.

The Wrong Attitude

Web designers don’t approve of these kinds of shortcuts. This way of thinking doesn’t translate to CSS; in the world of CSS, taking these “shortcuts” is not well regarded.

We CSS authors have a list of dirty words that we avoid saying when we’re speaking with fellow Web designer friends. For example, when someone says they’ve used a CSS framework, the apology immediately follows: “It wasn’t our fault.”

Principles such as DRY (don’t repeat yourself)9 are not present in CSS.

DRY states that “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” This applies not only to code but to every aspect of a product, such as design itself. When DRY principles are followed, we’re supposed to end up with products that are of higher quality and easier to maintain.

We CSS authors don’t think of the cost of maintenance or the increased complexity that duplication and cancelling out of styles add to our CSS sheets.

We usually follow something closer to WET: we enjoy typing10. Why someone would want to hand-code vendor prefixes for CSS gradients is beyond my understanding, but the truth is that some people do, and they take pride in it.

CSS authors — i.e. Web designers who write CSS — don’t like the machine. We don’t think any CSS that the machine can produce will ever be as good as the one we make ourselves by hand. But what if this is not true? What if the result is as good as our own manual labor from scratch?

Other groups have had the same fears. The Luddites11 were workers who fiercely opposed the Industrial Revolution and progress. They said that machines were taking their jobs — which was true. But they fought, protested, became violent and eventually lost. Things would evolve whether they liked it or not.

Luddites, frame breaking12
The Luddites, smashing the machine. (Image: Wikipedia13)

Context Matters

It’s true that we don’t all code for the Facebooks and Yahoos of this world; your CSS’ performance might not be the most important thing to focus on in your projects. But this is why considering context matters, and this is why it’s important not to dismiss techniques and solutions because someone once told us they were wrong or dirty.

We can embrace the flexibility that some measure of automation gives us and focus our worries and energies on deeper problems. We could focus on so many things: accessibility, usability, design theory, psychology, business, economics, experimentation and even programming are all suitable candidates and are areas in which having some knowledge, even at a basic level, can greatly improve our work.

Reading list14
An interesting reading list. (Image: Mike Kuniavsky15)

Expanding our skill set can give us a better understanding of the products we create, the people we create them for (and their context), and how they are supposed to work behind the curtains.

Rethinking our processes might lead to better quality work. It might lead to perfecting a machine still in its infancy. If we don’t deny mechanization from coming into our work, we get the chance to shape it so that it does exactly what we want it to do.

Try This At Home

If we look around, we’ll see that several people are already trying to change the way we write our CSS, whether by introducing some kind of automation or by looking at ways of creating style sheets that don’t bypass issues such as maintainability. We can take inspiration from the work they produce in a number of interesting ways. Below are some of the most prominent examples, but feel free to add your own list in the comments section.

Frameworks: Don’t Reinvent the Wheel

As mentioned, “frameworks” are probably the dirtiest word in a CSS author’s vocabulary — or second dirtiest, after “Dreamweaver.” (Note: this article was written before the advent of Adobe’s Muse.)

Often when discussing the subject of this article, people walk away assuming that the message I am trying to get across is to use CSS frameworks. That’s not correct. But it isn’t entirely incorrect either. Let me explain.

Frameworks are an important tool in a CSS author’s repertoire. By that, I don’t mean that you should blindly use popular frameworks such as Blueprint1916 or 960 Grid System17. Sure, these frameworks have nailed some things, and we can certainly learn a lot from their flexibility and modularity, but it’s more important that you — especially if you’re on a team — adapt a framework to the needs of you, your company and your team.

Blueprint website18
Blueprint1916, a popular CSS framework.

Perhaps you or your company works with such disparate clients and projects that a framework wouldn’t really be helpful, though. Perhaps a library in which you can collect snippets of frequently used code would be more useful. Or perhaps a starter template is what you need.

Whatever you need, more often than not you can find a way without having to reinvent the wheel from project to project. And if indeed you work with a number of other designers and developers and share CSS, then these tools will make collaboration easier, and you won’t have to adapt to the style of the person who created a particular file.

Frameworks can also be useful tools for wireframing and prototyping, especially when there are time constraints and you need to put something in front of users or stakeholders quickly.

There are differences between a framework and a patterns library, components or even a simple collection of code snippets. A framework is a system that is flexible and can be adjusted to a myriad types of layouts, creating various page templates, whereas a library constitutes smaller individual modules that don’t have to be tied to any particular overarching framework or page construction.

A pattern demonstrates how, for example, tabbed navigation should function or how to mark it up; a design component could be the exact visual representation of an instance of tabbed navigation, with its colors, shapes and fonts. This explanation of these two distinct and important concepts is very simplistic. The “Further Reading“ section at the end of this article lists some useful resources on both.

Yahoo's Design Pattern Library20
The Yahoo Design Pattern Library21.

A framework doesn’t have to spit out numerous unsemantic class names to every container in your markup. If you are creating your own, you are free to name those classes whatever you feel is right.

Let’s imagine you are starting to write a framework that can be shared across various development teams in your news organization. You might start with the following skeleton:

/* Resets */

/* Structure */

/* Global elements */

/* Visual media */

/* Article structure */

/* Forms */

/* Tables */

/* Reusable */

This structure is probably similar to many of your own style sheets. Let’s look at the “Article structure” section as an example of something that would probably benefit from some framework inspiration. In the project, you will probably have to accommodate several variations of templates from various departments, sub-departments, content creators, editors, etc. Rather than using classes like span-6 and pull-3, you can define a naming system that better ties into the website’s content. For example:

/* Article structure */

article {
	width: 80%;
}
article.charticle { /* Charticle pages have no sidebar */
	width: 100%;
}
article.listicle {
	width: 70%;
}

article > .headline {
	font-size: 2em;
}
article.feature > .headline {
	color: #000;
}
article.breaking > .headline {
	text-decoration: underline;
}

article > section {
	border-bottom: 1px solid #efefef;
}

article > aside {
	background: #efefef;
	padding: .5em;
}

article > footer {
	font-size: .9em;
}

Several things about the above CSS could be debated (I’m sure many of you have strong feelings about descendent selectors and named elements and even whether some of these classes could have been simple element selectors — to name but a few points), but none of this matters in this example. What does matter is how you can be influenced by what popular do-it-all frameworks are doing, and how you can apply that to your clean, semantic and perfectly named markup and CSS.

If you can plan for and analyze the needs of the people who create the content, then you can ensure that they have the flexibility they need to do their jobs and that you can be proud of your code. Sometimes an extra class is necessary, but if that makes everyone’s life easier, then why not, right?

Think of Others

Following what we discussed in the previous section, the fact that your CSS doesn’t live in a vacuum can be extremely useful.

Other people — and the future you — might need to come back later on to edit the style sheet that you’re creating today. Wouldn’t you want your future self to be free to go home to your spouse and kids earlier on a Friday afternoon rather than have to stay up late refactoring a CSS file that is hard to comprehend and impossible to extend?

Do yourself and others a favor by considering what you’re doing. Add comments to your CSS files for such things as the following:

Calculations
Font sizes (especially when dealing with ems) and layout measurements are great candidates for these types of comments.

h2 {
font-size: 18px;
line-height: 1.167; /* 21 (original line-height) / 18 (h2 font-size) */
}

Hacks
On the rare occasion that you use a hack, explain what you’re doing, refer to the hack by its common name, and link to an online reference that explains what you’ve just done.

aside section {
float: left;
width: 50%;
display: inline; /* fixes the double float margin bug on IE5/6. More on this bug/solution: http://www.positioniseverything.net/explorer/doubled-margin.html */
}

To-dos
Even CSS documents have “nice to haves,” so listing what you’ve been planning to do but haven’t gotten around to yet might be a good idea.

/* To-do
Change all colors to RGB format.
Sanitize reusable classes section.
*/

File structure
Summarizing what is contained in a particular file can save time when someone is looking for a certain selector.

/*  Table of contents
Resets
Structure
Links
Typography
Small screens
*/

Dependencies
Is this file being imported by some other file? Does it override something else? Explain what and how.

/* Christmas style sheet 2011

Overriding: main.css
Importing reset file: reset.css */

The fact that CSS comments are not standardized could cause a problem with all of this preparedness: everyone does them differently. In my quest for the ideal CSS formatting style, I discovered the dusty CSSDOC standard22, which tries (or tried) to introduce some kind of sanity to the situation.

CSSDOC website23
The old dusty CSSDOC24 website.

CSSDOC is an adaptation of Javadoc25 (a documentation generator that extracts comments from Java source code into HTML). It is also similar to PHPDoc26, Javadoc’s adaptation for PHP. A comment that follows the CSSDOC format (a “DocBlock”) looks like the following:

/**
 * Short description
 *
 * Long description (optional)
 *
 * @tags (optional)
 */

Every block starts with /** and ends with a space followed by */. Every line must start with a space followed by an asterisk. The tags may contain information such as @author, @copyright, @todo and so on.

The CSSDOC standard suggests that a CSS file should include a comment about the file itself at the top, containing meta data that is relevant to the whole file. This comment should include information such as the title of the document, a description and tags such as @project, @version, @author, @copyright and even @colordef, indicating which colors are used in the file. The file comment may be followed by any number of section comments that divide the style sheet into relevant blocks. Section comments include the tag @section:

/**
 * Typography
 *
 * @section typography
 */

The CSSDOC documentation is not lengthy. Also, it hasn’t been maintained for a while, but I did find it interesting and have started applying it to my projects because it takes some of the guesswork and subjectivity out of comments.

Another way to make sharing documents on a team easier is to standardize the style. We all have our preferences on how to format CSS, how to name classes and IDs, address bugs, etc. Creating a style guide that recommends a way to do these things in your company will make it easier for anyone who edits the CSS to dive straight into what they need to do, rather than having to decipher someone else’s style.

This may be overkill for a team of one or two, but it can improve efficiency and save time when the team grows. In this case, consistency should have final say; personal preference is not important. If you’re the only one on a team of 12 who prefers single-line CSS, you will have to take one for the team. (Pardon me if I sound bitter; perhaps I still recall what happened on my own team…)

Here are some examples of style guidelines:

  • “Class and ID names must be lowercase.”
  • “Do not specify units for values of 0 (zero). They are unnecessary.”

When creating a style guide, include a succinct explanation for its inclusion, otherwise it will be easy for people to challenge it. The BBC has some great examples of guidelines27 that are relevant to CSS authors.

BBC's CSS Guidelines28
An example of CSS guidelines29, part of BBC’s “Future Media Standards & Guidelines” documents.

Learn About Object-Oriented CSS

Object-oriented CSS30 was started by front-end performance consultant Nicole Sullivan. The methodology brings modularity and flexibility to CSS by forcing you to create small flexible style sheets.

It follows two main principles. First, it states that an element should behave predictably, no matter where you place it on a page. So, a child element should behave the same independent of the parent, and parent elements shouldn’t need child elements to render correctly.

The second principle is that the rules that control the structure of elements should be separate from the rules that control their skin.

So, if you look at the pages that you need to build in a modular way and think of individual objects first and the pages second, then after creating the initial CSS you should be able to build any page layout using just the existing modules.

All of this sounds great, but object-oriented CSS does have some drawbacks.

For instance, in order for an element to be adaptable enough to be placed anywhere on the page, the name of its class should also be flexible. If you style a box and give it a class name of footer, and later on you decide to apply that style to a box in the sidebar, then the initial class name you gave it will be wrong — it’s not flexible enough. Thus, class names in style sheets that follow object-oriented CSS can sometimes be less content-driven or less semantic than we’d like.

Despite its drawbacks, object-oriented CSS has its value in certain situations. If we are working on a big website for which a small style sheet (small file size) and flexibility and maintainability are important, then following the principles of object-oriented CSS can bring huge improvements to our processes and huge savings to our company.

Once again, you don’t have to follow this methodology blindly in order to gain from its benefits.

Going back to the news company, let’s imagine you want to make a box that sits in the sidebar more prominent than other elements contained there. You might write the following CSS:

#sidebar .highlight {
	background: #efefef;
	border: 1px solid #000;
	box-shadow: 0 0 .5em #000;
}

#sidebar .highlight > h1 {
	font-weight: bold;
}

What’s so wrong with the CSS above? If you are following object-oriented CSS, then you shouldn’t restrict a style that you will probably reuse in the main content area by confining it to the #sidebar container. In our example, though, we’ll happily keep the descendent element selector in the second rule (object-oriented CSS advises against child elements being dependent on parent elements, but you can draw the line on how closely to adhere to a particular technique as you see fit, and that’s the beauty of it!).

So much more could be said about this technique. It is indeed well worth looking into31, all bias aside. You will read things that you probably don’t consider good practice, but remember: context is important, and your expertise equips you to adopt the principles that will help you in your situation.

Step Into Programming

The command line is a boundary between designers and developers that we designers usually don’t want to cross. Instructions on opening the terminal can be quite intimidating for designers if they’re not familiar with it. I confess I’m guilty of steering clear of it most of the time.

But consider this: we keep talking about how we should learn and draw inspiration from the past — from print design, for example. We claim with pride to have deep knowledge of typography, color theory, layout, grids and scales. We see it as a requirement for anyone who calls themselves a professional designer.

This knowledge should be extended to encompass programming, at least at a basic level. After all, it is what powers our most precious creations.

Instead of being inspired by architecture — by its teachings, its processes and its vocabulary — why don’t we get inspired by the architect’s example, by what they have to learn? Why not be inspired by the multitude of disciplines that an architect has to know intimately in order to be a great professional?

Radiant City Model Lac Leman32
How many disciplines can you spot in this model? (Image: n fiore33)

Why not start now? Open Terminal. (Go on, don’t be scared. It’s only there to help.) Now type the following:

$ gem install sass

(You don’t have to write the $; it’s just there to indicate this is a Terminal command.) There, you’ve just installed Sass (which we’ll cover shortly). That didn’t hurt, did it?

If you’re working on a Sass file, you could type the following simple command to make the original Sass-formatted file automatically update the corresponding normal CSS file whenever changes are made:

$ sass --watch style.scss:style.css

The List Goes On

There are several more tools you can keep in your arsenal that can move CSS another step into the future.

Quite a few Web designers and CSS authors are becoming enamoured with CSS preprocessors such as Sass3634, which make it possible to extend CSS’ syntax to include, for example, variables, complex calculations and nested selectors. Not only do they enable you to use functionality not yet available in normal CSS, but you can increase efficiency by automating tasks such as updating a frequently used color on a file-wide basis, rather than having to change each instance by hand.

Sass homepage35
The increasingly popular Sass3634.

And with all the improvements brought by CSS337, even pure and simple CSS is becoming more powerful, enabling us to create very complex layouts and animations more easily and with fewer lines of code.

The list presented here is a short one, and I’d be happy to know what techniques you apply in your own projects to make the process of writing CSS more fluid and to make your style sheets smaller and more easily maintainable and sharable.

This Is Just The Beginning

Eric Meyer says38, “You can’t identify a code craftsman by whether or not they use this framework or that language. You can identify them by how they decide which framework or language to use, or not use, in a given situation.” This statement couldn’t be closer to the truth. Discussing tools without context is pointless.

Saying that something is good or bad should be done in context. By deciding that a certain technique is fundamentally flawed because someone once said so, and holding to that opinion throughout your career without ever challenging it, is not what being creative is about.

In his Critique of Pure Reason39, Kant says, “Have the courage to use your own intelligence.” I would ask you to set your biases aside when when speaking about tools, techniques and processes with other designers and developers who write CSS. Don’t view different opinions as a sign of ignorance or poor craftsmanship.

Certainly, we may question certain aspects of our jobs as Web designers, and whether to be more liberal in letting automation into our processes is just one of them — but one I’m particularly interested in.

I know and work alongside very intelligent and creative programmers. These are people who understand systems so complex that my brain shrinks every time it tries to even begin to understand them. These are also people who are proud of their work, true craftsmen of their times. I find it quite interesting how these two groups (CSS authors and programmers) work on the same products but in such different ways, how they both work with code but with such contrasting values.

There is a place for carefully handwritten, handmade, perfect CSS — I take great pleasure in this myself. But there is also a place for the study and perfection of a more mechanized approach to style sheets. Both can certainly run side by side.

What are your views on this subject? Have you been trying to automate any part of your CSS writing? Do you think style sheets should always be handcrafted?

Further Resources

Hopefully, I have linked to all of the resources used to write this article in the article itself. Here are a few more interesting reads40 that touch on this subject, if not in its entirety at least partially.

Front page image credits go to Creativity10341.

(al) (il)

Footnotes

  1. 1 http://en.wikipedia.org/wiki/Industrial_Revolution
  2. 2 http://www.flickr.com/photos/museemccordmuseum/5324104788/
  3. 3 http://www.flickr.com/photos/museemccordmuseum/5324104788/
  4. 4 https://www.me.com/
  5. 5 https://www.me.com/
  6. 6 http://jquery.com/
  7. 7 http://jquery.com/
  8. 8 http://jquery.com/
  9. 9 http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
  10. 10 http://c2.com/cgi/wiki?DontRepeatYourself
  11. 11 http://en.wikipedia.org/wiki/Luddite
  12. 12 http://en.wikipedia.org/wiki/File:FrameBreaking-1812.jpg
  13. 13 http://en.wikipedia.org/wiki/File:FrameBreaking-1812.jpg
  14. 14 http://www.flickr.com/photos/mikek/3504927651/
  15. 15 http://www.flickr.com/photos/mikek/3504927651/
  16. 16 http://www.blueprintcss.org/
  17. 17 http://960.gs/
  18. 18 http://www.blueprintcss.org/
  19. 19 http://www.blueprintcss.org/
  20. 20 http://developer.yahoo.com/ypatterns/
  21. 21 http://developer.yahoo.com/ypatterns/
  22. 22 http://cssdoc.net/
  23. 23 http://cssdoc.net/
  24. 24 http://cssdoc.net/
  25. 25 http://en.wikipedia.org/wiki/Javadoc
  26. 26 http://en.wikipedia.org/wiki/Phpdoc
  27. 27 http://www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml
  28. 28 http://www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml
  29. 29 http://www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml
  30. 30 http://oocss.org/
  31. 31 http://www.slideshare.net/stubbornella/object-oriented-css
  32. 32 http://www.flickr.com/photos/nfiore23/4298936281/
  33. 33 http://www.flickr.com/photos/nfiore23/4298936281/
  34. 34 http://sass-lang.com/
  35. 35 http://sass-lang.com/
  36. 36 http://sass-lang.com/
  37. 37 http://www.w3.org/Style/CSS/current-work
  38. 38 http://meyerweb.com/eric/thoughts/2008/04/17/crafting-ourselves/
  39. 39 http://en.wikipedia.org/wiki/Critique_of_Pure_Reason
  40. 40 http://www.smashingmagazine.com/related-resources-the-future-of-css-embracing-the-machine/
  41. 41 http://www.flickr.com/photos/creative_stock/5227842611/in/photostream/
CSS

↑ Back to topShare on Twitter

Inayaili de León is a London-based Portuguese web designer, specialist in cross-browser, semantic HTML and CSS, and clean, functional design. She writes frequently for well-known online and print publications and also on her own web design blog, Web Designer Notebook. In May 2011, she published a book, Pro CSS for High Traffic Websites, and she speaks frequently at local and international web conferences and meetups. She is currently working as a web designer on Canonical's Design team.

Advertising
  1. 1

    For css I’ve been using less quite a lot these past couple of months. Really helps with some tiresome chores (like vendor prefixes, related and calculated css values and reoccurring property groups like .hidden or .hideText).

    It’s a shame this article only talks about css though, as there is much room for improvement in the way we write html (for static templates). We developed an in-house tool that allows us to define the html for a component once and use it through all our templates in whatever variant needed (so 1 global html structure for all product instances on an entire site). Working like that teaches you a thing or two about html flexibility and consistency.

    0
    • 2

      I’d be interested in a tool like that. How and with what program did you achieve this?

      0
      • 3

        It’s not all that difficult to do. In an article I wrote for Smashing Magazine some time ago I hinted at how to do this:

        At my current job, we build such a tool based on components (recurring HTML code blocks) and schemes (outlines of each template that refer to these components). Thrown in some simple program logic (if and loop statements, parameters) and allow for proper nesting methods, and you’re good to go.

        If you have a developer, whipping up such a tool is not all that difficult really.

        0
      • 4

        Manon -

        I too have adopted these concepts, while Niels’ article is pretty good, visual practical application is where it is at.

        The concept of decomposing a design into individual reusable elements and then being able to use those elements to construct a widget in the abstract and then apply those widgets to the screen is a powerful concept and one that will free your code and your mind.

        I need to prove this concept for myself and illustrate into a working model.

        I built this using LESS and while the ‘framework’ I created is pretty rough the concepts is solid.

        Take a look and let me know what you think?
        http://axle.dalesande.com

        0
    • 5

      I’ve actually got an article explaining how to do this. Its called Object Oriented Web Design. zackperdue.com its on the first page!

      0
    • 6

      Inayaili de León

      November 9, 2011 4:48 am

      Yes, there is indeed room for improvement in a lot of areas. I thought CSS was a good start :)

      0
  2. 7

    “Principles such as DRY (don’t repeat yourself) are not present in CSS.” – Very true and a real shame.

    There’s a simple principle that I use that seems to get me by pretty well – “Leverage anything and everything you can to make your company money.”

    Elitism is for hobbyists. Professionals ship. :-)

    0
  3. 8

    A word against CSS preprocessors – that’s an energy (resources) wasteful method, unlike more energy-efficient object oriented CSS (who cares though).

    0
    • 9

      What happened to the replies – are tags accepted
      like <!– notes here –>

      0
    • 10

      Jakub Chodorowicz

      November 11, 2011 3:38 am

      You mean like CPU resources? As far as I know, every CSS preprocessor should actively process CSS (LESS, SASS) syntax only during the development phase and in production already processed, cached and minified version is served. So your argument seems to be totally invalid.

      0
      • 11

        I meant general energy efficiency, first it does preprocessing on the server side, then sends it to the browser which deals with regular CSS. I haven’t done any in-depth research on that yet, but it’s already clear preprocessors do not fit the concept of energy efficiency. Personally i see no point in spending more resourses to get same result. That might sound crazy i know but considering most of power plants use coal and gas it does make sense (or will be when preprocessors get widly accepted).

        0
      • 12

        Important note: it’s clear that client side preprocessors do not fit the concept of energy efficiency. As for SASS, it actually can save production time (and energy spent for that) but as the result you still get a more noisy css (as i’m looking at it from the object oriented CSS point of view) which is not quite good for high traffic websites. Again, i repeat, i haven’t done any research on that yet, so that’s all only in theory AND a good food for thinking.

        0
  4. 13

    Very interesting reading.

    As a lone designer in a team of developers I can quite safely say that I am having to steer them away from frameworks at every turn. My reason? They can’t be bothered to learn CSS; they want something that does it all without having to change a single property.

    The solution has been to develop our own framework of CSS modules that can be dropped onto virtually any application we produce. It suits our coding styles, it suits the content managers and it suits the customers (because we don’t have to work with meaningless container names and additional markup).

    Horses for courses.

    0
  5. 14

    Interesting & informative article.

    I think that the point is to comment your own code, always planning a better workflow and using pre-made scripts for complex development projects.

    0
  6. 15

    This is a great article, thanks for sharing!

    I too love the process of hand-crafted CSS, however, I see tools like LESS and SASS becoming more popular as the web evolves. That being said, I also agree that they are definitely scenario dependent.

    I would argue with your statement of – “Principles such as DRY (don’t repeat yourself) are not present in CSS.” They absolutely ARE. For example, if you have a larger website that uses a variety of styles, it is more efficient to create global classes (ex: .green {color:#6c0;}) to avoid re-using this declaration over and over again in your stylesheet. This does add to your HTML code [since you will assign multiple classes to various elements], but the tradeoff is well worth it for larger sites. This is an example of why LESS and SASS were created… to help organize and reduce the amount of CSS we use, and subsequently to help us avoid repeating ourselves.

    In my opinion, a true CSS master is one who can leverage the power of multiple classes and reduce the use of IDs. You will find that beginner designers tend to use IDs like they’re going out of style, whereas experienced designers only use them when necessary.

    0
    • 16

      Jakob Løkke Madsen

      November 17, 2011 8:13 am

      I totally agree with you, Ali.
      Well put!

      0
    • 17

      Yes, use multiple classes, but if all you’re doing is using them to abstract inline styles then you’re missing the point. A class called “green” doesn’t mean anything. I prefer to use semantic class names.

      For instance, for a status indicator I have one class called “status” which defines the basic properties of the indicator: border, size, etc. Then I have other classes to color it: “good” which is green, “unknown” which is yellow, and “bad” which is red.

      Now suppose I wanted to internationalize this, where good is white instead of green. I could do one of three things (from worst to best):

      1. Use the class called “green” but color it white.
      2. Scatter conditions all over my code to determine if the class should be “green” or “white”.
      3. Create an alternate stylesheet which defines “good” to be white.

      Likewise, if I have two completely unrelated elements that just happen to have a drop shadow, I’m not going to create a class called “shadow” (though I do see this a lot). This is just as bad as using a “b” tag instead of “strong” (HTML is for content; CSS is for presentation).

      0
  7. 18

    This was a great article with alot of valid things to say about the landscape in our industry at the moment. I hope everyone starts thinking about this. Perhaps people trying to think forward should just do whatever they like regardless of what people think of them. As long as they produce great work and others can understand what is going on.

    Just a shame you assumed 100% of your readers use OSX (the terminal bit). Maybe I am the 1%? I’m currently occupying your article.

    0
  8. 19

    At first I was sceptic about your article, when reading the dirty word framework. But the way you meant it was really useful. Too often I have to dig through others’ CSS to find that similar styles are declared in many different places, costing a lot of time and thus money. Such as font-family or line-height.

    The approach I usually take for a project is first taking a few moments to think about which styles are applicapable to multiple elements/locations on the website. And for évery single element that I’m styling, I take a few seconds to consider if this will also be used elsewhere. This saves money in the long run! When you become more experienced in this the time of consideration declines obviously. It dóes save money in the long run and is definately worth it.

    Great article!

    0
    • 20

      Inayaili de León

      November 9, 2011 4:54 am

      Hi Thomas,

      Yes, I think that yours is a very sensible approach, stopping and thinking about the flexibility of your CSS, and most important, planning.

      Thanks!

      0
  9. 21

    What is the flexibility of a grid system that is static and 960px wide.

    0
    • 22

      Inayaili de León

      November 9, 2011 4:56 am

      Maybe none, for someone’s particular needs. That is why it’s important to look into what you can take away from these pre-made frameworks and work on your own, that is more flexible. Of course, if it make sense for you to have a framework, it might be the wrong tool for your requirements.

      0
  10. 23

    Nice article with valid points and thoughtful takeaways. I appreciate the references to the Industrial Revolution. Funny how history finds its various reincarnations.

    “Why don’t we get inspired by the architect’s example”… Well put. Walter Gropius based the establishment of the Bauhaus School on a similar philosophy. What’s more, in a global economy where competition is plentiful, those who acquire knowledge and discipline outside of the requisites will be the ones that stand a better chance at job security.

    Frameworks are definitely a great resource even if you don’t use them. Nothing dirty about wanting to work more efficiently ;-)

    Cheers!

    0
  11. 24

    But I thought CSS already had automation built in. You style one h1 and every h1 across your entire site gets the style applied, from just one stylesheet! That’s a far cry from the inline styles of html4 and below. CSS designers are already using an automated system where we avoid repeating ourselves. We don’t have to style every h1 individually anymore, and that saves time.

    I reject your premise, but I agree that there can be more improvements. You forgot to mention Twitter Bootstrap, an excellent CSS toolkit for building web apps and sites.

    0
  12. 25

    As I was reading this it became more and more familiar!

    Check out a more in-depth look here (from DIBI 2011): http://vimeo.com/27487587

    0
    • 26

      Inayaili de León

      November 9, 2011 4:57 am

      Hi Andy,
      You’re right, this article is giving a few more examples than I could fit in the presentation. I hope you enjoyed it :)

      0
  13. 28

    Nice article about the future of CSS.Thanks for sharing.

    0
  14. 29

    A very well written article. Thanks.

    0
  15. 30

    I used Blueprint successfully for many projects. Now I understand how it works so it is easy to create my own grid. Your article mentions SASS but only in passing. Why use it? Why is that important? Each technology requires a lot of documentation by the community and investigation by the designer.
    I save lots of links to Github scripts and tools that have no explanation of what it is or description of how it works.

    0
    • 31

      Inayaili de León

      November 9, 2011 5:00 am

      Sass is very similar to Less. I usually recommend Sass over the second since it has more documentation, and is not done by a single individual, so it has more accountability. It’s easier to understand how it can be helpful by experimenting with it. For example, you can save all your vendor prefixes for things like animations, gradients, etc. and then just call them with a few characters when you actually need them. But this is only a very simple example, it can do a lot more complex and useful things :)

      0
  16. 32

    The analogy with the Industrial Revolution is interesting, but upon thinking about it a little bit more, it doesn’t match.

    Back then, people were replaced by machines because the repetitive work could be done faster/cheaper. However, these machines were used for mass production of whatever they were making. The same product was made over and over and over again.

    CSS authors do not (usually) create the same web site over and over again — each one is (fairly) unique. The pages WITHIN each web site could be seen as mass production perhaps, but that already IS automated (CSS itself, mainly; we create one file and it can apply to all those pages within the site).

    This whole automation process is not the future; it’s the present.

    0
    • 33

      Inayaili de León

      November 9, 2011 5:04 am

      When I work on commercial projects I find myself starting from the same generic bare bones CSS, using the same kind of snippets (tabs, vertical navigation, sliders, galleries) that I created for one project adjusted for another project. I find the same when working as an in-house web designer, creating multiple sites across the company. And I find it in conversation with other web designers: there is a lot of repetition. You’re right, the things I mention in the article are the present, but maybe we will see an increased level of automation in the future—that’s the message :)

      0
  17. 34

    “CSS authors — i.e. Web designers who write CSS”

    ummm….. NO. That’s a really large misinformed generalization.
    I’ve been a CSS author for 11 years now (along with other front end technologies). Am I a designer? Hell no.

    0
    • 35

      Inayaili de León

      November 9, 2011 5:07 am

      Hi Rory,

      That was actually a change made by the publisher, not my original text.

      0
  18. 36

    I always find funny these so called expert opinions about the end of hand-written markup/code call it how ever you want. There was an era when Microsoft told us that Front Page is the only tool you will need for web development.

    The automation like sass, less is good for agile development to speed up delivery time, frameworks are good too in some cases.
    But as I’m more HTML markup writer/coder than designer I usually get designs which fit in none if these frameworks. So either re-size everything while preparing files for layouts, or Make files fit your own CSS. Also making three column design is fast thing even by hand if you can do some math and can define these layout styles in the beginning to keep everything in touch.
    Object oriented CSS??? have you tried to edit CSS after it passes through 3 different web devs and you are the last person to touch it, You can write another markup horror story, as each person has it’s own approach to it which is called I will do it as fast as I can and then just jump to another project. After 3 devs you will find css in spaghetti oriented fashion. Redefining styles in later style, mixing skinning and layout.

    The real dealbreaker would be using such styling There will be no repetition in css. oh and while developing use one line rules. Ok I’m just being ironical here.

    To summarize while writing markup stay sane, take a look how superstar webdesigners write their code. Fit yourself into a set of rules even if you are working online. organize each styling rule int the same manner if in one element you write float in first position do the same in all other. Less strain for your eyes.

    Also the author of article seems to use these high hyped words like object oriented, Sass, also shows how to install it via console as a ruby gem, no pun intended here, but not everyone uses ruby. Also she is the author of book about about writing css for high traffic websites. so I found missing such things as to not forget before deploying your design to minify and merge your stylesheets and remove conflicting duplicated rules by hand.

    0
    • 37

      Inayaili de León

      November 9, 2011 5:22 am

      Hi Marius,

      This is exactly what I said on the article: discussing or arguing about tools without context is pointless. Also, if a framework is not the right tool for you, then why use it, right?

      Yes, indeed I have had to edit CSS files that have passed through not just 3 but 5 or 10 devs; it’s not the funnest thing in the world, but it’s my job and it’d be unprofessional if I were to reject the challenge.

      I have found that on sites where pages need to be built quickly and flexibly, an object-oriented approach (as defined by Nicole Sullivan, I didn’t invent the term) makes everyone’s life easier.

      As for the things missing (that are in the book you mention though), maybe you can accept the challenge of writing an article walking us through your own process? I’d be interested in reading that, as I’m always looking for ways of improving my methods ;)

      Thanks for reading.

      0
      • 38

        My process is currently simple as this, I have kinda skeleton css where my container, header, nav, content and footer areas are defined and the initial width is easy to change. So after I get to do psd2html conversion. Also I have skeleton HTML which has the above mentioned areas predefined. I also reset.css so I know that there are no margins and paddings anywhere it takes a lot of guesswork out of the process, and also I’m finding that by using reset css less red flags is raised in older browsers. I also use comments for both css and html for HTML where one or another div ends, and in css just for keeping an eye for structure, Then I move to styling the appearance of the website still in the same css. As it’s always only one variation of design I do not use external style sheet for that. I also try to style all elements globally, and then use classes or id’s depending on case to style element individually. I also constantly check against older browsers for degradation and not breaking down, as I’m big believer that the design may look a little bit stripped no shadows or rounded corners, but it still deliver content as It was designed. I know this process is kinda clumsy, but it let’s me to keep amount of css to minimum.

        I have had previous experience with Drupal, developed couple of themes and really can’t approve their approach with css, where everything is scattered amongst many places, and you ending up with tens of stylesheets to modify, or duplication on styling elements.

        I have used many things and really adored using 960.gs, but after some time I understood it does not give me flexibility I need, and if you have knowledge on how css works, it is as fast as coding by hand. I have also used less loved the way of declaring colors and so, but have not had any chance to look over compiled css due to time frame.

        In the end I think writing good css and htm markup is a skill acquired with experience. As you must see how elements are grouped, and whether it can be easily styled differently if needed.

        I know there is a lot to learn for me. But each time I do new project I’m finding new way to improve myself. These Eureka moments is what you keep going forward. But still I do not support object oriented way to handle stylesheets :)

        0
  19. 39

    Some time ago we wrote that

    Coding “…tools are developed by people, not by hostile aliens from Mars or anywhere else. So, the question ‘What is better – automated coding or hand coding’ is equal to ‘Who is more clever / successful / achieves more progress – coders who slice manually or programmers who try to create a universal intermediate system to automate the process once and for all.’

    The second task is more complex. But… 30 years ago there were no:
    * Home PCs, notebooks, Xboxes, PlayStations;
    * Mobile phones, iPhones, iPads;
    * Internet;
    * Google, Twitter and Facebook.

    So what about 30 years after now? Can we imagine that new world? It is very likely that the general level of programming, artificial intelligence systems, etc. will be enough then to develop perfect coding tools. The question is whether such tools will be in demand in 2040s because there could appear a new generation of the Internet or even absolutely new information transfer channels (telepathy? why not).”
    ( http://www.htmlcut.com/blog/what-is-the-best-psd-to-html-conversion-tool.html )

    Sorry for quoting that large chunks.

    0
  20. 40

    As an amateur HTML programmer I prefer to write the HTML code first then add the classes and id’s in a css file. However correlating the various css elements is time consuming and makes for errors.
    So I thought that if the HTML were written to include class and id names and element styles where you want them with the HTML elements, then subsequently the code was passed to generate a css file and strip the style out of the HTML, it would be helpful and allow more standardization. Would this defeat the ideas presented above?
    It could be coded in <!– tags in a form similar to the CSDOC above.
    like
    same element later

    0
    • 41

      Looks like something was lost in the posting. A sample HTML might look like:-

      <body>
      <DIV <!– *class=”headline”, Arial, blue, center; *id head1, 1.8em; *–>>
      Headline 1
      <DIV <!– *class headine; *id head2, 0.7em; *–>>
      Headline 2
      </DIV>
      </DIV>

      0
    • 42

      Well I found out what the pblroem was. I dont quite understand it. But the fix is this: Where you use .get method I changed it to .find and it all works great. I am using Sinatra on JRuby with Active Record. Here is the code changes: require ‘rubygems’ require ‘sinatra’ require ‘active_record’ require ‘haml’ ## Setup configure do ActiveRecord::Base.establish_connection({ :adapter => “jdbcsqlite3″, :dbfile => “tasks.sqlite” }) if File.exists?(‘tasks.sqlite’) ## Dont remake database file else ActiveRecord::Schema.define do create_table “tasks”, :force => true do |t| t.column “name”, :varchar t.column “completed_at”, :timestamp end end end end ## Models class Task nil) end def link “#{self.name}” end end Didnt paste it all, just the DB parts I changed. Changing get to find doesnt need pasting. :) Let me know what you think. BTW, I use AR since I cannot seem to get dm to work on JRuby. But AR works great. ) Thanks, John

      0
  21. 43

    To the css purists (luddists):
    by the time you’ll read all of this I’d be prototyping your layout with my framework… html5bp + modernizer 2 (native yepnope support) + semantic 960.gs + Compass + responsive media queries and a preinstalled EE cms… all minified via Ant build script.

    0
  22. 44

    Nice article! As our company has grown from doing a few one-off sites a year to rapid production and deployment of multiple sites, I have moved from “hand coding” to the use of a custom system of frameworks and design patterns.

    While frameworks may be used and abused by some as a crutch, in the right hands they can be very powerful. I use LESS to preprocess my css, and it has a lot more to offer than just making it quicker to write cross-browser CSS3. I have built many custom functions using LESS that let me produce large amounts of complicated code from just a few variables. When it comes down to it, we have ways that we are going to do things: a combination of best practices and personal preferences. The actual differences between one layout and another often amount to just a few rules, so why waste time and energy with the rest? So, the main advantage is definitely speed of production.

    Other advantages of using such a system are:

    ~Consistency (if I write the code in the function correctly, every instance of that code will also be correct – less chance for error)

    ~Adaptability (if I devise a new method of approaching something, I only need change the formula, and all instances of that code are updated at next compilation)

    ~Portability (the components of any chunk of code are dependent on the environment in which it sits, ie site colors, padding, etc. So, my code is built in a way that is relative to its surroundings, rather than absolute values. The gist of it is, if I take an element built in one site and drop it into another, it is going to adapt without me having to figure out the new colors, spacing, etc)

    As has been said, frameworks are merely tools. The real secret is brought to mind by the words of the infamous Aleister Crowley: “Know Thyself.” If you analyze how your mind works and how you are going to approach different coding scenarios, you can organize a system that is both concise and adaptable.

    Crap. There goes my morning.

    0
  23. 45

    why did you say that “dreamweaver” is the dirtiest word of a author’s vocabulary ? I like of Dreamweaver. He auto completes the codes before you write ! thats save a lot of time. what you use to design web sites ? you use the notepad ?

    0
    • 46

      I use Notepad. I also use Dreamweaver but only after disabling code completing, code hints, and the visual editor.

      0
    • 47

      It also “shows” how your site will look in browser :) For code auto-completion there are more tools than dreamweaver and less pricey ones. What I have found while using dreamveawer in early days of my php site coding, that it takes longer to develop using dreamveawer, by setting values with mouse vs. entering them with keyboard. The last time I saw dw interface was back in 2003. Maybe it evolved? But I doubt it.

      0
    • 48

      Hi. Somehow I’ve meissd all the OOCSS story, so I developed a parallel philosophy for my project. My way is simular to OOCSS, but not exactly. I also divide structure from elements (to be able to position blocks on pages independly). The thing is, that I use namespaces they are just a chain of class names in BODY, representing navigational path, just to be able to speak to the .element_x on one page different, than to the same .element_x on the other page. I pack namespaces into variables and use in SASS like that:in my _variables.sass partial I write:$picturesTemplate: .bigproject.our_products.product_x.product_x_pictures in my partial _picturesHeader.sass, that describes this particular element:body &#{$picturesTemplate} .element_xDoing so you can have both library for typical .element_x styles as well as be able to write alteration easily. If I have to differenciate between many nearly the-same elements on one page (what is very rarely), I can alway simply put one more level to the selector and use descending selection. Or, if the elements are too different, just handle them as different elements and give them different names.Sorry for the grammar English is not my strength :)

      0
  24. 49

    Nicolas Gallagher

    November 9, 2011 1:48 pm

    The points about intra-team consistency, commenting, not being afraid to use extra classes to make life easier, are all great. However, you start with a lot of generalisations and assumptions about what CSS authors think and do.

    Web designers don’t approve of these kinds of shortcuts. This way of thinking doesn’t translate to CSS; in the world of CSS, taking these “shortcuts” is not well regarded.

    When someone says they’ve used a CSS framework, the apology immediately follows: “It wasn’t our fault.”

    Principles such as DRY (don’t repeat yourself) are not present in CSS.

    We CSS authors don’t think of the cost of maintenance or the increased complexity that duplication and cancelling out of styles add to our CSS sheets.

    CSS authors — i.e. Web designers who write CSS — don’t like the machine. We don’t think any CSS that the machine can produce will ever be as good as the one we make ourselves by hand.

    I’m going to have to agree with Austen: “CSS designers are already using an automated system where we avoid repeating ourselves.” Furthermore, CSS frameworks – in their various forms – are immensely popular and appreciated. A far cry from being something that the modern developer is embarrassed about using. You just have to look at the popularity of HTML5 Boilerplate, Blueprint, 960.gs, Bootstrap, etc.

    The rise of frameworks, toolkits, pre-processors, and lively discussions about component-based front-end architecture all indicate that a lot of developers (especially those working on non-trivial websites and applications) are well aware about the need for maintainable code. It’s pretty clear that this has been the case for many years and during that time there have been several requests for CSS to help cater to these needs. The increasing use of pre-processors / tooling in modern web development, and the efforts to begin incorporating parts of their syntax into new CSS draft specs, shows how aware and interested CSS authors are in these matters. Arguing that CSS authors are generally averse to shortcuts and code reuse is no more likely to be true than claiming HTML purists fear server-side includes.

    It’s more likely that the barrier for many people is the unknown of how to get started with tooling and the upfront time investment. You give an example of how to install Sass, but that isn’t so simple for the majority of developers who are using Windows.

    class names in style sheets that follow object-oriented CSS can sometimes be less content-driven or less semantic than we’d like.

    There is nothing “unsemantic” about a class name like “span-5″, it just has different semantics to a name like “article”. Renaming “span-5″ to “charticle” provides no guarantee of DRY-er code. It’s more likely to do the opposite if you haven’t really abstracted enough. And that’s the point about a component/template/object-orientated architecture…you’re not trying to make it content-driven because varied content could inhabit near-identical components. So rigidly tying the classname semantics to that of the content can be a recipe for repetition and maintenance headaches.

    0
    • 50

      Hi Nicolas,

      There is nothing “unsemantic” about a class name like “span-5″, it just has different semantics to a name like “article”.

      I may be wrong, but I think when we talk about web design and semantics we refer to the content layer, not the presentational layer. Imho, “article” is relevant to that context while “span-5″ is not.

      (I’m not saying it’s wrong to use such class names though…)

      0
      • 51

        I may be wrong, but I think when we talk about web design and semantics we refer to the content layer, not the presentational layer. Imho, “article” is relevant to that context while “span-5″ is not.

        Class names don’t have anything to do with content, so it is irrelevant for a class name to be or not to be semantic. As long as they are understandable for the team who are working on the stylesheet, these class names can be anything. Take a look at the class names that google uses.

        0
        • 52

          Class names don’t have anything to do with content

          That’s the author’s choice.

          … so it is irrelevant for a class name to be or not to be semantic. As long as they are understandable for the team

          If they are understandable, it means they convey meaning, hence they are semantic. Isn’t?

          Take a look at the class names that google uses.

          I never thought of looking at Google’s markup to learn about best practices ;-)

          0
        • 53

          Whether class names have anything to do with content is sort of up to the author, but it’s very clear that the W3C intended them to be used semantically [1], [2].

          ( the article uses the word “structure”, but the examples make it quite clear that what they’re talking about is what we’re talking about :) )

          – ct

          0
      • 54

        Nicolas Gallagher

        November 10, 2011 2:37 am

        Hi Thierry. What you talk about is one form of semantic that is often treated as the only acceptable one. The content layer semantics are already served by the HTML tags that are used. Class name semantics are not intrinsically tied to content (with an exception being the microformats convention which is read by some machines).

        IMO, it’s more important that they are understandable, reusable, and make sense in a wide variety of contexts. That helps ensure that your components are abstracted to some degree and that the semantics of their class names are not tightly coupled to the semantics of the specific content they may contain at any one time.

        0
        • 55

          Hi Nicolas,
          Yes, we agree on this. The fact that the meaning of these is not tied to the content layer.
          I think many people are struggling with this issue because they believe their choice needs to be related to the content when in fact it would be better for them to forget the content and focus on the presentation – if they want to be able to use and reuse their rules.

          0
  25. 56

    This article hits right at the heart of a very exciting topic. Embracing the future or holding tight to yesterday’s newspaper.

    I have been involved in web development in one way or another since 1996, so I have seen it all and this is just another growing pain for all to endure. Let’s face it, CSS has had it’s day and it is time that this ‘scripting’ language matures into a real dynamic language. I am not going to get into any of the arguments as Inayaili did an awesome job of that.

    The argument over semantics is one that entertains me though. Often you hear people arguing about something where they are agreeing on the topic, but they are simply arguing ‘semantics.’ Inayaili’s point in this article was very clear, semantics are to be taken within context.

    Having spent a lot of time working on either large web applications or enterprise websites, the management of the CSS architecture has always been a challenge. And looking back to 2000, all the frameworks that we have today wen’t options. But the first thing that seemed very obvious was the concept of OOCSS. But there are issues with that solution as well. In a web application where context is pretty static it makes perfect sense to adopt a naming convention that has direct context to the ‘tool’ in your app thus allowing a perfect visual and semantic relationship with your code.

    But in today’s modern sites where context is king and meaning is everything, this can get you into trouble.

    Working on enterprise e-commerce sites, I have quickly learned that coupling to tightly the relationship between a visual element and context of the markup can get you into trouble. So creating more contextually semantic ‘objects’ in your markup allows you to more easily apply changes to the UI without going into the application itself. Rule of thumb, if you have to edit a ton of markup for a simply UI change, you did it wrong.

    So, how do you make this happen? In all my years, I have never used a UI tool more powerful then SASS. This brings all these concepts together in a nicely wrapped package.

    Time for the plug … I speak to a lot of these issues in a post I authored http://goo.gl/1TDSd

    I also encourage others who are ‘interested’ in SASS to also read along as I am trying to meet head on some of the issues related to SASS that people have mentioned in this comment thread.

    In the end we all must face it, the days of authoring hand written CSS are coming to an end. Are CSS processors like SASS and LESS the total future? I say no, but what is the future is writing CSS the way that SASS and LESS do.

    As users of this medium we should strongly advocate for CSS to mature into a real authoring and dynamic language.

    0
  26. 57

    Well, my method is:
    1.: make it caotic
    2.: get lost :D

    0
  27. 58

    Nice article. Lately I’ve been using LESS (http://lesscss.org/) and really like it. Some argue that it generates a lot of CSS, which is true – CSS that you would have had to write yourself. I especially appreciate mixins and variables.

    LESS is actually pretty similar to OOCSS – the difference being where you apply the reusable rule. With OOCSS you apply it in your html as a class. With LESS you apply it in your CSS as a mixin. Both valid approaches, and not mutually exclusive.

    As for automation, LESS.js runs in the browser, compiling my LESS files into CSS on the fly. Then as part of my optimization for deployment, I wrote a little Node script that scans my project, compiles and compresses any LESS into CSS, updates the s to point to the CSS instead of the LESS, and strips out less.js. So I end up with one pretty CSS file when I deploy. Gotta say, writing CSS has never been so good.

    0
  28. 59

    Terrible article. The author really has no clue.

    0
  29. 60

    Nice article. I think there are two meanings for “semantics”: one regards semantic web with automated links cross-referencing and stuff. The other is the more common sense in which CSS classes should make sense to developers reading them, like a meaningful text.

    Commenting on Dreamweaver there only two things I miss (couldnt find them in Notepad++, Gedit, SublimeText etc):

    - Apply code formatting to selection (which is kinda like Tidy but with sensible defaults)

    Oh and please let’s use always lowercase for CSS. I hate things like !Important BTW I should talk to a colleague at work about it and will recommend your article, thx for the time writing it.

    - Transform non-ascii into html entities: á for á

    Sometimes I go to Windows/Dreamweaver just to do that.

    0
  30. 61

    A very poor article, but definitely within Smashing Magazine’s standards.

    0
  31. 62

    I have a great suggestion for what we css coders need. That is, page specific css. Over and over again I have come across a need for page specific commands, i.e. page[url="home.html"] body {height:800px;} This would be a tremendous help and major time saver. There are many reasons why we should include page specific commands.

    1. Large and bulky CMS systems such as Joomla, Drupal, and WordPress, have themes and styles that are applied universally across the site. Instead of spending many hours creating a stylesheet for each page, everything could be centralized in a single document for maximum convenience. Note, the number of requests to the server would decrease too.

    page[url="home.html"] h1 {font-size:20px;}

    page[url="about.html"] h1 {font-size:16px;}

    The page specific h1 on .com/home.html would appear differently than .com/about.html.

    2. Any site with multiple pages, shopping carts, and other similar content systems are in need of something like this. Currently the only work around is to use a lot of javascript, which typically adds hours to each project, and usually doesn’t help much. Now if you think about it, millions of websites use css. If you could save all those people time, well, it really adds up.

    You’d be able to do things that a div with a wrapper #page_id can’t do, for example:

    page[url="home.html"] body {background-image:url(“bg1.png”);}

    page[url="about.html"] body {background-image:url(“bg2.png”);}

    Less time to write code, less javascript, and everybody wins.

    I will be happy to see this adopted.

    Also, additional working drafts of CSS should adapt to the genius of less.css and sass.scss, surely the future of CSS.

    I suggested this on w3.org but it never went through :/ So I figure Smashing Magazine is the next place to post :)

    0

↑ Back to top