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

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

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 ... */
}

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