Feature Proposal: Adopt a CSS framework from another project

Motivation

We currently have our own, and with all respect to the designers, fairly crude, CSS framework.

If we adopt another project's work, then we can leverage all the themes designed for that project - not to mention the testing, documentation, and support.

Description and Documentation

The proposal is to adopt the jquery CSS framework, as described in http://jqueryui.com/docs/Theming/API

We have already adopted jquery as a standard, so this is a natural next step.

Ideally it will be possible to merge the current CSS framework with this.

Impact

Impact on plugins?

-- Contributors: CrawfordCurrie - 15 Oct 2010

Discussion

Adoption of jQuery's css framework seems to be a natural next step. Most jquery plugin authors added themability using jquery UI css classes to their work.

However, this is by far a complete css framework from the perspective of a web designer. It only covers standard css classes as they are emitted by jquery widgets.

Having worked with jQuery UI and other themable widgets, I've found the available themes to be extremenly limited and hard to extend. I was very hard to extend coverage of an own theme in a way that all standard widgets of jquery ui look non-jquery-ish. Infact, the used css classes are used in a way that they sometimes conflict with each other, that is: a property in one place was not desired in another place even though both places used the same css class.

So my advice is to be extremely cautious when applying this as a standard: while you change the look & feel of a lot of jquery UI elements quickly with ease, it is rather hard to proceed from that point in any fruitful way.

Besides that, the available jquery themes already show their aged being createrd at a time when apple's aqua look was en vogue. As far as I know there is no kind of marketplace for jquery UI themes with more high quality designs.

Baseline is: besides foswiki's own base styles, we should create a jquery UI theme for foswiki usable by skin authors removing some of the jquery-ishness and providing a good and clean neutral look and feel.

But things obviously won't stop here coming to some kind of css framework.

Instead of just looking at jquery's css "framework", I'd prefer to agree on some of the grid frameworks like blueprint, 960, combined with something like SASS or LESS.

-- MichaelDaum - 15 Oct 2010

While jQuery doesn't come with a css framework, Compass is one. Here's some stuff to read up.

• Mastering Sass: Lesson 1
• Mastering Sass: Lesson 2
• Mastering Sass: Lesson 3: using Compass

-- MichaelDaum - 15 Apr 2011

I've been working with SASS/Compass for a while, on a non-Foswiki project, and it has to be said, it's a revelation. Makes life soooo much easier.

-- CrawfordCurrie - 15 Apr 2011

so long as we avoid the indent based syntax, I'd be very happy - I've been using LESS from before SASS changed over - as I think its important for users to be able to c&p css they find in the wild.

-- SvenDowideit - 16 Apr 2011

Yeah, agreed - we use the CSS based syntax with SASS, and it works really well so far.

-- CrawfordCurrie - 16 Apr 2011

Base skin will be implementing Twitter Bootstrap, that uses LESS.

-- ArthurClemens - 22 Feb 2012

One word of warning; Bootstrap is OK, but is an utter PITA for scrollable areas (or maybe I'm just using it wrong). Also, don't use anything older than v2.

-- CrawfordCurrie - 23 Feb 2012

Changing this to Parked. ArthurClemens has left the project. Hopefully someone will adopt it.

-- Main.GeorgeClark - 19 Nov 2015 - 00:42

State of affairs a couple of years later:

We've got a grid layout framework.

SASS seems to have made the race in favour of LESS.

Bootstrap is still popular but quite a stretch to use by now with a lot of features that you can't pick individually without buying in 100%.

jQuery-UI is mostly stale. Don't expect much to come anymore, i.e. with regards to its css framework. jQuery-UI's theming rules and Bootstrap are mostly at odds with each other.

With regards to icons: we have been using famfamfam for a very long time now and it still is an amazing icon set. However its playfulness not always suites modern web design. Today we mostly see icon or svg icon sets instead of png icon sets such as famfamfam. Most widely used icon sets are fontawesome and google's material design icons. These can be colorized to whatever suites best a web design albeit being monochrome (leaving asside icons in different colors can be stacked). While fontawesome icons (let's take it as a placeholder for all things font icon / svg icon set) are monocrome the buttons they are on are rather colorful (as in flat design). For example, you'd better not use a colorful famfamfam icon on a colorful button.

Coming back to Foswiki, css is mostly divided into several areas:

• skin css (pattern and nat): create the overal web design
• multiple extension css: serve as a base styling for implemented web components
• jQuery-ui css: comes with multiple themes, of which only the foswiki theme is matured enough covering all jquery components that we ship.

Bringing them in line to create a new design is not trivial and colors and styles are spread in a non-shareable way in all places. A good example is a:hover. Its color is defined in the skin css. However extenion css that redefines the colors of certain links will also have to redefine again the colors of a:hover thus creating redundance. Same problem exists for other elements such as input or the like.

That's why SASS will come in handy among other benefits such as modularization of css. It allows to define a color set that all extensions can read and adjust their css accordingly. SASS also comes in handy having a good perl processor. So it seems straight forward to add SASS support to BuildContrib and then rework existing skins in a modular way. There will most probably be changes to the way they are made customizable today, i.e. instead of cascading user styles we'd probably prefer a SASS run on the backend to create a compbined single css that merges user selected styles with modules of the skin css. Reworking PatternSkin that way will also greatly improve the way its css is loaded into the html head which uses @import() today thus harming performance and content security policies.

I have reworked the proposal description along these lines.

-- Main.MichaelDaum - 19 Nov 2015 - 07:23

I agree with everything what Michael said in his last entry. It is 100% true.

However, this changed the original proposal to something absolutely different. So,

• generating css with SASS is the right step forward
• but the adopting an CSS framework is an different thing

We currently have patterskin and natkin. (not counting the few unmaintained skin-extensions). The css for these skins should be generated by SASS as Michael proposed. But also (in addition) Foswiki in the future could adopt an any (or multiple) CSS frameworks (for example by new skin-extensions). Different things:

• generate all CSS for the Foswiki using SASS (regardless of using any CSS framework or not) this is a must - and this should be done as first
• adopting some existing CSS framework, for example bootstrap, foundation, UIkit or any other from the zilion existing ones, (of course using SASS from the previous bullet) - is an complementary (additional) thing.

Also, from my point of view, it is 100% true what Michael said about the icons - (famfamfam vs glyphicons), but again - it has nothing with the original proposal nor with the proposal using SASS. With SASS we could (should) generate the needed CSS

• for the glyphicons
• and also for the famnfamfam (regardless it's oldness - current users uses it)

Therefore recommending clearly separate the different things to differnet proposals:

1. create an brand-new proposal for using SASS - it is invariant to CSS frameworks, fonts etc... simply the proposal is "using SASS for generating CSS" - it is an needed, and right step forward and doesn't interfere with icons and/or css frameworks.
2. change back this proposal to it's original meaning - adopting an CSS framework - and park it until someone pickups it
3. if want, create another proposal for obsoloting famfamfam - but the current users uses famfamfam icons, and font-awesome currently has not equivalent icon for every famfamfam icon - so isn't easy obsolote famfamfam.

-- Main.JozefMojzis - 19 Nov 2015 - 08:55

Okay, reverted old and bogus proposal here and spinned off AdoptSASS

-- Main.MichaelDaum - 19 Nov 2015 - 12:51