all Teams:

Steps for preparing for Bootstrap compatibility in Tiki 13

(Bootstrap 3.1 will be released under an MIT license so will be compatible with Tiki's license.)

Boostrap v.3.0.1 comes soon and it is dual licensed (Apache 2 and MIT) see This is good enough for us and so v3.0.1 can be included in trunk? gezza: I guess it is not good enough, they say " all new contributions to Bootstrap will be dual-licensed as Apache 2 and MIT" ( Exactly: "We've been looking to move to the MIT license for quite some time, and today's release takes us that much closer. Starting with v3.0.1, all new contributions to Bootstrap will be dual-licensed as Apache 2 and MIT. The intent is to move the entire project (including all prior contributions) to the MIT license in a future version (hopefully v3.1.0)." — luci

CSS - file organization revamp

• Replace lite.css (now obsolete IMO) and design.css and feature-specific files in css/ directory with function-specific files mirroring the bootstrap .less partials.
  -> Torsten: NOT obsolete IMHO
  • Well, I meant in the sense that if the Bootstrap grid is used to lay out all the Tiki content, lite.css isn't needed. Not to say it doesn't have any, but what advantage does lite.css offer over using only the Bootstrap grid (just to be sure about this and so I'm being a Devil's advocate, to prevent unneeded duplication)? Also, for people with Bootstrap experience, maybe it's good to offer a path that's "pure" Bootstrap. But of course lite.css can still be available. That's why I mentioned maybe having options in L&F. Anyway, I want to make a schematic of CSS "stack" options.
  • -> Bootstrap does not know our module zones (especially #col2, #col3) at all and that is what lite.css takes care of: defined in layout_view.tpl and specified in lite.css. The thing is, that you need not to touch Bootstrap at all, to use the columns and that this is an easy to use and existing method to provide any content across pages and features, in column when wide screen and vertically stacked when narrow screen.
    • As a grid framework, Bootstrap doesn't need to know about Tiki's specific content such as the module zones or #col1,2, and 3. That's what the layout_view.tpl file is for: just assign bootstrap.css classes to those columns to make them part of the responsive grid. Bootstrap.css doesn't need to be touched.
  • -> I am not holding on the file lite.css itself, but the questions are,
    a) if we keep the method or find a new method to define column module zones
    b) if we keep, where we define it css-wise
    c) if we are already clearly at the point, that we do not touch bootstrap.css and it's various decendants (free themes) in itself, but build Tiki around bootstrap, so we literally can just plug in and out such themes in one single file and maybe very few simple adjustments
    => The workflow for good basic design must be very reliable and very easy!

• Globalize selectors to minimize the use of single-instance rules (design details such as white space and color).
  agree
• Question: What is the best-practices final form of the CSS files?

CSS - use Less CSS pre-compiler?

