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
To help developers solve the bug, we kindly request that you demonstrate your bug on a show2.tiki.org instance. To start, simply select a version and click on "Create show2.tiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show2.tiki.org.
To help developers solve the bug, we kindly request that you demonstrate your bug on a show.tikiwiki.org instance. To start, simply select a version and click on "Create show.tikiwiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show.tikiwiki.org.
filename | created | hits | comment | version | filetype | ||
---|---|---|---|---|---|---|---|
No attachments for this item |