Front-End Book

Wouldn’t it be great to have a generic CSS parser implemented in JavaScript in order to move presentational options to the stylesheet instead of having presentational and behavioural settings it in the markup. I ran across the problem the other week when I was writing a jQuery plugin for grabbing external data using getJSON-function. First I intended to only use an anchor as a bootstrap for the jQuery plugin, that worked well until the designers went Andy Warhol and started saying: Sometimes we want this generic solution to be more generic, and other times we want it to be yellow, and sometimes yellow is just not the colour we are after, yada yada. And I replied: As long as you treat those babies the same when they appear on the same page. But of course they had some crack-brain-solution where they would go bezerk on usability and treat all of these generic items as they were specific, I felt the need for some smart way to adjust the presentation via parameters, and I used John Resigs metadata plugin, which is neat when you need to treat every instance passed to a generic plugin specific. But I was a bit annoyed moving presentation settings to the markup, it would have been neat to have a non-standard css-based stylesheet for handling these kind of issues. Typical plugins that could use such a plugin is of course all lightbox-clones (it would be great to move presentation data such as width, height, position to a stylesheet) and form validation plugins and other plugins that are heavy on configuration.

I do not know if this is a good idea, I have to check for existing solutions and see what the side-effects are? Probably someone have already implemented this, but I have yet to find the solution, otherwise I might as well try to write it (and fight all the potential browser bugs that I am sure will evolve during an implementation of such a solution).

Not a big update. 

John Resig is writing a new selector engine, sizzle, interesting

I wonder when John have the time to write code, write books, write documentation, write for his blog AND work for Mozilla. He is one productive client side coding entrepreneur. Sizzle is Work In Progress, but John claims it is 4 times faster than the jQuery Selector Engine.

YUI has a new Interaction Pattern in their library

I do not know how many times I have been part of discussions about how to implement a sign in procedure the best way. This new pattern from YUI tries to describe the characteristics of the problem. I really like Yahoo’s initiative with YUI trying to help designers and likes from revinventing the wheel time after time.

Parallax scrolling made easy with JavaScript

10 years ago something, we believed DHTML and JavaScript where the solution to everything, and there are solutions I am proud of from that time, and solutions I wouldnt mention even under torture. These days all client side stuff is focused on availability, usability and other non-relevant bilities ;-). Where is all the cool stuff? jParallax is cool, and from a first point of view, somewhat useless, but hey, keep em coming.

Blueprint CSS 

I hate CSS. No I like separation of content, design and behaviour. But lets be honest, CSS is repetetive and often you find yourself chasing browser bugs hitting CTRL+S, ALT-TAB, CTRL-R, ALT-TAB …. That is why I believe we must minimize the rows of CSS we are actually writing, just as we try to do that with JavaScript using libraries such as jQuery, Prototype or Mootools. Blueprint CSS is interesting, I am thinking of implementing it into my mindset as the default CSS-library together with jQuery for JavaScript and Smarty for templating.

YAML (Yet Another Multicolumn Layout)

This one looks interesting as well, but the only reason I list this is because the name is the same as the configuration language YAML I will talk about below. 

YAML (YAML Ain’t Markup Language)

Before I have used XML for configuration, moving more and more over to JSON, because of the benefits parsing and using it. But YAML is what I have started using for some types of configuration, because of its easiness to read, write and share. Look into it. I love it for configuring navigations.

In this article I will try to dissect how we use CSS in order to design our webs and try to find a model that will make it easier for us to use and create CSS Frameworks that fits all the different problem domains we are facing when designing our websites. The Anatomy of Web Design is essential knowledge in order to create CSS Frameworks that are actually solving the problems we do not want to repeatedly solve over and over again when building websites.

Today no one would even think of writing their own JavaScript library from scratch and use on a site where the audience is diversed, making QA difficult. Libraries such as jQuery and Prototype solves most of the problems that occur on a public website, you only have to write snippets of code for smaller parts that are business specific, if you are writing large chunks of code for your business specific needs you are either solving problems at the wrong level or not thinking in terms of components/plugins. But when it comes to web design and CSS the wheel gets reinvented on each and every site you visit. I bet there are two main reasons for this:

- Design is difficult to quantify and generalize
- Designers do not think as programmers, who always quantify and generalize because they are lazy by nature.

But there are some projects, who have identified the css reinventing the wheel problem, both of them focus on giving designers and developers a generic set of CSS that solves problems that occur, independent from website. The two biggest, and most promising projects are:

• Blueprint CSS
• Yahoo! User Interface Library (YUI)

They have a lot in common, both focus on first adding a reset CSS to the document and then use a grid for creating all types of design grids you could ever dream up. Blueprint has a module for forms, print and typography, while YUI has modules for fonts and a base css that tries to make a cross-browser-stylesheet from the reset document. YUI offers themes for different widgets/components. No project I have found focus on solving the biggest problem: Specific CSS for specific needs.

As you can see, we have a lot of different keywords (in bold) already, and we could start to quantify and generalize how we look at CSS.

Generalize Design

Generalising design is what CSS is all about. CSS is about finding property values that can be altered and combined in order to achieve the desired result in design. We may say that CSS in it self is the first level of abstraction when it comes to design. For a couple of years we have been focused on creating intriguing designs with our bare hands with CSS as our only (mental) tool.

Pretty soon people working with CSS found out that we had to take the abstraction one level higher, separating types of design into different parts of the design, making the stylesheets easier to edit, more modular and easier to redesign. A typical step is to split the applied styles into different parts, such as grid, typography and design. On top of that we possibly added specific styles for specific parts of the website. By making this separation, we made it easier to change and maintain the design of our websites. If we look at the biggest websites today (with a designed frontend) a lot of them uses this separation of design to different degree.

Still we are solving design problems over and over again in these styles. And the next problem is to identify generic components and grids without forcing a specific look and feel onto the user of the framework. YUI and Blueprint takes a couple of steps in this direction. What I would like to see from both YUI and Blueprint is components that are “wireframed” in their look and feel, this in combination with a well defined documentation on how to add look and feel to these components with specific themes/templates would solve a lot of the design problems some people are facing today. After all, when we dissect a page in interface components, we will realize that 75-90% of our look and feel is well defined patterns or components used elsewhere and if we have wireframed solutions for this, we will see better websites with less rendering errors because designers can focus on what they think is fun, designing, and web developers can focus on learning JavaScript, not play Russian CSS-roulette.

I am in the middle of a big redesign, re-gridding of one of the websites I am responsible for the frontend on, and I believe that we have to start using solutions like this for three main reasons:

1. Maintainability. If we use well defined components with a good documentation, it will be easier for people working with maintenance of the website, to create components, pages, flows that we know for sure will fit the graphic profile and will work in all browsers.
2. Quality. By minimizing the number of rows of new code on all levels we will create a better product. By using already tested and verified code, we will of course create the foundation for a better product.
3. Focus. Designers can focus on design, developers on development and people who have written CSS in the past, can start build UI Components in [INSERT_YOUR_PREFERRED_LANGUAGE_HERE] and make sure developers are distanced from the look and feel by creating a good API for creating these design components. But that is another article.