On a related note, we should use (?)

What is a CSS framework?

Wikipedia says "CSS frameworks are pre-prepared libraries that are meant to allow for easier, more standards-compliant styling of web pages using the Cascading Style Sheets language."

Currently we use *lite CSS "framework" but it does not provide grid layouts. It serves us well and is stable solid CSS base for many years in Tiki so far but it is just that - lightweight basic 3-column layout. So, do we need to extend it or pick some additional ?

CSS frameworks - the advantages (benefits)

  • Currently in Tiki, on the up side:
    • *lite.css along with layout.css, etc has been providing a default layout.
    • There is a kind of badly organized framework with defaults provided for themes to inherit.
    • Theme stylesheets extend the default layout for customized sites.
    • Regarding grid systems, custom themes can introduce a grid layout by declaring div#fixedwidth the container, sizing side columns appropriately and providing div classes for wiki text content.
  • On the other hand:
    • Tiki doesn't have any built-in grid awareness and it would be hard for a custom theme to cover all elements.
    • With no good organization or documentation of element design, there is a lot of redundancy and near-duplication in the CSS (200 colors in layout.css, design.css and the /css files, for example).
    • About out-of-the-box CSS frameworks, here's an argument against using them - - and using Sass CSS preprocesser instead.

Other points:

We need to think about responsive web design, along with CSS frameworks and grid systems. An unresponsive grid isn't good enough these days. Do we build screen-size responsiveness into the CSS, or do we rely on jQuery to provide smaller views?

CSS preprocessors

Here is an introduction to CSS pre-processors.

CSS preprocessors - the advantages (benefits)

Probably we should think about this on two levels:

Tiki core CSS (use by Tiki code contributors for basic layout, feature functionality, default design, etc.)

  • Grid arrangements like Blueprint can be incorporated into some CSS preprocessers (Sass/Compass).
  • Tiki CSS files need to be reorganized anyway, so conversion to Sass or Less would provide motivation and focus thinking.
  • Hopefully, there would be fewer unique rules being added to the stylesheets if there is a logical and documented organization of Tiki CSS rules.

Tiki themes (best practices for additional/custom themes)

  • Theme variants can be produced faster.
  • Theme stylesheets would benefit if the default CSS becomes more modular.

Are there any problems or disadvantages using CSS preprocessors ?

  • Specifically about Tiki, developers who contribute or edit CSS files would need to agree on which preprocessor to use, and get up to speed on using it.
  • Presumably, in the revamped CSS directory, there would be a new directory containing the preprocessor files, which would be edited directly, and the compiled css files, which wouldn't be edited directly. This isn't a disadvantage, but just something to work out.

Just to name few from the article:

  • Code duplication in compiled CSS
  • Extend and mixins can be bad for maintenance
  • Nested code can be harder to read

Please note that they are opinions of a single developer, who thinks that "A stylesheet full of mixins, if/else, loops, variables, functions, etc, will be as hard to maintain as a bloated hand-crafted stylesheet, if not harder".

Another opinion is here:

If yes, which CSS framework to pick ?

About picking a framework, here is a list:

In order of number of active committers:

I can't tag this one as CSS framework but it would be on the list

If yes, which CSS preprocessor to pick?

Somebody said that currently Sass is to Less what jQuery was to Mootools a while back (that is, gaining the edge in mindshare). Here's one opinion: .

Tiki experiments


Gezza suggested Twitter Bootstrap which is LESS based and Apache Licensed (so should be OK in LGPL ?) Version 3 is licensed MIT so all is fine. But it seems there could be problem because Twitter Bootstrap includes Glyphicons which are Creative Commons Attribution 3.0 Unported (CC BY 3.0) and require "you must always add a link to in a prominent place (e.g. the footer of a website), include the CC-BY license and the reference to on every page using Glyphicons." Font Awesome web-font icons was added and also "Glyphicons Halflings are also a part of Bootstrap by Twitter, and are released under the same license as Bootstrap. While you are not required to include attribution on your Bootstrap-based projects, I’d certainly appreciate a visibile link back to in any place you find appropriate (footer, docs, etc)."

So what if we just use LESS to get the CSS pre-processing and jQuery UI Bootstrap compatible "theme" (because we use jQuery UI anyway already) to make it look nice and Twitter Bootstrap themes compatible ? Luci thinks it is not necessary to include all the Twitter Bootstrap stuff anyway. Gary agrees. Maybe Twitter Bootstrap could be done at the theme level.

The big news among the many new features in this release is the mobile administration capabilities and the deep integration and support of Twitter's Bootstrap framework (which enables much of the mobile admin).

jQuery UI Bootstrap author claims "With this theme, not only do you get the ability to use Bootstrap-themed widgets, but you can now also use (most) of Twitter Bootstrap side-by-wide with it without components breaking visually."

(There are also docs on how to use Sass/Compass with jQuery-UI, and there's a Sass Twitter Bootstrap implementation:

If we decide to use CSS preprocessor like LESS we will probably need to use an optional LESS compiler to turn LESS files into CSS and to avoid little delays less.js (which is client side JS compiler) can cause (load performance) - most probably Assetic or the PHP one: (About other compilers read the ?

(Note: CSS preprocessors are dev tools to create and manage CSS files. One workflow would be to work with the Sass or Less files in local dev machines, compile them locally as the CSS files in the Tiki package, and SVN commit both the Sass and compiled CSS files (after agreeing on the compile options for file format consistency regarding comments, compact or expanded, etc.). This way, there is no compiling done by the production server or in the browser.

Are you in favor of using CSS preprocessor ?

Accept Undecided Reject
1 4 0
  • jonnybradley
  • luci
  • gezza
  • chibaguy
  • eromneg

Are you in favor of using even more comprehensive / advanced / complete / complex CSS framework ?

Accept Undecided Reject
2 1 1
  • jonnybradley
  • marclaporte
  • gezza
  • luci

Jonny's 2¢: We already have a hugely complex CSS "framework", so actually why i am voting for this one really is to replace our chaotic and unique CSS system with a more standard and commonly used one.

Are you in favor of simply focusing on the new native "CSS Variables" ?

Or even now in PHP (we could call our files styles/abc.css.php)

Accept Undecided Reject
0 2 0
  • marclaporte
  • jonnybradley


It's easy to compare them on Ohloh:
This comparison is a little bit apples and oranges as Blueprint and 960gs are actually CSS class libraries and Compass is a production framework.

Comparison of Sass and less-css on Ohloh:

Related links

also related:

Front-end frameworks on

Zurb Foundation

Twitter Bootstrap

Bootstrap themes repositories

Bootstrap FOSS themes

Bootstrap generators theme and wireframe

Videos about Bootstrap

Version 3

LESS is included in Bootstrap

HTML Boilerplate



960 Grid System