Montag,
23. März 2009

Layout frameworks are gaining in popularity and are on their way to becoming standard tools for web development. However, the term "frameworks" is primarily associated with software development and as neither HTML nor CSS can be classified as programming languages, there has been some confusion and discussion over the appropriateness of the term in this area. The concept of CSS frameworks encounters similar acceptance problems, as even though they are not "programming", many web developers – particularly professionals – continue to hold fast to the idea that no matter how demanding everyday life is, markup and CSS rules must be written completely by hand in order to ensure clean and simple code. This prejudice stems in part from the experiences that nearly every developer has had with the very first code generators like FrontPage, GoLive, or Dreamweaver, and those very negative experiences will not be soon forgotten.

Hinweis: Dieser Essay ist alternativ auch in Deutsch verfügbar.

Table of Content

Web Developers' General Viewpoint

HTML and CSS are interpreted on the client side. Code should therefore be kept as streamlined as possible for any individual project. CSS frameworks, however, are project-independent modular systems, built with the goal of presenting the most universal solutions for the greatest variety of layouts. How do these seemingly incompatible approaches fit together?

A fair comparison of the more than twenty online projects calling themselves “CSS frameworks” is extremely difficult: their quality and documentation as well as their intended uses and even the basic concepts behind the layout concepts simply vary too much. Even worse, there is no clear and generally accepted definition of what really qualifies as a “CSS framework”. Almost encouragingly, so many people want to know what makes a framework that many people have published perfunctory and superficial surveys. The typical argumentation when discussing the pros and cons of CSS frameworks generally looks like this:

Advantages of CSS Frameworks

  • You increase your productivity and avoid common mistakes.
  • You normalize your code/class base.
  • You have a better workflow within a team.
  • You gain an optimal browser-compatibility.
  • You have a clean, well-structured and complete code.

Disadvantages of CSS Frameworks

  • You need time to fully understand the framework.
  • You need a close familiarity with your code’s architecture.
  • You might inherit someone’s bugs or mistakes.
  • You develop sites upon a framework, not upon the solid knowledge of CSS
  • You get a bloated source code.
  • CSS can not be framed semantically.
  • Ignoring the uniqueness of your project.
CSS Frameworks + CSS Reset: Design From Scratch, Smashing Magazine

As the developer of the (X)HTML/CSS Framework YAML, I constantly use these arguments / stereotypes to keep the further development of my project on course. In this essay, I would like to clarify my position on the most common criticisms of frameworks, using my definition of a CSS framework (german article) as the standard.

CSS frameworks are powerful development environments for website creation and are generally oriented towards professional web developers. They provide universal layout building blocks and define a set of rules and parameters within which the developer can move freely.

Important here is the affirmation that CSS frameworks are tools for professionals. A project like YAML might – at first glance – look like a complete set of building blocks with finished layouts and samples, but all the templates and examples are merely demonstrations of how flexibly this environment can be used in professional web development practice.

In this discussion, I will repeatedly refer to Jens Meiert's articles, as he is one of the best-known German web developers and an energetic advocate of streamlined and standard-conforming code. I do not intend to personally attack Jens. On the contrary: I greatly appreciate his articles, as he is one of the few critics who does not merely complain, but can back up his arguments. His articles are thus a good basis for a thorough technical discussion.

"CSS frameworks are never the best solution ..."

The following will examine the truth of the purported disadvantages listed above. For various reasons, the fact is: CSS frameworks are not for everyone. Jens Meiert tries to name several reasons for this:

"Public, or open, HTML/CSS “frameworks” are never the best solution, and oftentimes not even a good solution for any site. [...] So why stating that frameworks aren’t a good solution? Because people outside your company or outside your apartment just cannot know your needs, and this implicit ignorance results in way too much markup in your documents and way too many rules in your style sheets, making any framework-based solution inferior to something tailored."

A few words on HTML/CSS-Frameworks, Jens Meiert

This seems reasonable enough at first glance. A framework can be based upon web standards and best practices, but can never duplicate the particular methods of an individual developer or an agency with 100% accuracy. This is why working with a CSS framework requires a certain learning phase for the code and its working principles. This demands that individual developers adjust their work methods to the conceptual basis of that CSS framework.

