This page has some preliminary ideas about Transition to Bootstrap - 2013 classes transition targeted for Tiki 13 and onwards to help Tiki themers and designers.

Bootstrap files

Location: vendor/bootstrap/

Now in trunk (to be Tiki 13), all necessary Bootstrap files are part of the Tiki package and loaded by default. However, the Bootstrap Less files aren't included (yet) so you will have to get these separately if you want to use them to make a Tiki theme.

Main elements

Navbar

Could be used as a standard background for buttons.

Buttons

Default Tiki button (query, navigation, cancel action)

class="btn btn-default"

class="btn btn-primary"

class="btn btn-warning"

gezza: What do you think, would it make sense to introduce a functionality focused "tiki class" layer as well for the buttons to make styling felxible and development more consistent? I am thinking something like:
btn-insert
btn-update
btn-delete
btn-revert
btn-cancel
btn-query
btn-navigation
btn-icon

Notes

1.1.1.1. when should an element be a button or a link

Tiki sometimes uses hyperlinks ( a> tag), sometimes input type submit, sometime buttons

How to unify?

1.1.1.2. default classes for a Tiki button

A way could be to agree on a naming convention, assign type or class accordingly in tiki templates, than use the smarty function to add the bootstrap class for styling.
An approach could be for example according to functionality:

• Action buttons that result in a commit to the database -> tiki class/type name: "button-action". Use smarty to add btn-primary class for styling
• Cancel action buttons (eg: Cancel Edit) -> tiki class/type name="cancel-button". Use btn-default bootstrap class for styling
• Query buttons (list something, run a report, etc) -> tiki class/type name="button-query". Use btn-default bootstrap class for styling
• Navigation buttons (eg: jump to another screen/feature) -> tiki class/type name="button-navigation". Use btn-default bootstrap class for styling.

issue #1: Bootstrap offers button style and size options, which one to pick? See http://getbootstrap.com/css/#buttons

• btn-default seems ok for most buttons
• btn-primary requiers additional css sytling to have white color for links on buttons

issue #2: use span tag or add class directly in the element?

1.1.1.3. how to customize

eg: I dont like that on the edit page the save button class is btn-primary, I want it to look like btn-warning, how do I do that without modifying php or tpl source files?

There must be a class .edit or so in the .tpl file by default.
Then you could modify the custom .css - other wise I do not see a point to customise specifically edit buttons without braking other kinds of buttons.
so must be prepared in the .tpl once before, meaning we have to consider this

lib/

function.button.php

<span class="button" ...>

<span class="btn-default button" ...> or <span class="btn-warning button"...>

<a class="btn-default" data-role="button" ...> or <a class="btn-warning" data-role="button"...>

• issue #1: not all buttons are picked up for styling, for example the comment button on tiki-page_bar.tpl (it has span class="button")

• issue #2: in Tiki input types such as submit look like buttons, but they are not picked up by this function (eg: Create tracker button on tiki-list_trackers)

Dropdown

Select one option:

class="form-control"

Select multiple options:

multiple class="form-control"

Page layouts (grids)

These changes will be made in templates/layouts/bs_grid (or some name indicating Bootstrap grid compatibility. At issue is where to add class="row" container divs.

In parallel with this, presumably the idea of moving everything in the center column to modules will happen. This will simplify the template and give a lot of flexibility to page layout as well.

Overall page layout

This includes the top module zone, topbar module zone, side columns, center content (less div#role_main, which should be addressed separately), page bottom module zone (bottom of center column), and footer (bottom module zone).

Page center content (div#role_main)

gezza: The classes on layout-view.tpl are going to be simplified or we keep them? What is the plan for shadowlayers, fullscreen, fixedwith? Clearfix classes?

IMO (), we can have several layouts and the designer or site admin can choose which to use, or can add another. For example:

• Responsive_fivealive: This one enables replication of the current Fivealive style (has extra divs needed for full-width header and footer background graphics, but fixed-width content). Within each - header, middle, and footer - of course the areas are responsive.
• Responsive_middle: Simpler than the Fivealive layout, but has support for current Tiki layout of distinct header, middle and footer.
• Responsive_simple: Essentially one large container that depends on wiki code, etc. for layout as well as content.
• Other responsive variants

These templates/layouts/responsive_fivealive.tpl etc. layouts can be added or removed as we experiment with the possibilities.

In my opinion, there's no particular reason to keep old divs and div classes like the shadow divs in layouts other than Classic. If one goal of being Bootstrap compatible is to attract devs and designers who are familiar with Bootstrap, we should provide templates that are clean and familiar as much as possible, not cluttered. Also, Bootstrap provides for the "full-width" and "fixed-width" properties, so I don't think we need explicit divs/classes distinct from Bootstrap's.

{if isset($objectCategoryIds) and in_array(32, $objectCategoryIds)}<div 
class="cat_wrapper">{/if}

{if isset($objectCategoryIds) and in_array(32, 
$objectCategoryIds)}</div>{/if}

.cat_wrapper .wikitext { /* Keep Layout Shadows feature and Categories 
used in templates enabled for this ! */
     /* object category custom CSS goes here ... */
}

BTW, some probably-useful Bootstrap-compatible HTML templates for various page layout: http://startbootstrap.com/ (Apache license); i.e., how to use Bootstrap divs in wiki pages, etc. for a nice site.

To keep these layouts simple I guess the layout_view.tpl has to be clean of any functionality other than layout arrangement. If there is other functionality, logics inside, than it would become hard to maintain them as one would need to copy functionality changes all over the different layout_view.tpl files. So these need to be moved out to separate tpls?:

• share
• tell a friend
• error report
• full screen?
• social networks
• google analytics
• endbody code?
• js?

At TikiFest Montreal/Ottawa last spring, we discussed (and I think agreed) moving those items to modules, to clean up the template and so they could be positioned flexibly.

Any thoughts on changes affecting Tiki module zones? (Top, Topbar, Pagetop, Left, Right, Pagebottom, Bottom). If someone new comes, this might be confusing having also header, main, middle, footer etc.

I think the current names are pretty descriptive and should be easy for newcomers to understand (maybe with the exception of "Bottom", which could be changed to "Footer"). It might be confusing that "Pagetop" and "Pagebottom" refer to the "middle center" of the content, and not the entire web page, so they could be changed if there are better words.

Proposal #1 (not sure if possible to do, but seems simple to follow)

The current layout_view can be separated into 3 areas:
1) header: everything until the start of the body tag. Designers don't need to work with this and it remains unified in all layouts when code evolves.
2) body_layout: this is where the designers create the layout. It contains only the grid layout with the module zones. See starter sample below. This way basically all the designers have to do is to create their favoured grid layout and place the module zones where they want. The only thing newcomers have to learn is that Tiki has some zones for content and they have to place them all into the grid.
3) footer: everything before the closing of the body tag that is not related to grid layout (JS file calling, endbody code, things from footer.tpl etc). Designers dont have to work with this, it remains unified in all layouts when the code evolves.

