Category: Theme: Look & feel, Styles, CSS, Theme Control Center

{syntax type="tiki" editor="plain"}
The FiveAlive-Lite Raspberry theme’s intended burgundy header background (#A30D3A) is being overridden by a dark gray (#212529)

Probable regression from:
-https://gitlab.com/tikiwiki/tiki/-/merge_requests/9092
-https://gitlab.com/tikiwiki/tiki/-/merge_requests/9117

After looking through the CSS for TikiWiki, one quickly find several redundancies and inconsistencies (modules are not consistently using CSS in the same way, just take a look at the login box with different renderings to see what I mean). On top of that, some CSS classes requested by the code are actually not existing in some CSS... (separatorline etc in some menus)

SO, should we not rethink the styles system?

What I am thinking of is less of a local (modul-driven) approach but rather a context/mode-driven approach.

For example, we could structure the class names so they properly represent the place of usage: header,main, left, middle, right, bottom as pre-fixes, and the usage as the tag, and a qualifier as the postfix.

Example:
A Menu item would be [location]_menuitem_[qualifier]
A Menu item on the left side would be left_menuitem_[qualifier].
A Menu Option on the left side would be left_menuitem_option

SMARTY knows precisely where it is rendering. So we could generate a standard variable in smarty called $CSS_LOCATION, which smarty maintains. All css requests are parsed through a smarty function that assembles the propper prefix.

The [qualifier] is there to make writing CSS a little easier. We can simply create a DIV as an envelope around a structure, assigning the class [location]_[usage] to that. All elements inside would then automatically inherit those characteristics, and the CSS part would only have to deal with the diviation. Those should be clustered together in the CSS to give a clear view on what happens in this particular usage...

I know that this is most probably a &%$&-load of nitty-gritty work, but once done, we should be able to then write a little app that makes developing CSS much easier (maybe even inside TikiWiki) Biggest problem: how to we manage the transition to the new approach, how to maintain backwards compatibility, and how to get alignment on the structure itself...

COMMENTS are very welcome.

J

When displaying a page in default2, the icon band on top of the page (the one containing the print icon, amongst others) is slightly pushed to the right, which cuts off icons or dropdown lists (for backlinks, for example). see attached jpg.

The behaviour does not show in FireFox.

We are using TikiWiki for a lot of people with IE, and are getting complaints... Can you help?

After saving the "Edit CSS" changes, the *.css file is empty!!

See http://screencast.com/t/XEJzwKo97k

I am using the 7.x head build. I know the tradeoffs versus using a stable build. I can't go back, though.

#The new, improved search box is partially hidden by the right-hand column of modules.
#The user login name is invisible.

My current site theme is jqui. I have tried other themes, but each one seems to have a different problem.

While these are not breaking problems, they affect the usability of my site, and I am willing to pay a consultant to help me fix them.

Bottom banner bar appears on calendar although not checked at the general layout options level.

Plus calendar is not part of sections proposed in admin layout per section.

The discussion started here: https://gitlab.com/tikiwiki/tiki/-/commit/479393d23dfce6d9a39d1bb6fb90bde5b8fcc641#note_1261499177

Now, what will become our SOP?
https://duckduckgo.com/?va=t&t=he&q=Should+I+Use+Source+Maps+in+Production&ia=web

Please keep in mind that the vast majority of the contributor community runs Tiki from Git, while the vast majority of the non contributors run from packaged version (ex.: zip)

Firefox 35.01
tikiwiki 13.1, fresh upgrade from 6.1, default theme, fixed width

my layout looks like this in the admin area, and it used to look like this always (expected behavior)
| div #col2 div#col1 div #col3 |

outside the admin area:
| div#col1
|
div #col2 div #col3

so both col2 and col3 come only after the content of col1,
and col2 is half way out of the screen

the layout primarily uses bootstrap.min.css
----- the dom-inspector says that these are the applied rules for col2 --->>>
element {
}
#col2, #leftcolumn, #col3, #rightcolumn, .cssmenubox, .box-menustructure, .box-data ul.cssmenu_vert, .box-data ul.cssmenu_vert li ul {
overflow: visible !important;
}
.col-md-pull-8 {
right: 66.6667%;
}
.col-md-2 {
width: 16.6667%;
}
.col-md-1, .col-md-2, .col-md-3, .col-md-4, .col-md-5, .col-md-6, .col-md-7, .col-md-8, .col-md-9, .col-md-10, .col-md-11, .col-md-12 {
float: left;
}
.col-xs-1, .col-sm-1, .col-md-1, .col-lg-1, .col-xs-2, .col-sm-2, .col-md-2, .col-lg-2, .col-xs-3, .col-sm-3, .col-md-3, .col-lg-3, .col-xs-4, .col-sm-4, .col-md-4, .col-lg-4, .col-xs-5, .col-sm-5, .col-md-5, .col-lg-5, .col-xs-6, .col-sm-6, .col-md-6, .col-lg-6, .col-xs-7, .col-sm-7, .col-md-7, .col-lg-7, .col-xs-8, .col-sm-8, .col-md-8, .col-lg-8, .col-xs-9, .col-sm-9, .col-md-9, .col-lg-9, .col-xs-10, .col-sm-10, .col-md-10, .col-lg-10, .col-xs-11, .col-sm-11, .col-md-11, .col-lg-11, .col-xs-12, .col-sm-12, .col-md-12, .col-lg-12 {
position: relative;
min-height: 1px;
padding-left: 15px;
padding-right: 15px;
}
* {
box-sizing: border-box;
}
body {
font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
font-size: 14px;
line-height: 1.42857;
color: #333;
}
html {
font-size: 62.5%;
}
html {
font-family: sans-serif;
}
<<<----- the dom-inspector says that these are the applied rules for col2 ---