Jens Meiert concludes, however, purely on the basis of the foreign code, that CSS frameworks always and necessarily bring an overhead of markup and too many CSS rules. This results from the assumption that frameworks would neither allow individual working procedures nor permit any possibilities of optimizing the final code. This assumption is the actual basis of his criticism. The mistake in his logic is, however, to assume that either individual working procedures or the concrete demands of any project determine the basis of professional web development – rather than working according to current web standards. This set of rules is not only the basis of all professional web development, it is also the basis of widely varied and highly individual working habits. YAML, currently the most complete and fully developed CSS framework, is also based on these web standards: this results in a foundation of transparent source code, a clear separation of content and layout, and semantically appropriate markup within the HTML page structure.

Let us examine current web development practice: in spite of all the variations in the millions of websites, their structure is basically similar. There is usually a header, a navigation, a clearly defined content area, perhaps a sidebar and finally a footer: these sections are often named directly in the source code, and have by now nearly become an informal convention. There may be several columns and perhaps teasers or small variations of the layout. Yet: websites are less different from each other than houses are, which – as unique as they may be – still all consist of a foundation, a living area, and a roof.

Frameworks, Code Snippets and Web Design Practice

Many fear that the use of a CSS framework with a set structure and predetermined class and ID names will unnecessarily hinder the designer's particular freedom. We note that the restrictions of the immutable HTML structure of the CSS Zen Garden have not kept designers from producing countless unique designs for the site.

The practice of the individual hand-coding of a website does not necessarily mean that developers invent their structure from a blank slate. A developer is precisely not an artist, kissed by the Muse to give the Web a new masterpiece of her creative fantasy. Web development is a trade and every developer uses trusted tools (code snippets) for every new site – even those who code by hand. And even if a developer swears that she uses no prefab copy & pasted lines of HTML or CSS, it is her expert knowledge that leads her to type her code according to the principles of a particular system. Web professionals have uncountable tried-and-true code snippets in their heads, just like architects remember countless possible variations on a house. And CSS frameworks are basically nothing more than a collection of tested, practice-oriented code snippets which work together and are subordinated to one general concept.

Often cited along with the arguments of too much markup and too many CSS rules is the allegedly poor quality of the code itself. Here, however, it is important to discuss the fundamentally different goals of various framework concepts. Most web developers understand the term "CSS framework" to refer not only to YAML, but also to YUI Grids, Blueprint CSS, 960 Grid System and various derivatives of latter two. It is easy to lose sight of the fact that unlike YAML, the sleek YUI-Grids do not contain the complete IE patches, the building blocks for forms, or comprehensive documentation. Blueprint CSS and 960.gs implement the design of a classic column grid as their conceptual foundation for the entire framework, and are thus much closer to the purely visually oriented table layout than to the implementation of web standards. As a framework in practice, YUI-Grids can be a bit tricky when designing complex elements, while the visually oriented frameworks with their precisely defined columnar layout cannot clearly separate content and design, which is certainly justified grounds for criticism.

About Practical Solutions and the Minimizing of Source Code

Professional CSS frameworks cannot fullfill the dream of always providing the absolute minimum code. Naturally, such an extreme can always only be reached for exactly one specific case and requires integration of the pages' final content. The goal of a good CSS framework can thus only be to develop building blocks with a relative minimum of markup and CSS rules and the greatest possible potential for reusability, and to use those to create a robust and efficiently usable layout system independent of content.

The difference between the absolute code minimum of a perfect individual creation and the relative minimum of the framework code is inherently variable, dependent upon various influences:

  1. The more the layout planning can take the functional principles of the framework being used into account, the smaller the resulting overhead and the faster and simpler the implementation.
  2. HTML and CSS almost always offer various ways to solve a problem, and hand coding is not guaranteed to find the ideal solution and implement it faultlessly. Expert knowledge comes into play here.
  3. The absolute minimum is a theoretical value. In reality, CSS bugs and the varying CSS implementations of the different browser generations require constant compromises in markup and in the formulation of CSS rules.
  4. CSS frameworks are tools for layout development. Only in the hands of an experienced developer does the final layout appear, precisely because optimization is determined by the requirements of the particular project. A certain overhead on the part of the framework is thus required to allow this flexibility.

CSS frameworks do not provide that perfect made-to-measure suit, but a compromise – and with good reason. YAML does not claim to deliver the best possible (in the sense: a made-to-measure suit = absolute minimum code) out of the box. Instead, I aim to provide the best possible code basis (in terms of efficiency and flexibility) for the developer. YAML's basic markup, the flexible grid building blocks (Subtemplates) and the three CSS Core Stylesheets (base.css, iehacks.css and print_base.css) are robust, reusable construction units, which have all gone through an optimization process in the course of developing the framework, and especially in the area of flexible layouts, this code basis is extremely streamlined in spite of its flexibility.

