Questions

• Where will we coordinate work?

  • I think on themes.tiki.org
    • I think dev.tiki.org would be more appropriate as it is about development (not a themes how to and tips and tricks stuff)
      #But then we wouldn't be able to enjoy the retro environment of
      as far as I see it, coordination already started on themes.t.o and we should stay here as facts have been made - earlier on I would have opted for dev.t.o aswell

• Bootstrap 2 and later 3, or directly to Bootstrap 3?
  Bootstrap 3.1 is decided in the meantime and will apply licence whise as it will be duallicenced to MIT

  • Licensing issue prevents us use Bootstrap 2
  • There are several non backward-compatible changes
  • I suggest we shoot for compatibility with Bootstrap 3 to avoid doing a lot of work twice.
    • I agree

• What about LTS handling?

  • Option 1: start revamp after Tiki12 LTS
    • Benefit: We can do pre-requisites such as
    • Benefit: So we have less work later, we can start with migration of some aspects like
      • Some of the themes (ex.: we should have a FiveAlive for Bootstrap)
    • Benefit: We can start directly with v3
    • Benefit: Community has several months to get accustomed to Bootstrap
    • Benefit: No change on the schedule
    • Drawback: First LTS with Bootstrap will be Tiki15
    • Drawback: We could have started earlier
  • Option 2: start after 11.0 and try to finish for Tiki12
    • If Tiki12 isn't stable enough for a release on schedule, either
      • Option 2a) Retroactively identify Tiki11 as LTS
      • Option 2b) Identify Tiki13 as LTS
  • Option 3: Experimental option in 12 and rocksolid default in 13?

• Do we try to support

  • => in my mind that depends on how we structure the /templates directory

• Will we still support the core/existing customisation approach that Tiki has - even with a Bootstrap theme (I'm probably showing my ignorance here! - Geoff)
  I see no reason for not keeping the core/existing customisation approach and my first tests with bootstrap show me, that there is no technical problem with it
  ... - Geoff) e.g

  • being able to take a standard theme but apply an 'option' (/styles/theme_name/options)that tweaks/adds different css etc., which includes:
    • option specific images
    • the Newsletter specific css
    • etc.
    • how will quirky browser tweaks be handled eg ie7, ie8 files etc
  • having a set of .tpl's that are theme specific (/templates) - with customised mail templates folder
  • be able to apply theme specific modules

  [My view is that we should use Bootstrap to provide:

  • Uniform styling (classes) for page components such as gadgets, buttons, tabs, and tables, etc. ("content"), and
    — (First we'll need to clean up Tiki's tpl files to uniformize the construction of these things.)
  • Page layout classes for grids, responsive web design, etc. ("framework")
  • Tiki's CSS classes should be a superset of the Bootstrap classes IMO.
    — A quick check of more-interesting "made with Bootstrap" sites shows this is common practice.
    — Sites using only default Bootstrap classes seem to be pretty limited style-wise.
    — We can offer more flexibility to designers and reduce their work by adding classes for styling.
    — We can offer more page layout options by having a few more divs available (to support FiveAlive-style header and footer graphic treatment, etc.). ]

Evolution or revolution?

Do we go for a clean break / "burn all bridges" approach and force major changes on all legacy themes? or do we make an effort to try to make old themes still work?

Arguments for clean break

• End result will be simpler code
• End result will be closer to what people already know (people that use Bootstrap that is)
• Most theme intense sites have more than enough features in the LTS versions and can use that until they decide to refresh their site design.

Arguments for legacy support

• Makes it easier for heavily customized themes to upgrade
  [I'm not sure how important legacy support per se is, but I think it'll be good to have a framework available that enables people to replicate their old designs if they want to go to the trouble. ]

Things to watch out for

Things that Bootstrap doesn't cover

• Logo?
  • Presumably, Tiki's HTML classes will be a superset of the Bootstrap classes, so our current method for specifying the logo can still be used, in combination with the benefit of Bootstrap's layout.
• RTL is not in v2
  • Licensing issue prevents us use Bootstrap 2 anyway (see
• Let's use
• I do not understand how do Schema attributes validate in HTML - luci
• luci, I think the suggestion was to use them for element/class names, etc.

Things that Bootstrap overlaps with existing components

• jQueryUI
• jQuery Mobile

Pre-requisites

This is a list of things that must or should be done before or as part of the Bootstrap integration.

• Migrate more things to Smarty plugins
• New space /themes/ directory (but old way still works)
• Move all temp content to one place
• Layout switcher (from experimental branch)
• Change to use Bootstrap

In general

• This is a lot of work
  • True, but Tiki's templates and CSS really need a major overhaul anyway. If that happens in a way that can take advantage of the Bootstrap bandwagon (as long as we still have design flexibility), so much the better.

CSS file reorganization

• In parallel with the Smarty templates cleanup, CSS selector globalization, and use of

Coming in Bootstrap version 3.0

• No set release date, but probably sometime in 2013
• Many changes in class names

Workflow

PHPStorm has a Less plugin (

• Some references:

Related links