See also: Bootstrap Transition Preps
On a related note, we should use schema.org (?)
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 ?
- 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 - http://chriseppstein.github.com/blog/2009/02/15/a-sassy-response-to-css-framework-disadvantages/ - and using Sass CSS preprocesser instead.
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?
Here is an introduction to CSS pre-processors.
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.
- Theme variants can be produced faster.
- Theme stylesheets would benefit if the default CSS becomes more modular.
- 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: http://www.amberweinberg.com/januarys-12412-researching-less-sass/
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
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: http://css-tricks.com/sass-vs-less/ .
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 glyphicons.com in a prominent place (e.g. the footer of a website), include the CC-BY license and the reference to glyphicons.com 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 glyphicons.com 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: http://thesassway.com/projects/sass-twitter-bootstrap.)
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: http://leafo.net/lessphp (About other compilers read the http://fadeyev.net/2012/02/16/less-update/) ?
(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.
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.
Or even now in PHP (we could call our files styles/abc.css.php)
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:
- http://lessframework.com/ CSS for Print
LESS is included in Bootstrap