The objection of too much markup and rules is of course not answered by merely offering an empty folder for content along with a reset-css and a couple lines of basic CSS as a basis for coding – that cannot really be called a "framework". It is certainly streamlined, but will not save any more than a couple minutes in development time.

Frameworks Serve Web Development, not Philosophy

Another look at the practice: the desired minimum of code is also in hand-coded form only reachable in the extremely rare case of a customer who gives a developer free rein from the initial conception up to the launch – without any change requests in the middle. The reality of front end development is rather different. New changes are often demanded after clearance and even after the launch, which at that stage often mean additional markup. The minimum can only be determined at the end of the life of the project, and only as a best case scenario.

Jens Meiert is not the only one who misses the point of a CSS framework, as he compares a theoretically highly-optimized custom solution to the out of the box result of a CSS framework – in order to argue against the necessary overhead of the CSS frameworks. This argument first neglects the fact that only those professionals with the necessary expertise can and should optimize the basic project setup of any framework. Second, the advantages of working with a CSS framework are not in the area of final code optimization, but in all the previous stages of development, in which things change due to more factors than just through discussions with the customer. The growing complexity of large and challenging projects with several teams and diverse groups of decisionmakers does not allow for immediate optimization and finalization of code. YAML's concept offers a practice-oriented solution: robust in all the major browsers, designed for complex demands of web development, and ready for the vagaries of dealing with customers. That six of the recent Biene Awards for particularly accessible websites were awarded to YAML-based sites demonstrates what this framework can do in professional practice.

Futureproof and Maintainable CSS

Even in the area of CSS itself, there are many varied opinions on the utility of splitting up stylesheets according to modules, using hacks to tame Internet Explorer, and the use of conditional comments. YAML uses all these techniques with good reason.

Conditional Comments & Hacks

I quote Jens Meiert on conditional comments, as he is absolutely uncompromising on the use of Conditional Comments and a Reset-CSS.

"The core problem with Conditional Comments is its impact on maintainability. By their very definition you have to link at least one additional style sheet from your HTML, unless, even worse, CSS rules are added within the document. And just as we avoid using font elements as they are presentational and usually mean HTML changes once we want to change the layout (which means a maintenance problem), we should avoid Conditional Comments as once we want to change (or even keep) the layout when a new version of Internet Explorer ships or an old version goes, we face a good likelihood to change the HTML, which translates to an unnecessary maintenance issue as well. [...]

There are implications for collaboration as well, and you can observe these problems in practice: Since CC style sheets don’t necessarily use different selectors than the “regular” style sheets, developers either have to look for the same selector in at least two style sheets, which slows them down (even or especially in comparison to “hacks” which are usually close to all other rules), or they overlook them, implement another solution, eventually run into “weird” layout problems (because the CC style sheet overrides something or says something different), and maybe even add code that is unnecessary."

To Be Clear (on Conditional Comments and Resets), Jens Meiert

Conditional Comments are indeed a special case, as they are a proprietary development from Microsoft and accordingly they don't quite behave like regular HTML comments do. Yet this does not necessarily cause problems. The same is the case for Internet Explorer's no-less idiosyncratic understanding of CSS properties, some of which are simply wrong (CSS bugs), and others are just not interpreted. Of course CSS bugs are not only evident in Internet Explorer, but Microsoft has led the browser market for many years. By now, we can solve all of Internet Explorer's presentational problems more or less easily, by avoiding particular markup / CSS constellations or by using CSS hacks.

A Question of Practice: Where to Put the Hacks?

For the hacks, there are two methods: either – as Jens Meiert recommends – do without the use of CCs and keep all bugfixes in the regular stylesheets. For the maintainer's search for particular CSS rules described above, this method may be advantageous. However, this does not avoid feeding useless CSS ballast to all the modern browsers (Firefox, Safari, etc.) which do not need it, yet thus load the pages more slowly. In addition, many bugfixes use parser hacks to address particular IE versions. But precisely these sometimes hard-to-read constructs will generally not validate, and they are not always ignored by other browsers – which certainly does not make this method less problematic regarding "weird layout problems".

Or, one can separate standard CSS and the IE adjustments completely, put all the CSS hacks into their own special stylesheet, and link it in the layout with a conditional comment. The advantages of this method are convincing and more than compensate for the possible disadvantage of slightly higher maintenance effort.

