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.)

Decisions that need to be made:

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. What advantage does lite.css offer over using only the Bootstrap grid? Also, for people with Bootstrap experience, maybe it's good to offer a path that's "pure" Bootstap. But of course lite.css can still be available. That's why I mentioned maybe having options in L&F. I want to make a schematic of CSS "stack" options. )
• Globalize selectors to minimize the use of single-instance rules (design details such as white space and color).
• 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 (http://getbootstrap.com/customize/) and demo (http://bootswatch.com/) bootstrap themes are done)?
• 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).
  (No, the best-practice method is for the dev to compile the Less files into CSS before they and the resulting CSS files are committed to SVN. )
  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 ...)

If Less pre-compiling is used...

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: http://jeffcroft.com/blog/2012/feb/23/many-ways-to-use-css-preprocessors/
• 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: https://github.com/twbs/bootstrap/issues/9913, theme-based solution: https://github.com/morteza/bootstrap-rtl.
• Torsten: => yesterday or so, I remind, that in an IRC chat it was said, that there is a solution?

Icon Fonts

• Should icon fonts such as Glyphicons (http://getbootstrap.com/components/) (or similar, such as Fontawesome (http://fortawesome.github.io/Font-Awesome/), which may work better - need to research/decide) be supported by default?
  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, '<span class="glyphicon glyphicon-star"></span>' or '<i class="icon-li icon-ok"></i>' in the template).
• 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)

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
• Decide on bundled options - classic, responsive, responsive variants a la Drupal panels(https://drupal.org/sandbox/apmsooner/1805170) and a naming convention. Options should include:
  • 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.cswits for wide viewports with @mediaqueries in lite.css and use relative grid width for the columns
      @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 - I'm just brainstorming/thinking out loud 😉 )
    • ?? 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. )

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

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 (http://getbootstrap.com/customize/).
  • 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

Related

• http://confoo.ca/en/2014/session/the-new-css-layout
• http://sixrevisions.com/mobile/methods-mobile-websites/