• It seems best to take advantage of the power of CSS pre-compiling if the workflow can be worked out, but (for comparison):
• e107 just uses compiled bootstrap.css
• Joomla apparently has install code to fetch bootstrap.css but doesn't include it.
• Some new CMSs support Less pre-compiling of stylesheets, but none of the major ones seem to.
• Another question: Should theme CSS files override core files, or should themes be made by editing .less files and replacing core files (for example in the same way that the customized (
• Torsten => afaik the performance goes down, when using uncompiled LESS files, cause they have to be compiled by the server at every pageload (maybe relieved a bit by caching).
  LESS and other pre-compilers are meant to make it easier to develop new themes and to make theme more consistent.
  Providing the option to use LESS compiled files directly might be an additional feature, but in my point of view, IF we want that, this should be some of the last steps (kind of a top up, maybe nice to have or show feature "Tiki can even this ...)
  • No, the best-practice method is for the dev to compile the Less files into CSS before they and the output CSS files are committed to SVN. There's no performance hit at all; the files for distribution are just produced differently. Whether to switch to Less earlier or later kind of depends on how the current CSS is reorganized, IMO.
    • gezza: IMHO precompiling should be used only by devs for now
      • I agree, but would like to know if even devs are ready to use Less.
        • gezza: me not yet 😊

Less and CSS - determine the best workflow.

Proposed:

• Commit .less files and compiled .css files
• Edit only .less files
• Resist the temptation to make quick edits in .css files. Reference:
• Torsten: => Maybe a good point, but do you really want to force our user (equals customers in some respect) to learn LESS when they want or need to customise a few bits and pieces of their Tiki instance?
  • Users won't need to learn Less. Less would be used by the dev team to generate the packaged CSS files; theme authors could use Less if they wanted to, but wouldn't need to. Site admins/Tiki users could still edit CSS as usual, overriding the default Tiki files as they do now. (Example: Bootstrap.css itself is generated with Less, but users override the file rules if they like, with CSS editing.

RTL language support

• We should figure on supporting RTL from the start; discussion:
• Torsten: => yesterday or so, I remind, that in an IRC chat it was said, that there is a solution?
  • Coming in Bootstrap 3.1, right?

Icon Fonts

• Should icon fonts such as Glyphicons ( Or if not by default, maybe it can be a L&F option, or else documentation provided as to what to modify (supporting icon fonts means linking to the files and adding, for example, '
• Torsten: => Since long I wish an option to simply switch icon sets.
  apart from that I strongly opt for Font-Awesome, as Font-Awesome is completely free (have to check licence!!! Afaik possible!)
  Glyphicons are not cross browser compatible (Chrome problems) and not completely free (free and pro version)
  • gezza: imho there should be a UI and a configuration "layer" between the tpls and the actual icons, so in the tpl we should have only a generic sysname as the icon id like "save" and than the actual icon that is used as "save" is determined depending on the configuration. Icon set schemes could be predefined and shipped, for example Tiki could ship a scheme called "Tiki default icons", where "save"=/img/icons/disk.png. You could associate an icon scheme with a theme. Performance can be a question as this would requre additional processing.
    => that is actually an exact description of what I aswell think, we need. Thx gezza for the brief description and you have my +1
    • Flexibility like that sounds great, but I wonder how it can be done. Icon fonts require a class in the HTML, right? But maybe it can be done.

Template (.tpl) files

• Add Bootstrap classes to existing Tiki HTML where they make sense (under way with buttons, etc.).
• Reorganize as part of file tree organization
  Torsten: => Need a Coder/Designer Webinar!
• Confirm that templates/layouts is the place for page layout alternatives
  Torsten: => Confirmed. Here is the start point <-> layout_view.tpl
  templates/layouts/customlayoutname/layout_view.tpl

gezza: I think it should be in 2 files, I wrote some thoughts about it at the bottom of briefly: imho header and footer part of the current layout_view should remain the same in all themes. the body section (where you create the grid) should be moved out to a layout_body.tpl. Every theme gets an own layout_body.tpl.

• gezza, by header and footer, do you mean the lines that load HTML head at the top and the javascript lines at the bottom? I'm not sure what you want to exclude.

  • gezza: yes, I meant those. Maybe there is a better solution, my concern is that layout development should focus only on the grid definition, but if we leave other functionalities that can change as Tiki evolves it can become hard to maintain all the grid layout files. See my example at the end of

• Decide on bundled options - classic, responsive, responsive variants a la Drupal panels(

  • Classic (current pre-bootstrap layout - will be modified/simplified as gadgets-to-modules progresses)
  • Default (Bootstrap-compatible implementation of classic)
    • As a superset of Bootstrap layout, this supports legacy Tiki behavior: module zones and left and right columns, column show-hide, etc.
      Torsten: => module zones and left and right columns have no problems with bootstrap.
      Only some change in lite.css is needed: limit effects of lite.css wits for wide viewports with @mediaqueries in lite.css and use relative grid width for the columns
      + This can also be done with Bootstrap's container elements (that is, making a "fixed-width" content area in a wide viewport - or am I misunderstanding this point?
      @mediaqueries should have the same measurements as in styles/bootstrap/bootstrap.css (where ever this file will be placed finally).
    • Simple alternative (one big page-data area, for the most flexible layout- no default content)
      Why not just deactivate all module zones to achieve that?
      Sure, that may be better, but I'm thinking of cases where maybe you want module zones on some pages but not all, etc.
    • ?? Other layout views, or "panels"

• Globalize Tiki feature elements
  This may be a good opportunity to "globalize" or "unify" the elements of the various Tiki features; that is, to revamp the layout elements of wiki pages, blog and forum posts, cms articles (at least) so their titles, content body and so on are consistent, with consistent CSS selectors and so on. Any needed style variation can be provided via the body class for the feature. This would greatly simplify theming.

• Torsten: => Great idea! +1

Related tasks

• Revamp Smarty blocks and other code to support Bootstrap construction and classes .
  • Tabs
  • Menus
    How does the menu revamp fit into this transition?
    Torsten: => menu needs a complete overhaul - need a Coder/Designer webinar
  • Etc.
• Modules
  • Move remaining tiki-center gadgets, etc. to modules
    • Page bar, wiki action icons
    • Column show/hide icons
    • Etc.
  • It should be easy to add the bootstrap grid class to a module. Maybe instead of the actual class names, something more human-readable should be used, such as "1/6 width". Options also include "row", "container", etc. (what else should be used from bootstrap.css? Anything?
    Torsten: => maybe not needed! Just apply the grid-class to the object (or mostly containing DIV) and Grid is working
    I have to document that later, when I am back from travel
    I'm looking forward to your documentation because I don't know how a grid column (box, etc.) can be set to be, for example, 1/6 of the container width without being assigned the class - are we talking about the same thing?
  • About responsive behaviors of specific modules, what is the best behavior for a site logo? Probably to be replaced by something smaller, or to shrink, or disappear completely and only the site title be used.
    Torsten: => optional responsive images would be more than awesome, but that would be kind of a task 😉
    Images can scale in CSS3 so are already responsive in that sense; Bootstrap also has rules for object display/no-display according to media query - though this doesn't stop the image download, which is a drag, but as Marc indicated, there is server-side control of resources depending on display device, maybe for Tiki 14.
• Tables
  If tables are too wide, they will cause their grid div to overlap the divs to the right. The Bootstrap solution is to put the table in a div with class="table-responsive", to give the table a horizontal scroll bar. Thus the table will stay contained in the grid div and the design will remain responsive (

jQuery, JavaScript

• How to resolve redundancy of existing scripts and new Bootstrap JavaScript?
• Is jQuery mobile still needed? Should it be an optional alternative to Bootstrap (which supports mobile devices by default)?
  + Torsten: => in my personal point of view we do not need a mobile perspective any more (I never got it really running with perspectives)
  + the existing solution seems to me more like a workaround
• Especially in light of Jonny's comments, I think we can conclude that jQuery Mobile will be replaced by Bootstrap. Now, what about jQuery-UI?
  • gezza: I think it is related to the question of how to manage the styling of externals (stuff in the vendor directory). To achieve unified visual experience, we need to do something with the various styling of vendor sources, but we dont want to touch source codes in the vendor directory, so we need a layer either to first purify and than to add (or just simply add) boostrap classes on the fly. This dilemma is known if you google it, you will find many threads on this. A project to address this is

Compare Responsive Solutions:

Touch & Gestures

• Should we pick a

Workflow for theme developers, etc. in and after Tiki 13

• Regarding themes, we need to think about the entry points of designers and implementers. We need to support a range of skill levels and dev time availability regarding themes.
  • Just install a pre-made bootstrap theme and have it work.
    • In this case, we probably need to provide the grid and responsive class rules, as the pre-made bootstrap themes don't necessarily cover these. But pre-made themes are often stand-alone, not needing the default bootstrap.css. This needs to be researched further.
    • Maybe there should be some switches in L&F, to indicate whether the full bootstrap.css is needed (maybe the custom theme replaces it).
    • These methods are for working in CSS, not Less files.
• Make a new theme compatible with bootstrap.
  • One approach: working in CSS only.
  • If appropriate/necessary, we could provide instructions on how to best use the getbootstrap.com theme customizer (
  • Another approach: working with Less.
• Make or upgrade a legacy Tiki theme.
  • Document the mapping of Bootstrap.css to Tiki legacy CSS selectors.

Mail to dev-list 22 Oct. 2013

has to be merged into the page structure, when I am back from travelling.
Cheers
Torsten