The Advantages of Conditional Comments

  1. The standard CSS remains free of cryptic parser hacks for correcting IE bugs.
  2. The bugfixes for Internet Explorer cannot accidentally disrupt the presentation in modern browsers.
  3. The number of CSS adjustments for Internet Explorer is usually manageable. Such a stylesheet can generally be kept quite short.
  4. The website gains on performance in modern browsers as they need not even parse through the bugfixes for Internet Explorer.

That was the general claim for the sensible use of conditional comments. Within YAML itself, it was possible to formulate bugfixes for most of the IE CSS bugs universally enough so that they engage without any work from the developer: they can be used preventively, thanks to the framework's set markup structure. This concept, which is currently exclusively used in YAML, leads on one hand to some slight CSS overhead, and yet on the other hand also provides many advantages.

Conditional Comments in YAML

  1. Developers can concentrate on layout development for the standard-conform browsers, as YAML takes care of most of the adjustments for IE 5.x - 7.0 automatically. The amount of time spent correcting the general layout as well as forms etc. sinks dramatically.

  2. Customers need not accept incompatibility with certain browsers, as the CSS framework inherently includes support for older IE-versions.
  3. End users are freer in their choice of browser as the CSS framework supports more of them.

And finally, should Internet Explorer 8 completely conform to the standards and drive the older versions from the market, the only update necessary for a site to deactivate support for the old browsers is to delete the stylesheet from the server and remove the special comments from the layout. Can those who oppose conditional comments merely because they are proprietary or because the arbitrarily defined “maintenance problem” is too great really present an effective alternative to YAML's bugfixing concept, one which provides at least the same advantages for developers, customers, and end users?

Modular Stylesheets vs. Performance

CSS frameworks are development tools with a modular structure. They contain a variety of reusable building blocks (resetting CSS, screen layout, navigational elements, print version, etc.), which are integrated into the CSS layout and adjusted, depending on the requirements of any particular project. The principle of reusability is critical to the speed of the design process. Simultaneously, the use of tested components keeps maintenance and testing to a necessary minimum. Contrary to the development process, running a live site requires more speed than anything else. As every CSS file must be individually requested from the server and every request results in lag time and slows the loading of the page, it is a standard recommendation that a live site combine its stylesheets into as few as possible. A similar process is used for graphics (see CSS-Sprites). Still, these are two entirely independent phases of a project, which should not be arbitrarily mixed together in our discussion.

The CSS of a website is only interpreted by the user's client, and must first be downloaded from the server. Performance on a live site thus requires the smallest possible files for fast loading times. Tools like the YUI Compressor or minify can efficiently compress stylesheets. CSS comments and unnecessary whitespace (space characters, tabs, line breaks) are removed to shrink the file. However, compressed files are not suitable for development: they are not so easily readable by humans. Anyone coding layout by hand will always ensure that the CSS rules are legible and well-organized and will comment on particular passages to increase maintainability and to document design decisions for other members of the team. A division of stylesheets into logical parts thus lends itself to the care and maintenance of complex projects.

Developing with a CSS framework is not much different. The framework provides a new code basis which must be understood before one can trust it and work efficiently with it. To assist new developers, YAML's CSS building blocks are thoroughly documented using CSSDOC and the stylesheets are divided into consistent modules according to their function. CSS comments, meaningful names for layout elements, files, and folders is a basic requirement of professional web development and cannot be considered to be exclusive to either hand coding or to CSS frameworks. In either case, the development process has different requirements than does the live environment. A modular structure of stylesheets while in development is not an argument against CSS frameworks. The decision to optimize stylesheet performance for the live environment is entirely independent of any hand coding or framework use, and is always a sign of professional work.

Do Frameworks Create Non-Semantic Code?

A rather exasperating topic: CSS frameworks purportedly provide non-semantic code or even use non-semantic class names.

"A CSS framework passively removes a great majority of semantic value from the markup of a document and, in my opinion, should be avoided."

Please Do Not Use CSS Frameworks, Jonathan Christopher

This is nonsense. CSS layouts are typically based on DIV elements, which are intended to have no semantic meaning: they are merely structural elements which allow us to divide content neatly into useful sections (header, navigation, content, footer, etc.) and to display it independently of that content. Of course there are certainly various approaches to the extensive or restrained use of DIV elements, but that is really a separate issue and has nothing to do with semantics, and is really a matter of personal taste and of keeping your code as short as possible.