This seems to be a regression since Tiki12 LTS at least. (non-bootstrap, I mean)

since last visit module using bootstrap tabs: add different bg color to active vs non active tabs
You can see it reproduced here in dev.t.o in 14.x also, in the corresponding "Since your last visit..." module. All tabs have same whote background, and this makes it less usable to easily distinguish where tab you are at.

since last visit module using bootstrap tabs: make icons bigger (for human fingers in smartphones)

Have tried using it on a smartphone? It's way difficult to tap on them.

You can try in 14.x in dev.t.o.

since_last_visit_new module clips the text for comments. See screenshot.

a) I spent weeks testing these features one by one.

It will save time if all these features are enabled and complete with samples.

This is the approach used by Joomla and Mambo.

It also helps us learn faster.


b) The assist module is useful but asking users to read a tedious configuration as the first step will eat up too much time.

Site configuration or Look at Feel should be the first one.

It is also the most dangerous but essential.

c) Provide a clue, in the assist if possilbe, to replace a damaged header.tpl with a skeleton header.tpl

[https://sourceforge.net/p/tikiwiki/code/34340/|This change] was made because IE7 & IE8 has trouble with a page which starts with "<!-- TPL:". However, for a new developer, it's useful to know about tiki.tpl and error.tpl

Suggested layout:

{CODE()}<!DOCTYPE html> <!-- TPL: tiki.tpl is used as the global page container -->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<!-- TPL: header.tpl --><meta http-equiv="Content-Type" content="text/html; charset=utf-8" />{CODE}


{CODE()}<!DOCTYPE html> <!-- TPL: error.tpl is used as the global page container -->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<!-- TPL: header.tpl --><meta http-equiv="Content-Type" content="text/html; charset=utf-8" />{CODE}

Some of the preinstalled themes seem to be incomplete:
I have the word "loading..." in the top left corner of each page.

Check: http://list.vic-fontaine.com/
(test user/pw if needed: smarty)

I found this forum topic:
http://tikiwiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=32558&highlight=loading

However, in this case, preinstalled themes are affected.
For example:
bluegreen.css: error
boreal.css: works fine
brtiki.css: error
codex.css: works fine
etc...

while using the paper template, spreadsheet UI style is broken, as it "moves" around when you try to click a button.


After hours of trying to debug this, I found that it was not specifically related to paper. The UI buttons jump around on many themes.

In the end I narrowed the issue down to a style in tiki_base.css

by removing the padding rule under a.toolbar:hover, the UI no longer jumps around.

a.toolbar,
a.toolbar:hover {
--padding: 4px 2px;--
display: inline-block;
border: none;
background: transparent;
}

Ths Strasa theme does not seem to work properly.

The content is against the LHS of the sceen rather than in the middle and the menu is off the bottom of the pages.

We have just done the upgrade from 10.0 to 11.0

We have adopted the tikinewt theme instead but would rather go back to the Strasa if we could.

default.css fails to render correctly because of some wrong syntax.
- "* Links to extend/collapse menus */" is missing the comment start "/*".
- "llistfileslink:active" has its '.' in the line above instead of infront of it.

See the patch below:

The text in nearly all themes - even Readable - is not pure black (RGB # 00 00 00). This lowers readability. While this may not have a hard effect on accessibility, it certainly reduces reading comfort.

I have compiled the following list of default text color for functional themes (excluding themes with non-white backgrounds) on trunk.

-=000000=-
*Jqui
*Utopias

-=222222=-
*Tikinewt
*Yeti

-=333333=-
*Default Bootstrap
*Cosmo
*Darkshine
*Feb12
*Fivealive
*Fivealive-lite
*Readable
*Strasa
*Thenews
*United

-=363636=-
*Didiem

-=555555=-
*Cerulean
*Lumen

-=515151=-
*Greenvalley

-=666666=-
*Paper
*Spacelab

-=737373=-
*Business

-=777777=-
*Journal
*Simplex

Flatly and Sandstone are slightly special cases, as the text is tinted. The former uses #2c3e50, the latter #3e3f3a.

This problem is developing. Grey fonts have become a fashion, as recently [http://www.telegraph.co.uk/science/2016/10/23/internet-is-becoming-unreadable-because-of-a-trend-towards-light/|reported by The Telegraph]. In Tiki 9, the default color was pure black. In Tiki 15, it has become #333333.

I am not asking for a strictly pure black or pure white interface. I understand that other colors can be aesthetically or functionally better. What am I asking is to increase the contrast for the main content (the context of a wiki page, or of the blog post being viewed, for example).

Suckerfish menu dropdown items flicker in IE6 (rapidly switch between being displayed and background showing), apparently due to a javascript conflict. This happens whether or not jquery (w/ or w/o superfish) is activated. This type of menu works fine in IE6 normally (such as at the Superfish demo site), so there seems to be a conflict with something in Tiki. A Google search turned up similar problems in Joomla and Drupal, and was caused there by some conflict with some the javascript used by some module or other. I tested CSS variations, to rule out the possibility of CSS being the cause - no change made a difference.

Assuming Tiki will move from php layers menus to suckerfish menus, and there will still be a significant number of IE6 users, this should be solved as soon as possible.

on 1.9.cvs
See it in here: http://www.moviments.net/valldelcorb
Try changing language as anonymous from default (catalan) to Spanish, for instance. a blank page is shown.

If you do the same as registered, the interface is changed to Spanish, as expected, and as it happenened always with previous versions of Tiki.
(That happened with empty wiki homepage).

-----

However, I tried today (homepage had some articles through article plugin) as registered (user with admin rights), from this page:
http://www.moviments.net/valldelcorb/tiki-index.php

and I got:
^Warning: preg_replace() [function.preg-replace]: Unknown modifier 'd' in /home/httpd/tiki19/tiki-switch_lang.php on line 47

Warning: Cannot modify header information - headers already sent by (output started at /home/httpd/tiki19/tiki-switch_lang.php:47) in /home/httpd/tiki19/tiki-switch_lang.php on line 70
^
plus a blank page.

???

This tracker item could not be found

Using the switch-theme module has no effect. The page refreshes but the theme doesn't change. But, it works as expected when the user is logged in.

see also : http://dev.tiki.org/item4874

Changing a site theme with a URL like tiki-switch_theme.php?theme=fivealive.css&option=kiwi.css was effective in the past, but in Tiki 14 and trunk, it seems to just activate the "default" theme.

http://themes.tiki.org/Sample+page

{flash type="url" movie="display528" width="1111" height="494"}

Using latest 1.9.cvs (from 13th june 2007), and simple.css and tpl's.

Maybe related to these other bug reports by me a momoent ago with Calendars:
[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1136&show=view&offset=0&reloff=2&status=op&trackerId=5&sort_mode=created_desc|bug 1]
[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1138&show=view&offset=0&reloff=0&status=op&trackerId=5&sort_mode=created_desc|bug 2]

I attempted to create a simple event at this newly created calendar ("Comisión Web", see previous bug reports). I get a red message saying ~~red:Syntax error~~ (in Spanish, due to lang interface in Spanish).

See screenshot attached (if I can), after posting this bug report.
That's the text I introduced:
{CODE()}
Prueba de item: retocar estilo de tema de la web (a partir de simple.css)
{CODE}
-----
Update: when using tikineat.css and tpl's, or smartiki.css and tpl's, for instance, everything works fine, as expected.