1) and 3) remains in one file and this file is considered as a system file. 2) goes into a separate file and gets called from the system file depending on the layout selection in theme administration.

Example: the current layout_view.tpl contains header, start of body, than an inclusion of body_layout.tpl (where the layout is defined by the designer), than footer stuff and close of body. Various body_layout.tpl files are shipped with Tiki. In case of a 2 main folder structure (see http://dev.tiki.org/File+and+directory+structure+revamp) the various body_layout templates shipped by Tiki are stored in system/templates/layouts/. If someone wants to create own, can do it in the local directory of local/themes/mytheme/ (or local/example.com/themes/mytheme in case of multitiki).

sample starter layout

<div class="main container">
		<div class="header row">
			<div class="col-md-12">
				{modulelist zone=top}
			</div>
		<div class="middle row">
			<div class="col-md-12">
				<div class="middle-topbar row">
					<div class="col-md-12">
						{modulelist zone=topbar}
					</div>
				<div class="middle-leftcenterright row">
					<div class="middle-left col-md-2">
						{block name=zone_left}
						{modulelist zone=left}
					</div>
					<div class="middle-center col-md-8">
						<div id="tiki-center" {*id needed for ajax editpage link*}" class="row">
							<div class="middle-center-pagetop col-md-12">
								{modulelist zone=pagetop}
							</div>
								<div id="role_main class="middle-center-content col-md-12">
									{block name=title}{/block}
									{block name=content}{/block}
									{block name=show_content}{/block}
								</div>
							<div id="middle-center-pagebottom col-md-12">
								{modulelist zone=pagebottom}
							</div>
						</div>
					</div>
					<div class="middle-right col-md-2">
						{block name=zone_right}
						{modulelist zone=right}
					</div>
				</div>
			</div>
		</div>
		<div class="footer row">
			<div class="col-md-12">
				{modulelist zone=bottom class="content modules" bidi=y}
			</div>
		</div>
	</div>

# CSS selectors (classes vs. ids)

Discussion

Isn't now pretty much a "best practice" that ids shouldn't be given CSS style properties? Their CSS style properties are too hard to override with class properties without resorting to !important, etc.

Sorry Gary, probably my bad but I don't understand your comment Can you clarify if id should be used or not as selector for elements (eg for divs)? .
Sorry from me, too, for not being clear. I think ids should not be used for CSS style properties.
And I agree aswell, whilst additionally "afaik" bootstrap does relay on classes and not ids anyway.

An id can be used as a selector if it is used only once on the page (ids must be unique per page), and an id could be used for a page element if there is no chance the element will contain other elements for which the styling rule set for the id might have to be overridden. It's notoriously difficult to override an id's style rule, due to the id's strong specificity, without resorted to "!important". Since the page element's HTML could be edited in the future and a new exception to a style rule might be needed, it's just best to avoid potential problems by assigning style rules to a class instead. Ids can be used when, by definition, they won't pose a problem for child element conflicts, like a display:block/display:none rule for a div. We know no child element will need to override that div's visibility. (If it does, then the HTML needs to be corrected.)

Styling of external sources

External sources come with their own styling. How is this neutralized and turned into Tiki styling?
Vendor (external) source codes contain lots of their own formatting. This causes problems when trying to achieve a unified look and feel. For example jquery-ui is nice, but has its own styling. Using Bootstrap, how will a jquery-ui dropdown will look the same as a dropdown anywhere else in Tiki? Or a button?

One way is to simply add the needed classes, stop and override the usage of external CSS. This might work for buttons, tables, hyperlinks, etc, but how about divs? This can be done as well, but it does add bulk to the total CSS used for a page, since the external script's CSS has to be overridden by new rules that are added to make the page elements produced or affected by the external script consistent with the rest of the Tiki page.

BS Themes Transition