Now to address those evil non-semantic IDs and class names in many CSS frameworks: they are completely irrelevant. Class and ID names add no semantic information to a website, nor does the actual content itself become less semantic when the source code is enriched by CSS frameworks class names. Class and ID names are intended purely to match CSS selectors to HTML elements: nothing more. Or let us ask: what changes in the semantics of a German technical article if the class names of the layout elements surrounding the content are in English? Or in Spanish? Class names must be carefully chosen purely for the easy maintenance and readability of the source code, and indeed, we must give the known CSS frameworks credit for a sophisticated and consistent naming system.

Developers' misunderstandings stem more often from the fact that the system cannot be to everyone's individual taste. Purely grid-based frameworks (Blueprint CSS or 960 Grid System) are strongly visually oriented. This results in a markup structure that strongly resembles the old table layouts and names the CSS classes accordingly, which are oriented to the grid matrix. Jens Grochtdreis's (german article) and Adam Bard's criticism is fully justified, as they point out how little this layout technique can separate form from content and how difficult changes are. However, this valid point relates specifically to the technique employed by Blueprint CSS and its many clones and modifications. YAML, on the other hand, allows a great variety of designs implemented in pure CSS, without any changes in the basic markup. YAML's layout concept is particularly efficient in combination with Content Management Systems, as templating is generally relatively complicated. The limitless design possibilities of such templates using CSS increase their potential reusability.

Only for Beginners / No Learning Effect?

Finally, two further typical arguments against CSS frameworks: they are allegedly useful only to beginners, as real professionals need no such help. It is certainly a good deal easier to learn how to use a framework than to build up expert knowledge of CSS.

“A big problem with frameworks is when up and coming developers attach themselves to a framework as opposed to the underlying code itself. The knowledge gained in this case surrounds a specific framework, which severely limits the developer.”

Please Do Not Use CSS Frameworks, Jonathan Christopher

But how far does a beginner really get without learning? No framework in the world can save users from the responsibility of positioning individual layout elements correctly and labeling their content semantically correctly. Anyone who requires quality will require expertise. Learning cannot be avoided. Beginners are only spared the frustration that any web developer faces when confronted with the not-so-standardized browser reality.

Professional developers will not gain a lasting learning effect by using HTML and CSS daily – they should already know how it works. As mentioned in the introduction, using a CSS framework does require a certain willingness to learn in order to work efficiently with it. And the timesavings are of course much greater in professional webdesign, as the development time is shortened for each additional project that uses the system. This time can then be used for investigating new developments like HTML 5, WCAG 2.0 or WAI-ARIA.

In contrast, it is certainly understandable that hobby designers prefer to focus on the fun and choose to code everything by hand, as efficiency in a hobby is generally neither required nor desired.

Summary

It's quite noticeable that damning criticisms of CSS frameworks or of YAML come from professionals who have clearly never worked with YAML. One can only speculate on the reasons: if, even more important than a basically healthy distrust, a general fear of losing control to an instant third-party solution plays a larger role. I have to wonder if the critics are simply afraid to be at the mercy of a foreign concept and constricted in their creative freedom, which is certainly not the case for those with enough expertise. Jeff Croft noticed that quite a while ago. It's true, you have to trust and work with YAML's concept, and you have to take time to understand the structure of the framework. But that is true of any CMS too, as they all have their own rules and are certainly only manageable after a much longer time spent learning than a CSS framework requires. The argument “I just don't want to” can certainly be an honest and legitimate objection – I can live with that. Such a very personal decision in favor of a particular way of doing things, however, does not mean that CSS frameworks are obsolete or cannot compete with one's own code quality.

It is undeniable that the current number of projects and their starkly varied complement of functions, as well as their various approaches to layouts make a thorough comparison of their qualities almost impossible. Even more aggravating, many online projects gladly assume the buzzword “framework” as part of their name in an attempt to gain in popularity, yet their quality leaves much to be desired for the professional designer. This certainly makes sweeping criticism simple, if not justified. A few copycats will certainly not detract from the many advantages that working with CSS frameworks offers in the long term. YAML and YUI Grids both give us an idea today of what the future holds for web development.

Informationen

This essay was developed in close cooperation by Dirk Jesse and Nils Pooker. The as always excellent English translation provided Genevieve Cory.


Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Dieser Eintrag kann nicht mehr kommentiert werden.