history "WikkaCSS":Wikka

-an unofficial [[http://skins.openformats.org/wikka.php?wakka=HomePage | Wikka Skin Repository]]
1) be coded as an **unordered list**. See this [[http://www.sovavsiti.cz/css/horizontal_menu.html | tutorial]]
I was thinking about a menu system like [[http://www.hiermenuscentral.com/ | Hiermenus]]. --JamesMcl
(BTW, a formatter for css would be nice ;-)) - See [[http://qbnz.com/highlighter/ | GeSHi!]] which several other Wikis are already using...)
~I would be extremely sad if DarTar gave up. DarTar, this is your home now -- no need to ever go away to some other wiki land. Stay forever. :) Anyway.... the real reason I'm writing: how about we revisit JW's idea of having user-specific CSS? I really like this idea. Many months ago I explored this idea in Wikka's defunct sister project, [[http://www.jsnx.com/WikkaRTE/HomePage | WikkaRTE]]. Double-click on the homepage, and notice the input box for page level CSS. How about we add a box to UserSettings that allows each user to enter their own CSS that could override the Wikka stylesheets? I'm sure that DarTar is not the only one who would like to customize a certain aspect of the stylesheet. -- JsnX
Of course you need a browser like [[http://mozilla.org | Firefox / Mozilla]] to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].

-an unofficial [[http://skins.openformats.org/wikka.php?wakka=HomePage Wikka Skin Repository]]
1) be coded as an **unordered list**. See this [[http://www.sovavsiti.cz/css/horizontal_menu.html tutorial]]
I was thinking about a menu system like [[http://www.hiermenuscentral.com/ Hiermenus]]. --JamesMcl
(BTW, a formatter for css would be nice ;-)) - See [[http://qbnz.com/highlighter/ GeSHi!]] which several other Wikis are already using...)
~I would be extremely sad if DarTar gave up. DarTar, this is your home now -- no need to ever go away to some other wiki land. Stay forever. :) Anyway.... the real reason I'm writing: how about we revisit JW's idea of having user-specific CSS? I really like this idea. Many months ago I explored this idea in Wikka's defunct sister project, [[http://www.jsnx.com/WikkaRTE/HomePage WikkaRTE]]. Double-click on the homepage, and notice the input box for page level CSS. How about we add a box to UserSettings that allows each user to enter their own CSS that could override the Wikka stylesheets? I'm sure that DarTar is not the only one who would like to customize a certain aspect of the stylesheet. -- JsnX
Of course you need a browser like [[http://mozilla.org Firefox / Mozilla]] to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].

<P class=nextbutton><A href="javascript:history.back()">< Back to
tutorial</A> </P></DIV>
<DIV id=footer>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV></DIV></BODY></HTML>%%
==Better code rendering==
I found that bits of code sometimes are rendered hard to understand, with both loss of original indents and line wrapping. The cause is 1) inheritance of the body's "justify" text alignment, and 2) the fact that lines are allowed to wrap (overflow: auto; doesn't prevent this).
My suggested solution is the following change for the code class in wikka.css:
%%(css)
.code {
color: black;
background: #ffffee;
border: 1px solid #888;
font: 11px "Bitstream Vera Sans Mono","Courier New", monospace;
width: 95%;
margin:auto;
padding: 3px;
text-align: left; /* override justify on body */
overflow: auto; /* allow scroll bar in case of long lines - goes together with white-space: nowrap! */
white-space: nowrap; /* prevent line wrapping */
%%
(BTW, a formatter for css would be nice ;-)) - See [[http://qbnz.com/highlighter/ GeSHi!]] which several other Wikis are already using...)
-- JavaWoman
Thanks for the excellent tip above. Code formatting is looking much better..... -- JsnX
''Sorry for this late reaction. Am I the only one who found the wrapped lines much easier to read? With the new .code class, if I want to read the end of long lines in long block of codes with no line wrap I have to:
1) scroll down until I find the horizontal scrollbar,
1) scroll right to the end of the block,
1) scroll up to the line,
1) read it,
1) rescroll down to the horizontal bar,
1) rescroll left,
1) rescroll up to the line and continue reading, ---
which means 7 operations per line. I found the old version much more intuitive (to me this was one of the biggest layout improvements between wakka and wikka) and I confess I really hate horizontal bars'' --DarTar
~Heh, I generally hate horizontal scroll bars - but I hate wrapped lines of code even more! Just comment out the white-space: nowrap; rule and you should have your wrapped lines back. Do we need a vote? --JavaWoman
~If you need the original version of the code, without wrapped-lines, you just need to switch to the editable version of the page ;-p To me, the "show" method should enable an all-at-once glance to the code, not a cut&paste version, hence I'd vote for wrapped lines as a default -- DarTar
~I agree with both of you. Neither way is ideal. However I'd rather deal with the scrolling inconvenience than scan through a bunch of wrapped lines of code. *shrug* Vote: nowrap. - JsnX
~Any other votes?
~There is no way for something like a user-option (beeing unable to decide :-) NilsLindenberg
~''Possible, although in a roundabout way since our stylesheets are static, not generated. But it //might// be possible to generate a class on the code tag depending on user preference, and then tie CSS styling to that class (as opposed to styling without that class, i.e., the class would be the exception to the default). Such a user option would then need to be stored in the user table (a new column). So yes, possible (technically, at least) - but personally I think it's a bit overkill. :) --JavaWoman''
~I agree with JW and democratically acknowledge the vote of the majority - but I gonna write some private lines of code to make dartarmagically vanish any nowrap attribute while I'm logged in :) -- DarTar
~''Phew! You had me worried there with your 'Giving up' edit note. Glad to learn you're only planning a bit of underhanded "dartarmagic" (any kind of magic being fitting for "Wikka", of course!). --JavaWoman''
~I would be extremely sad if DarTar gave up. DarTar, this is your home now -- no need to ever go away to some other wiki land. Stay forever. :) Anyway.... the real reason I'm writing: how about we revisit JW's idea of having user-specific CSS? I really like this idea. Many months ago I explored this idea in Wikka's defunct sister project, [[http://www.jsnx.com/WikkaRTE/HomePage WikkaRTE]]. Double-click on the homepage, and notice the input box for page level CSS. How about we add a box to UserSettings that allows each user to enter their own CSS that could override the Wikka stylesheets? I'm sure that DarTar is not the only one who would like to customize a certain aspect of the stylesheet. -- JsnX
~''Well, of course any decent, standards-compliant browser //already// provides the user with a way to supply their own user stylesheet instead of whatever a website provides.
~Oh, wait. Not everyone **has** a decent browser or even access to one. :( But with DarTar's WikkaSkinSelector and WikkaSkinEditor and a few extensions, we're already there, I think:
~~-provide a number of basic but sufficiently different skins to choose from
~~-write-protect these
~~-create a "user styles" directory
~~-allow anyone to use the WikkaSkinEditor to edit an existing skin and "save as" a different skin to be stored in the "user styles" directory (not overwriting anyone else's skin)
~~-allow people to edit their own skins (needs some mechanism to record who "owns" what; and one person can own multiple skins)
~~-other people's skins can always be selected with a (modified) WikkaSkinSelector, or used as starting point for the WikkaSkinEditor to create a new skin
~~-store the current selection for skin in the session (not a separate cookie) and allow storing a "permanent" preference in the user profile (extra DB column)
~~-really nice skins can be added to the "standard" set
~How's that sound? I do like the possibility of having people select or build their own stylesheets very much, since it can enhance accessibility! --JavaWoman''
~''Sounds like a great idea. And - don't worry - It will take you much more than a nowrap line to make me leave :-p --DarTar''
Geshi is now hooked into Wikka. Go to SyntaxHighlighter for further discussion about it. -- JsnX
== Alternate stylesheets ==
I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :
* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :
%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%
* in header.php this two lines just after the last link and before the "style" box :
%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%
(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Of course you need a browser like [[http://mozilla.org Firefox / Mozilla]] to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].
--SergiO
CategoryDevelopmentSuggestions CategoryLayout

~~<P class=nextbutton><A href="javascript:history.back()">~~

<P class=nextbutton><A href="javascript:history.back()">< Back to
tutorial</A> </P></DIV>
<DIV id=footer>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV></DIV></BODY></HTML>%%
==Better code rendering==
I found that bits of code sometimes are rendered hard to understand, with both loss of original indents and line wrapping. The cause is 1) inheritance of the body's "justify" text alignment, and 2) the fact that lines are allowed to wrap (overflow: auto; doesn't prevent this).
My suggested solution is the following change for the code class in wikka.css:
%%(css)
.code {
color: black;
background: #ffffee;
border: 1px solid #888;
font: 11px "Bitstream Vera Sans Mono","Courier New", monospace;
width: 95%;
margin:auto;
padding: 3px;
text-align: left; /* override justify on body */
overflow: auto; /* allow scroll bar in case of long lines - goes together with white-space: nowrap! */
white-space: nowrap; /* prevent line wrapping */
%%
(BTW, a formatter for css would be nice ;-)) - See [[http://qbnz.com/highlighter/ GeSHi!]] which several other Wikis are already using...)
-- JavaWoman
Thanks for the excellent tip above. Code formatting is looking much better..... -- JsnX
''Sorry for this late reaction. Am I the only one who found the wrapped lines much easier to read? With the new .code class, if I want to read the end of long lines in long block of codes with no line wrap I have to:
1) scroll down until I find the horizontal scrollbar,
1) scroll right to the end of the block,
1) scroll up to the line,
1) read it,
1) rescroll down to the horizontal bar,
1) rescroll left,
1) rescroll up to the line and continue reading, ---
which means 7 operations per line. I found the old version much more intuitive (to me this was one of the biggest layout improvements between wakka and wikka) and I confess I really hate horizontal bars'' --DarTar
~Heh, I generally hate horizontal scroll bars - but I hate wrapped lines of code even more! Just comment out the white-space: nowrap; rule and you should have your wrapped lines back. Do we need a vote? --JavaWoman
~If you need the original version of the code, without wrapped-lines, you just need to switch to the editable version of the page ;-p To me, the "show" method should enable an all-at-once glance to the code, not a cut&paste version, hence I'd vote for wrapped lines as a default -- DarTar
~I agree with both of you. Neither way is ideal. However I'd rather deal with the scrolling inconvenience than scan through a bunch of wrapped lines of code. *shrug* Vote: nowrap. - JsnX
~Any other votes?
~There is no way for something like a user-option (beeing unable to decide :-) NilsLindenberg
~''Possible, although in a roundabout way since our stylesheets are static, not generated. But it //might// be possible to generate a class on the code tag depending on user preference, and then tie CSS styling to that class (as opposed to styling without that class, i.e., the class would be the exception to the default). Such a user option would then need to be stored in the user table (a new column). So yes, possible (technically, at least) - but personally I think it's a bit overkill. :) --JavaWoman''
~I agree with JW and democratically acknowledge the vote of the majority - but I gonna write some private lines of code to make dartarmagically vanish any nowrap attribute while I'm logged in :) -- DarTar
~''Phew! You had me worried there with your 'Giving up' edit note. Glad to learn you're only planning a bit of underhanded "dartarmagic" (any kind of magic being fitting for "Wikka", of course!). --JavaWoman''
~I would be extremely sad if DarTar gave up. DarTar, this is your home now -- no need to ever go away to some other wiki land. Stay forever. :) Anyway.... the real reason I'm writing: how about we revisit JW's idea of having user-specific CSS? I really like this idea. Many months ago I explored this idea in Wikka's defunct sister project, [[http://www.jsnx.com/WikkaRTE/HomePage WikkaRTE]]. Double-click on the homepage, and notice the input box for page level CSS. How about we add a box to UserSettings that allows each user to enter their own CSS that could override the Wikka stylesheets? I'm sure that DarTar is not the only one who would like to customize a certain aspect of the stylesheet. -- JsnX
~''Well, of course any decent, standards-compliant browser //already// provides the user with a way to supply their own user stylesheet instead of whatever a website provides.
~Oh, wait. Not everyone **has** a decent browser or even access to one. :( But with DarTar's WikkaSkinSelector and WikkaSkinEditor and a few extensions, we're already there, I think:
~~-provide a number of basic but sufficiently different skins to choose from
~~-write-protect these
~~-create a "user styles" directory
~~-allow anyone to use the WikkaSkinEditor to edit an existing skin and "save as" a different skin to be stored in the "user styles" directory (not overwriting anyone else's skin)
~~-allow people to edit their own skins (needs some mechanism to record who "owns" what; and one person can own multiple skins)
~~-other people's skins can always be selected with a (modified) WikkaSkinSelector, or used as starting point for the WikkaSkinEditor to create a new skin
~~-store the current selection for skin in the session (not a separate cookie) and allow storing a "permanent" preference in the user profile (extra DB column)
~~-really nice skins can be added to the "standard" set
~How's that sound? I do like the possibility of having people select or build their own stylesheets very much, since it can enhance accessibility! --JavaWoman''
~''Sounds like a great idea. And - don't worry - It will take you much more than a nowrap line to make me leave :-p --DarTar''
Geshi is now hooked into Wikka. Go to SyntaxHighlighter for further discussion about it. -- JsnX
== Alternate stylesheets ==
I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :
* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :
%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%
* in header.php this two lines just after the last link and before the "style" box :
%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%
(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Of course you need a browser like [[http://mozilla.org Firefox / Mozilla]] to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].
--SergiO
CategoryDevelopmentSuggestions CategoryLayout

===== Wikka CSS Issues =====
{{lastedit}}
Issues and discussion related to Wikka CSS stylesheets

<<**Related pages**:
-General bugs/issues see: WikkaBugs
-Wikka CSS specification see: WikkaSkins
-New layout proposal for Wikka: WikkaSkinOptimization

**Also relevant**:
-an unofficial [[http://skins.openformats.org/wikka.php?wakka=HomePage Wikka Skin Repository]]
<<::c::

----
==min-width and max-width==
You should not use fixed width in .floatr and .floatl classes. Instead, I suggest the use of max-width and min-width :
%%(css).floatl {float: left; margin: 0.5%; padding: 0.5%; background: #EEE; min-width: 100px; max-width: 300px;}
.floatr {float: right; margin: 0.5%; padding: 0.5%; background: #EEE; min-width: 100px; max-width: 300px;}%%
Try with the code ""<<{{calendar}}<< ""
--DotMG
== A Better Horizontal Menu ==

I find that the current Wikka horizontal menu allows very limited layout control.
A well formed CSS menu should IMO:

1) be put in a dedicated ##<DIV id="menu">## so that it can be moved around the page and its layout freely modified. See as an example this wikka site: http://www.awug.net/HomePage
1) be coded as an **unordered list**. See this [[http://www.sovavsiti.cz/css/horizontal_menu.html tutorial]]

Your ideas?

-- DarTar

''Just give the unordered list itself an id (which indicates //which// menu it is!), and it can be "moved around the page" as desired. No need to wrap it in a div just to do that (though a div may be useful for other purposes). I agree though that **all** menus should be marked up as unordered lists and styled with CSS.
-- JavaWoman''

''From the reference above: //The menu has to be wrapped by a div that is used for styling background color, left margin/padding, etc. I've found no way to style the UL itself, because I can't clear the float inside it. Thus the height of the OL always equals zero.//''
~I don't get this. Look at the menu at the top of the page: it is enclosed, together with the page's heading, in a div with class "header" (why not an id??? how many headers are there going to be on a page?) from which it inherits its background color; all you'd have to do is code the menu items as an unordered (not ordered) list instead of the current series of text, and then style it as a horizontal menu: it will still inherit the same background. No need for an extra div around the ul. --JavaWoman
''Beside this detail, I think the only problem that remains to be addressed is the question of menu configuration. How are we to save the menu settings in Wikka configuration (currently saved as a wikka-formatted string)? A good solution might be to create a menu administration module (in form of an action with a dedicated SQL table) that allows the user to specify items that go in the menu and their order (and maybe switch on/off an optional secondary menu). This would allow more flexibility than the current systems offers (one wouldn't need to edit the configuration file) and solve the problem of how to save the menu settings. I'm taking a day off from my work, I'll see if I can cook up something''
-- DarTar
~It's obvious that editing a configuration file (especially since it contains an array, and not every user is familiar with PHP syntax) is a problem; but the solution here would IMO not be to create a special menu creation function, but simply allow a simple way to edit the configuration. I'm working on a generic solution for that with configuration stored in an ini file and an admin web interface to edit the contents of the ini file. I think a separate table just for a menu is probably overkill. --JavaWoman

This approach to menus may have implications for the CategorySystemOverhaul. If the menu structures are created from a SQL table, then the definition of the category system would need to addressed and in place before hand.
--JamesMcl
~I must be extraordinarily dense today :) I'm not getting this either. A menu is simply a **collection** of links to pages or functionality - how or where would any category system come in with that? --JavaWoman

I was thinking about a menu system like [[http://www.hiermenuscentral.com/ Hiermenus]]. --JamesMcl

Thanks all for your quick feedback! I've cooked up a first version of a WikkaMenus module. Feel free to add your comments and modify the code.
@JW: you'll find on the page above my arguments why using menu table might be a better idea than editing the config file.
@James: actually, I was also thinking of menus as simple //collections// of links, but why not study a way to integrate multiple menus and categories, along the lines you were suggesting. To be continued...
-- DarTar

----
I have been trying to modify the style sheet without success. I cannot get the footer, commentsheader and smallprint areas to align as they should. They keep flowing below the menu. Could you offer any help, please.
The code for the layout that I'm trying to achieve is like below, any help would bew much appreciated.
An example header.php with the ordered list and id tag would also help.

%%(html)
""<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML lang=en><HEAD><TITLE>Two columns with color - Final layout</TITLE>
<META http-equiv=content-type content="text/html; charset=iso-8859-1">
<STYLE type=text/css media=screen>

hr {
margin-left: auto;
margin-right: auto;
margin-top: 1.25em;
margin-bottom: 1.25em;
width: 100%;
height: 4px;
background-color: #6BB300;
}

body,html {
scrollbar-face-color: #6BB300;
scrollbar-shadow-color: #E6FFBF;
scrollbar-highlight-color: #E6FFBF;
scrollbar-3dlight-color: #E6FFBF;
scrollbar-darkshadow-color: #E6FFBF;
scrollbar-track-color: #E6FFBF;
scrollbar-arrow-color: #000033;
}

.highlight {
scrollbar-face-color: #6BB300;
scrollbar-shadow-color: #E6FFBF;
scrollbar-highlight-color: #E6FFBF;
scrollbar-3dlight-color: #E6FFBF;
scrollbar-darkshadow-color: #E6FFBF;
scrollbar-track-color: #E6FFBF;
scrollbar-arrow-color: #000033;
}

BODY {
PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; COLOR: #000; PADDING-TOP: 0px; FONT-FAMILY: georgia, times, "times new roman", serif; BACKGROUND-COLOR: #ddd
}
#container {
BORDER-RIGHT: #333 1px solid; BORDER-TOP: #333 1px solid; BACKGROUND-IMAGE: url(images/background.jpg); MARGIN: 1em 5%; BORDER-LEFT: #333 1px solid; BORDER-BOTTOM: #333 1px solid; BACKGROUND-REPEAT: repeat-y; BACKGROUND-COLOR: #fff
}
#banner {
BORDER-BOTTOM: #333 1px solid; BACKGROUND-COLOR: #6BB300
}
#banner H1 {
PADDING-RIGHT: 0.5em; PADDING-LEFT: 0.5em; PADDING-BOTTOM: 0.5em; MARGIN: 0px; PADDING-TOP: 0.5em
}
div#sitenav {float: left; width: 145px; margin-top: 0;
font-size: 14px; background-color: white;
border-right: 1px solid black;
border-bottom: 1px solid black;}
div#sitenav a {display: block; padding: 4px 8px; margin: 0;
text-decoration: none; text-align: right;
border-top: 1px solid gray; background: #E6FFBF}
div#sitenav a:hover {background: #6BB300;}
div#sitenav a:hover {color: black;}
div#sitenav a {color: #6BB300; text-align: left;}
div#sitenav h4 {background: rgb(33%,33%,33%); color: white;
text-align: center; margin: 0; padding: 0.25em 0 0.125em 0;}

#nav {
FLOAT: left; MARGIN-LEFT: 10px; WIDTH: 145px; PADDING-TOP: 1em
#nav a {display: block; padding: 4px 8px; margin: 0;
text-decoration: none; text-align: right;
border-top: 1px solid gray;}
#nav a:hover {background: #FB9;}
#nav h4 {background: rgb(33%,33%,33%); color: white;
text-align: center; margin: 0; padding: 0.25em 0 0.125em 0;}
}
#nav P {
MARGIN-TOP: 0px
}
#content {
MARGIN: 0px 2em 0px 200px; PADDING-TOP: 1em
}
#content H2 {
MARGIN-TOP: 0px
}
#footer {
CLEAR: both; PADDING-RIGHT: 1em; BORDER-TOP: #333 1px solid; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; BACKGROUND-COLOR: #E6FFBF; TEXT-ALIGN: right
}
#footer2 {
CLEAR: both; PADDING-RIGHT: 1em; BORDER-TOP: #333 1px solid; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; BACKGROUND-COLOR: #CCFF80; TEXT-ALIGN: right
}
#footer3 {
CLEAR: both; PADDING-RIGHT: 1em; BORDER-TOP: #333 1px solid; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; BACKGROUND-COLOR: #99FF00; TEXT-ALIGN: right
}
</STYLE>

</HEAD>
<BODY>
<DIV id=container>
<DIV id=banner>
<H1>Site name</H1></DIV>
<DIV id=sitenav>
<P><b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=HomePage">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
</P></DIV>
<DIV id=content>
<H2>Page heading </H2>
<P>Ut wisi enim ad minim veniam, quis <a href="www.aol.com">Home Page</a> nostrud exerci tation ullamcorper suscipit
lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure
dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore
eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui
blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla
facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
<form>
<textarea class="highlight" rows=3 cols=45>
in hendrerit in
vulputate velit esse
molestie consequat
, vel illum dolore
eu feugiat nulla
facilisis at vero eros
et accumsan et iusto odio dign
issim qui
blandit praesent luptatum zzril delenit augue duis
</textarea>
</form></P>
<P>Ut wisi enim ad minim veniam, quis <a href="www.aol.com">Home Page</a> nostrud exerci tation ullamcorper suscipit
lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure
dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore <br><hr>
eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui
blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla
facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
</P>
<P class=nextbutton><A href="javascript:history.back()">< Back to
tutorial</A> </P></DIV>
<DIV id=footer>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV></DIV></BODY></HTML>%%

--JamesMcl
----

==Better code rendering==
I found that bits of code sometimes are rendered hard to understand, with both loss of original indents and line wrapping. The cause is 1) inheritance of the body's "justify" text alignment, and 2) the fact that lines are allowed to wrap (overflow: auto; doesn't prevent this).

My suggested solution is the following change for the code class in wikka.css:
%%(css)
.code {
color: black;
background: #ffffee;
border: 1px solid #888;
font: 11px "Bitstream Vera Sans Mono","Courier New", monospace;
width: 95%;
margin:auto;
padding: 3px;
text-align: left; /* override justify on body */
overflow: auto; /* allow scroll bar in case of long lines - goes together with white-space: nowrap! */
white-space: nowrap; /* prevent line wrapping */
}
%%
(BTW, a formatter for css would be nice ;-)) - See [[http://qbnz.com/highlighter/ GeSHi!]] which several other Wikis are already using...)
-- JavaWoman

Thanks for the excellent tip above. Code formatting is looking much better..... -- JsnX
''Sorry for this late reaction. Am I the only one who found the wrapped lines much easier to read? With the new .code class, if I want to read the end of long lines in long block of codes with no line wrap I have to:
1) scroll down until I find the horizontal scrollbar,
1) scroll right to the end of the block,
1) scroll up to the line,
1) read it,
1) rescroll down to the horizontal bar,
1) rescroll left,
1) rescroll up to the line and continue reading, ---
which means 7 operations per line. I found the old version much more intuitive (to me this was one of the biggest layout improvements between wakka and wikka) and I confess I really hate horizontal bars'' --DarTar
~Heh, I generally hate horizontal scroll bars - but I hate wrapped lines of code even more! Just comment out the white-space: nowrap; rule and you should have your wrapped lines back. Do we need a vote? --JavaWoman
~If you need the original version of the code, without wrapped-lines, you just need to switch to the editable version of the page ;-p To me, the "show" method should enable an all-at-once glance to the code, not a cut&paste version, hence I'd vote for wrapped lines as a default -- DarTar
~I agree with both of you. Neither way is ideal. However I'd rather deal with the scrolling inconvenience than scan through a bunch of wrapped lines of code. *shrug* Vote: nowrap. - JsnX
~Any other votes?
~There is no way for something like a user-option (beeing unable to decide :-) NilsLindenberg
~''Possible, although in a roundabout way since our stylesheets are static, not generated. But it //might// be possible to generate a class on the code tag depending on user preference, and then tie CSS styling to that class (as opposed to styling without that class, i.e., the class would be the exception to the default). Such a user option would then need to be stored in the user table (a new column). So yes, possible (technically, at least) - but personally I think it's a bit overkill. :) --JavaWoman''
~I agree with JW and democratically acknowledge the vote of the majority - but I gonna write some private lines of code to make dartarmagically vanish any nowrap attribute while I'm logged in :) -- DarTar
~''Phew! You had me worried there with your 'Giving up' edit note. Glad to learn you're only planning a bit of underhanded "dartarmagic" (any kind of magic being fitting for "Wikka", of course!). --JavaWoman''
~I would be extremely sad if DarTar gave up. DarTar, this is your home now -- no need to ever go away to some other wiki land. Stay forever. :) Anyway.... the real reason I'm writing: how about we revisit JW's idea of having user-specific CSS? I really like this idea. Many months ago I explored this idea in Wikka's defunct sister project, [[http://www.jsnx.com/WikkaRTE/HomePage WikkaRTE]]. Double-click on the homepage, and notice the input box for page level CSS. How about we add a box to UserSettings that allows each user to enter their own CSS that could override the Wikka stylesheets? I'm sure that DarTar is not the only one who would like to customize a certain aspect of the stylesheet. -- JsnX
~''Well, of course any decent, standards-compliant browser //already// provides the user with a way to supply their own user stylesheet instead of whatever a website provides.
~Oh, wait. Not everyone **has** a decent browser or even access to one. :( But with DarTar's WikkaSkinSelector and WikkaSkinEditor and a few extensions, we're already there, I think:
~~-provide a number of basic but sufficiently different skins to choose from
~~-write-protect these
~~-create a "user styles" directory
~~-allow anyone to use the WikkaSkinEditor to edit an existing skin and "save as" a different skin to be stored in the "user styles" directory (not overwriting anyone else's skin)
~~-allow people to edit their own skins (needs some mechanism to record who "owns" what; and one person can own multiple skins)
~~-other people's skins can always be selected with a (modified) WikkaSkinSelector, or used as starting point for the WikkaSkinEditor to create a new skin
~~-store the current selection for skin in the session (not a separate cookie) and allow storing a "permanent" preference in the user profile (extra DB column)
~~-really nice skins can be added to the "standard" set
~How's that sound? I do like the possibility of having people select or build their own stylesheets very much, since it can enhance accessibility! --JavaWoman''
~''Sounds like a great idea. And - don't worry - It will take you much more than a nowrap line to make me leave :-p --DarTar''

Geshi is now hooked into Wikka. Go to SyntaxHighlighter for further discussion about it. -- JsnX

----
----
== Alternate stylesheets ==

I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :

* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :

%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%

* in header.php this two lines just after the last link and before the "style" box :

%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%

(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Of course you need a browser like [[http://mozilla.org Firefox / Mozilla]] to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].

--SergiO

----
CategoryDevelopmentSuggestions CategoryLayout

===== Wikka CSS Issues =====
{{lastedit}}
Issues and discussion related to Wikka CSS stylesheets

<<**Related pages**:
-General bugs/issues see: WikkaBugs
-Wikka CSS specification see: WikkaSkins
-New layout proposal for Wikka: WikkaSkinOptimization

**Also relevant**:
-an unofficial [[http://skins.openformats.org/wikka.php?wakka=HomePage Wikka Skin Repository]]
<<::c::

----
==min-width and max-width==
You should not use fixed width in .floatr and .floatl classes. Instead, I suggest the use of max-width and min-width :
%%(css).floatl {float: left; margin: 0.5%; padding: 0.5%; background: #EEE; min-width: 100px; max-width: 300px;}
.floatr {float: right; margin: 0.5%; padding: 0.5%; background: #EEE; min-width: 100px; max-width: 300px;}%%
Try with the code ""<<{{calendar}}<< ""
--DotMG
== A Better Horizontal Menu ==

I find that the current Wikka horizontal menu allows very limited layout control.
A well formed CSS menu should IMO:

1) be put in a dedicated ##<DIV id="menu">## so that it can be moved around the page and its layout freely modified. See as an example this wikka site: http://www.awug.net/HomePage
1) be coded as an **unordered list**. See this [[http://www.sovavsiti.cz/css/horizontal_menu.html tutorial]]

Your ideas?

-- DarTar

''Just give the unordered list itself an id (which indicates //which// menu it is!), and it can be "moved around the page" as desired. No need to wrap it in a div just to do that (though a div may be useful for other purposes). I agree though that **all** menus should be marked up as unordered lists and styled with CSS.
-- JavaWoman''

''From the reference above: //The menu has to be wrapped by a div that is used for styling background color, left margin/padding, etc. I've found no way to style the UL itself, because I can't clear the float inside it. Thus the height of the OL always equals zero.//''
~I don't get this. Look at the menu at the top of the page: it is enclosed, together with the page's heading, in a div with class "header" (why not an id??? how many headers are there going to be on a page?) from which it inherits its background color; all you'd have to do is code the menu items as an unordered (not ordered) list instead of the current series of text, and then style it as a horizontal menu: it will still inherit the same background. No need for an extra div around the ul. --JavaWoman
''Beside this detail, I think the only problem that remains to be addressed is the question of menu configuration. How are we to save the menu settings in Wikka configuration (currently saved as a wikka-formatted string)? A good solution might be to create a menu administration module (in form of an action with a dedicated SQL table) that allows the user to specify items that go in the menu and their order (and maybe switch on/off an optional secondary menu). This would allow more flexibility than the current systems offers (one wouldn't need to edit the configuration file) and solve the problem of how to save the menu settings. I'm taking a day off from my work, I'll see if I can cook up something''
-- DarTar
~It's obvious that editing a configuration file (especially since it contains an array, and not every user is familiar with PHP syntax) is a problem; but the solution here would IMO not be to create a special menu creation function, but simply allow a simple way to edit the configuration. I'm working on a generic solution for that with configuration stored in an ini file and an admin web interface to edit the contents of the ini file. I think a separate table just for a menu is probably overkill. --JavaWoman

This approach to menus may have implications for the CategorySystemOverhaul. If the menu structures are created from a SQL table, then the definition of the category system would need to addressed and in place before hand.
--JamesMcl
~I must be extraordinarily dense today :) I'm not getting this either. A menu is simply a **collection** of links to pages or functionality - how or where would any category system come in with that? --JavaWoman

I was thinking about a menu system like [[http://www.hiermenuscentral.com/ Hiermenus]]. --JamesMcl

Thanks all for your quick feedback! I've cooked up a first version of a WikkaMenus module. Feel free to add your comments and modify the code.
@JW: you'll find on the page above my arguments why using menu table might be a better idea than editing the config file.
@James: actually, I was also thinking of menus as simple //collections// of links, but why not study a way to integrate multiple menus and categories, along the lines you were suggesting. To be continued...
-- DarTar

----
I have been trying to modify the style sheet without success. I cannot get the footer, commentsheader and smallprint areas to align as they should. They keep flowing below the menu. Could you offer any help, please.
The code for the layout that I'm trying to achieve is like below, any help would bew much appreciated.
An example header.php with the ordered list and id tag would also help.

%%(html)
""<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML lang=en><HEAD><TITLE>Two columns with color - Final layout</TITLE>
<META http-equiv=content-type content="text/html; charset=iso-8859-1">
<STYLE type=text/css media=screen>

hr {
margin-left: auto;
margin-right: auto;
margin-top: 1.25em;
margin-bottom: 1.25em;
width: 100%;
height: 4px;
background-color: #6BB300;
}

body,html {
scrollbar-face-color: #6BB300;
scrollbar-shadow-color: #E6FFBF;
scrollbar-highlight-color: #E6FFBF;
scrollbar-3dlight-color: #E6FFBF;
scrollbar-darkshadow-color: #E6FFBF;
scrollbar-track-color: #E6FFBF;
scrollbar-arrow-color: #000033;
}

.highlight {
scrollbar-face-color: #6BB300;
scrollbar-shadow-color: #E6FFBF;
scrollbar-highlight-color: #E6FFBF;
scrollbar-3dlight-color: #E6FFBF;
scrollbar-darkshadow-color: #E6FFBF;
scrollbar-track-color: #E6FFBF;
scrollbar-arrow-color: #000033;
}

BODY {
PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; COLOR: #000; PADDING-TOP: 0px; FONT-FAMILY: georgia, times, "times new roman", serif; BACKGROUND-COLOR: #ddd
}
#container {
BORDER-RIGHT: #333 1px solid; BORDER-TOP: #333 1px solid; BACKGROUND-IMAGE: url(images/background.jpg); MARGIN: 1em 5%; BORDER-LEFT: #333 1px solid; BORDER-BOTTOM: #333 1px solid; BACKGROUND-REPEAT: repeat-y; BACKGROUND-COLOR: #fff
}
#banner {
BORDER-BOTTOM: #333 1px solid; BACKGROUND-COLOR: #6BB300
}
#banner H1 {
PADDING-RIGHT: 0.5em; PADDING-LEFT: 0.5em; PADDING-BOTTOM: 0.5em; MARGIN: 0px; PADDING-TOP: 0.5em
}
div#sitenav {float: left; width: 145px; margin-top: 0;
font-size: 14px; background-color: white;
border-right: 1px solid black;
border-bottom: 1px solid black;}
div#sitenav a {display: block; padding: 4px 8px; margin: 0;
text-decoration: none; text-align: right;
border-top: 1px solid gray; background: #E6FFBF}
div#sitenav a:hover {background: #6BB300;}
div#sitenav a:hover {color: black;}
div#sitenav a {color: #6BB300; text-align: left;}
div#sitenav h4 {background: rgb(33%,33%,33%); color: white;
text-align: center; margin: 0; padding: 0.25em 0 0.125em 0;}

#nav {
FLOAT: left; MARGIN-LEFT: 10px; WIDTH: 145px; PADDING-TOP: 1em
#nav a {display: block; padding: 4px 8px; margin: 0;
text-decoration: none; text-align: right;
border-top: 1px solid gray;}
#nav a:hover {background: #FB9;}
#nav h4 {background: rgb(33%,33%,33%); color: white;
text-align: center; margin: 0; padding: 0.25em 0 0.125em 0;}
}
#nav P {
MARGIN-TOP: 0px
}
#content {
MARGIN: 0px 2em 0px 200px; PADDING-TOP: 1em
}
#content H2 {
MARGIN-TOP: 0px
}
#footer {
CLEAR: both; PADDING-RIGHT: 1em; BORDER-TOP: #333 1px solid; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; BACKGROUND-COLOR: #E6FFBF; TEXT-ALIGN: right
}
#footer2 {
CLEAR: both; PADDING-RIGHT: 1em; BORDER-TOP: #333 1px solid; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; BACKGROUND-COLOR: #CCFF80; TEXT-ALIGN: right
}
#footer3 {
CLEAR: both; PADDING-RIGHT: 1em; BORDER-TOP: #333 1px solid; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; BACKGROUND-COLOR: #99FF00; TEXT-ALIGN: right
}
</STYLE>

</HEAD>
<BODY>
<DIV id=container>
<DIV id=banner>
<H1>Site name</H1></DIV>
<DIV id=sitenav>
<P><b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=HomePage">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
</P></DIV>
<DIV id=content>
<H2>Page heading </H2>
<P>Ut wisi enim ad minim veniam, quis <a href="www.aol.com">Home Page</a> nostrud exerci tation ullamcorper suscipit
lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure
dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore
eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui
blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla
facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
<form>
<textarea class="highlight" rows=3 cols=45>
in hendrerit in
vulputate velit esse
molestie consequat
, vel illum dolore
eu feugiat nulla
facilisis at vero eros
et accumsan et iusto odio dign
issim qui
blandit praesent luptatum zzril delenit augue duis
</textarea>
</form></P>
<P>Ut wisi enim ad minim veniam, quis <a href="www.aol.com">Home Page</a> nostrud exerci tation ullamcorper suscipit
lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure
dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore <br><hr>
eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui
blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla
facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
</P>
<P class=nextbutton><A href="javascript:history.back()">< Back to
tutorial</A> </P></DIV>
<DIV id=footer>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV></DIV></BODY></HTML>%%

--JamesMcl
----

==Better code rendering==
I found that bits of code sometimes are rendered hard to understand, with both loss of original indents and line wrapping. The cause is 1) inheritance of the body's "justify" text alignment, and 2) the fact that lines are allowed to wrap (overflow: auto; doesn't prevent this).

My suggested solution is the following change for the code class in wikka.css:
%%(css)
.code {
color: black;
background: #ffffee;
border: 1px solid #888;
font: 11px "Bitstream Vera Sans Mono","Courier New", monospace;
width: 95%;
margin:auto;
padding: 3px;
text-align: left; /* override justify on body */
overflow: auto; /* allow scroll bar in case of long lines - goes together with white-space: nowrap! */
white-space: nowrap; /* prevent line wrapping */
}
%%
(BTW, a formatter for css would be nice ;-)) - See [[http://qbnz.com/highlighter/ GeSHi!]] which several other Wikis are already using...)
-- JavaWoman

Thanks for the excellent tip above. Code formatting is looking much better..... -- JsnX
''Sorry for this late reaction. Am I the only one who found the wrapped lines much easier to read? With the new .code class, if I want to read the end of long lines in long block of codes with no line wrap I have to:
1) scroll down until I find the horizontal scrollbar,
1) scroll right to the end of the block,
1) scroll up to the line,
1) read it,
1) rescroll down to the horizontal bar,
1) rescroll left,
1) rescroll up to the line and continue reading, ---
which means 7 operations per line. I found the old version much more intuitive (to me this was one of the biggest layout improvements between wakka and wikka) and I confess I really hate horizontal bars'' --DarTar
~Heh, I generally hate horizontal scroll bars - but I hate wrapped lines of code even more! Just comment out the white-space: nowrap; rule and you should have your wrapped lines back. Do we need a vote? --JavaWoman
~If you need the original version of the code, without wrapped-lines, you just need to switch to the editable version of the page ;-p To me, the "show" method should enable an all-at-once glance to the code, not a cut&paste version, hence I'd vote for wrapped lines as a default -- DarTar
~I agree with both of you. Neither way is ideal. However I'd rather deal with the scrolling inconvenience than scan through a bunch of wrapped lines of code. *shrug* Vote: nowrap. - JsnX
~Any other votes?
~There is no way for something like a user-option (beeing unable to decide :-) NilsLindenberg
~''Possible, although in a roundabout way since our stylesheets are static, not generated. But it //might// be possible to generate a class on the code tag depending on user preference, and then tie CSS styling to that class (as opposed to styling without that class, i.e., the class would be the exception to the default). Such a user option would then need to be stored in the user table (a new column). So yes, possible (technically, at least) - but personally I think it's a bit overkill. :) --JavaWoman''
~I agree with JW and democratically acknowledge the vote of the majority - but I gonna write some private lines of code to make dartarmagically vanish any nowrap attribute while I'm logged in :) -- DarTar
~''Phew! You had me worried there with your 'Giving up' edit note. Glad to learn you're only planning a bit of underhanded "dartarmagic" (any kind of magic being fitting for "Wikka", of course!). --JavaWoman''
~I would be extremely sad if DarTar gave up. DarTar, this is your home now -- no need to ever go away to some other wiki land. Stay forever. :) Anyway.... the real reason I'm writing: how about we revisit JW's idea of having user-specific CSS? I really like this idea. Many months ago I explored this idea in Wikka's defunct sister project, [[http://www.jsnx.com/WikkaRTE/HomePage WikkaRTE]]. Double-click on the homepage, and notice the input box for page level CSS. How about we add a box to UserSettings that allows each user to enter their own CSS that could override the Wikka stylesheets? I'm sure that DarTar is not the only one who would like to customize a certain aspect of the stylesheet. -- JsnX
~''Well, of course any decent, standards-compliant browser //already// provides the user with a way to supply their own user stylesheet instead of whatever a website provides.
~Oh, wait. Not everyone **has** a decent browser or even access to one. :( But with DarTar's WikkaSkinSelector and WikkaSkinEditor and a few extensions, we're already there, I think:
~~-provide a number of basic but sufficiently different skins to choose from
~~-write-protect these
~~-create a "user styles" directory
~~-allow anyone to use the WikkaSkinEditor to edit an existing skin and "save as" a different skin to be stored in the "user styles" directory (not overwriting anyone else's skin)
~~-allow people to edit their own skins (needs some mechanism to record who "owns" what; and one person can own multiple skins)
~~-other people's skins can always be selected with a (modified) WikkaSkinSelector, or used as starting point for the WikkaSkinEditor to create a new skin
~~-store the current selection for skin in the session (not a separate cookie) and allow storing a "permanent" preference in the user profile (extra DB column)
~~-really nice skins can be added to the "standard" set
~How's that sound? I do like the possibility of having people select or build their own stylesheets very much, since it can enhance accessibility! --JavaWoman''
~''Sounds like a great idea. And - don't worry - It will take you much more than a nowrap line to make me leave :-p --DarTar''

Geshi is now hooked into Wikka. Go to SyntaxHighlighter for further discussion about it. -- JsnX

----
----
== Alternate stylesheets ==

I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :

* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :

%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%

* in header.php this two lines just after the last link and before the "style" box :

%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%

(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Of course you need a browser like [[http://mozilla.org Firefox / Mozilla]] to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].

--SergiO

----
CategoryDevelopment CategoryLayout

==min-width and max-width==
You should not use fixed width in .floatr and .floatl classes. Instead, I suggest the use of max-width and min-width :
%%(css).floatl {float: left; margin: 0.5%; padding: 0.5%; background: #EEE; min-width: 100px; max-width: 300px;}
.floatr {float: right; margin: 0.5%; padding: 0.5%; background: #EEE; min-width: 100px; max-width: 300px;}%%
Try with the code ""<<{{calendar}}<< ""
--DotMG

~''Sounds like a great idea. And - don't worry - It will take you much more than a nowrap line to make me leave :-p --DarTar''

~I would be extremely sad if DarTar gave up. DarTar, this is your home now -- no need to ever go away to some other wiki land. Stay forever. :) Anyway.... the real reason I'm writing: how about we revisit JW's idea of having user-specific CSS? I really like this idea. Many months ago I explored this idea in Wikka's defunct sister project, [[http://www.jsnx.com/WikkaRTE/HomePage WikkaRTE]]. Double-click on the homepage, and notice the input box for page level CSS. How about we add a box to UserSettings that allows each user to enter their own CSS that could override the Wikka stylesheets? I'm sure that DarTar is not the only one who would like to customize a certain aspect of the stylesheet. -- JsnX
~''Well, of course any decent, standards-compliant browser //already// provides the user with a way to supply their own user stylesheet instead of whatever a website provides.
~Oh, wait. Not everyone **has** a decent browser or even access to one. :( But with DarTar's WikkaSkinSelector and WikkaSkinEditor and a few extensions, we're already there, I think:
~~-provide a number of basic but sufficiently different skins to choose from
~~-write-protect these
~~-create a "user styles" directory
~~-allow anyone to use the WikkaSkinEditor to edit an existing skin and "save as" a different skin to be stored in the "user styles" directory (not overwriting anyone else's skin)
~~-allow people to edit their own skins (needs some mechanism to record who "owns" what; and one person can own multiple skins)
~~-other people's skins can always be selected with a (modified) WikkaSkinSelector, or used as starting point for the WikkaSkinEditor to create a new skin
~~-store the current selection for skin in the session (not a separate cookie) and allow storing a "permanent" preference in the user profile (extra DB column)
~~-really nice skins can be added to the "standard" set
~How's that sound? I do like the possibility of having people select or build their own stylesheets very much, since it can enhance accessibility! --JavaWoman''

~I would be extremely sad if DarTar gave up. DarTar, this is your home now -- no need to ever go away to some other wiki land. Stay forever. :) Anyway.... the real reason I'm writing: how about we revisit JW's idea of having user-specific CSS? I really like this idea. Many months ago I explored this idea in Wikka's defunct sister project, [[http://www.jsnx.com/WikkaRTE/HomePage WikkaRTE]]. Double-click on the homepage, and notice the input box for page level CSS. How about we add a box to UserSettings that allows each user to enter their own CSS that could override the Wikka stylesheets? I'm sure that DarTar is not the only one who would like to customize a certain aspect of the stylesheet. -- JsnX

~I agree with JW and democratically acknowledge the vote of the majority - but I gonna write some private lines of code to make dartarmagically vanish any nowrap attribute while I'm logged in :) -- DarTar
~''Phew! You had me worried there with your 'Giving up' edit note. Glad to learn you're only planning a bit of underhanded "dartarmagic" (any kind of magic being fitting for "Wikka", of course!). --JavaWoman''

~I agree with JW and democratically acknowledge the vote of the majority - but I gonna write some private lines of code to make dartarmagically vanish any nowrap attribute while I'm logged in :) -- DarTar

~There is no way for something like a user-option (beeing unable to decide :-) NilsLindenberg
~''Possible, although in a roundabout way since our stylesheets are static, not generated. But it //might// be possible to generate a class on the code tag depending on user preference, and then tie CSS styling to that class (as opposed to styling without that class, i.e., the class would be the exception to the default). Such a user option would then need to be stored in the user table (a new column). So yes, possible (technically, at least) - but personally I think it's a bit overkill. :) --JavaWoman''

~~~There is no way for something like a user-option (beeing unable to decide :-) NilsLindenberg~~

~There is no way for something like a user-option (beeing unable to decide :-) NilsLindenberg

~I agree with both of you. Neither way is ideal. However I'd rather deal with the scrolling inconvenience than scan through a bunch of wrapped lines of code. *shrug* Vote: nowrap. - JsnX
~Any other votes?

~If you need the original version of the code, without wrapped-lines, you just need to switch to the editable version of the page ;-p To me, the "show" method should enable an all-at-once glance to the code, not a cut&paste version, hence I'd vote for wrapped lines as a default -- DarTar

which means 7 operations per line. I found the old version much more intuitive (to me this was one of the biggest layout improvements between wakka and wikka) and I confess I really hate horizontal bars'' --DarTar
~Heh, I generally hate horizontal scroll bars - but I hate wrapped lines of code even more! Just comment out the white-space: nowrap; rule and you should have your wrapped lines back. Do we need a vote? --JavaWoman

which means 7 operations per line. I found the old version much more intuitive (to me this was one of the biggest layout improvements between wakka and wikka) and I confess I really hate horizontal bars --DarTar

~~which means 7 operations per line. I found the old version much more intuitive (to me this was one of the big steps between wakka and wikka) and I confess I really hate horizontal bars --DarTar~~

1) rescroll up to the line and continue reading, ---

~~1) rescroll up to the line and continue reading,~~

{{lastedit}}
Thanks for the excellent tip above. Code formatting is looking much better..... -- JsnX
''Sorry for this late reaction. Am I the only one who found the wrapped lines much easier to read? With the new .code class, if I want to read the end of long lines in long block of codes with no line wrap I have to:
1) scroll down until I find the horizontal scrollbar,
1) scroll right to the end of the block,
1) scroll up to the line,
1) read it,
1) rescroll down to the horizontal bar,
1) rescroll left,
1) rescroll up to the line and continue reading,
which means 7 operations per line. I found the old version much more intuitive (to me this was one of the big steps between wakka and wikka) and I confess I really hate horizontal bars --DarTar

~~Thanks for the excellent tip above. Code formatting is looking much better.....~~

%%(html)
%%(css)
Thanks for the excellent tip above. Code formatting is looking much better.....
Geshi is now hooked into Wikka. Go to SyntaxHighlighter for further discussion about it. -- JsnX

== Strikethrough rendering ==
Strikethrough seems to highlight the selected text ++like this++ instead of striking through it. Looks like Wikka uses the deletions class from wikka.css instead of the strikethrough class.
.strikethrough {color: #888; text-decoration: line-through;}
.deletions {color: #876; background-color: #FFCC99;}
--RichardTerry
(see new code below)
--NilsLindenberg (no own computer, no installed wikka :(
''Marking "a strikethrough" as "deletion" in order to get a certain rendering is just a roundabout way to go back to presentational markup instead of structural, semantic markup! The class should indicate its purpose (i.e., real clasification!); so if the purpose is "strikethrough" rather than "deletion", it should indeed be a separate class. In the CSS you then have the freedom to either style both classes the same, or to style them differently.
See also my remarks about "markup of diff pages" in the SuggestionBox!
Yes, I have read your remarks in the SB. But this is (hopefully, as i can't test it) an easy solution for the problem, as long as it isn't modified towards your suggestions.
The problem is, that there is no handling for "deletion". Instead, "strikethrough" is missused for it. To change this:
change in **formaters/wakka.php**
static $trigger_inserted = 0;
static $trigger_center = 0;
to
static $trigger_inserted = 0;
static $trigger_deleted = 0;
static $trigger_center = 0;
and
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_italic =$trigger_keys = 0;
to
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic =$trigger_keys = 0;
and
// strikethrough
else if ($thing == "++" || $thing == "¥¥")
{
return (++$trigger_strike % 2 ? "<span class=\"deletions\">" : "</span>");
}
to
// strikethrough
else if ($thing == "++")
{
return (++$trigger_strike % 2 ? "<span class=\"strikethrough\">" : "</span>");
}
and add (after ""//inserted""))
// deletions
else if ($thing == ""¥¥")
{
return (++$trigger_deleted % 2 ? "<span class=\"deletions\">" : "</span>");
}
== Missing Pages ==
Is there a reason why missing pages are marked through ##<a href="..."><span class="missingpage">Page name</span></a>## instead of ##<a class="missingpage">Page name</a>##? This makes control on ##hover## behavior difficult.
None that I know of. I made the change. Better now? -- JsnX

None that I know of. I made the change. Better now? -- JsnX

-General bugs/issues see: WikkaBugs
-Wikka CSS specification see: WikkaSkins
-New layout proposal for Wikka: WikkaSkinOptimization

-for general bugs/issues see: WikkaBugs
-for Wikka CSS specification see: WikkaSkins

CategoryDevelopment CategoryLayout

~~CategoryDevelopment~~

Thanks all for your quick feedback! I've cooked up a first version of a WikkaMenus module. Feel free to add your comments and modify the code.
@JW: you'll find on the page above my arguments why using menu table might be a better idea than editing the config file.
@James: actually, I was also thinking of menus as simple //collections// of links, but why not study a way to integrate multiple menus and categories, along the lines you were suggesting. To be continued...

I was thinking about a menu system like [[http://www.hiermenuscentral.com/ Hiermenus]]. --JamesMcl

''From the reference above: //The menu has to be wrapped by a div that is used for styling background color, left margin/padding, etc. I've found no way to style the UL itself, because I can't clear the float inside it. Thus the height of the OL always equals zero.//''
~I don't get this. Look at the menu at the top of the page: it is enclosed, together with the page's heading, in a div with class "header" (why not an id??? how many headers are there going to be on a page?) from which it inherits its background color; all you'd have to do is code the menu items as an unordered (not ordered) list instead of the current series of text, and then style it as a horizontal menu: it will still inherit the same background. No need for an extra div around the ul. --JavaWoman
''Beside this detail, I think the only problem that remains to be addressed is the question of menu configuration. How are we to save the menu settings in Wikka configuration (currently saved as a wikka-formatted string)? A good solution might be to create a menu administration module (in form of an action with a dedicated SQL table) that allows the user to specify items that go in the menu and their order (and maybe switch on/off an optional secondary menu). This would allow more flexibility than the current systems offers (one wouldn't need to edit the configuration file) and solve the problem of how to save the menu settings. I'm taking a day off from my work, I'll see if I can cook up something''
~It's obvious that editing a configuration file (especially since it contains an array, and not every user is familiar with PHP syntax) is a problem; but the solution here would IMO not be to create a special menu creation function, but simply allow a simple way to edit the configuration. I'm working on a generic solution for that with configuration stored in an ini file and an admin web interface to edit the contents of the ini file. I think a separate table just for a menu is probably overkill. --JavaWoman
~I must be extraordinarily dense today :) I'm not getting this either. A menu is simply a **collection** of links to pages or functionality - how or where would any category system come in with that? --JavaWoman

''From the reference above: //The menu has to be wrapped by a div that is used for styling background color, left margin/padding, etc. I've found no way to style the UL itself, because I can't clear the float inside it. Thus the height of the OL always equals zero.//
Beside this detail, I think the only problem that remains to be addressed is the question of menu configuration. How are we to save the menu settings in Wikka configuration (currently saved as a wikka-formatted string)? A good solution might be to create a menu administration module (in form of an action with a dedicated SQL table) that allows the user to specify items that go in the menu and their order (and maybe switch on/off an optional secondary menu). This would allow more flexibility than the current systems offers (one wouldn't need to edit the configuration file) and solve the problem of how to save the menu settings. I'm taking a day off from my work, I'll see if I can cook up something''

This approach to menus may have implications for the CategorySystemOverhaul. If the menu structures are created from a SQL table, then the definition of the category system would need to addressed and in place before hand.

Beside this detail, I think the only problem that remains to be addressed is the question of menu configuration. How are we to save the menu settings in Wikka configuration (currently saved as a wikka-formatted string)? A good solution might be to create a menu administration module (in form of an action with a dedicated SQL table) that allows the user to specify items that go in the menu and their order (and maybe switch on/off an optional secondary menu). This would allow more flexibility than the current systems offers (one wouldn't need to edit the configuration file) and solve the problem of how to save the menu settings. I'm taking a day off from my work, I'll see if I can cook up something''

Beside this detail, I think the only problem that remains to be addressed is the question of menu configuration. How are we to save the menu settings in Wikka configuration (currently saved as a wikka-formatted string)? A good solution might be to create a menu administration module (in form of an action with a dedicated SQL table) that allows the user to specify items that go in the menu and their order (and maybe switch on/off an optional secondary menu). This would allow more flexibility than the current systems offers (one wouldn't need to edit the configuration file) and solve the problem of how to save the menu settings. I'm taking a day off from my work, I'll se if I can cook up something''

''From the reference above: //The menu has to be wrapped by a div that is used for styling background color, left margin/padding, etc. I've found no way to style the UL itself, because I can't clear the float inside it. Thus the height of the OL always equals zero.//
Beside this detail, I think the only problem that remains to be addressed is the question of menu configuration. How are we to save the menu settings in Wikka configuration (currently saved as a wikka-formatted string)? A good solution might be to create a menu administration module (in form of an action with a dedicated SQL table) that allows the user to specify items that go in the menu and their order (and maybe switch on/off an optional secondary menu). This would allow more flexibility than the current systems offers (one wouldn't need to edit the configuration file) and solve the problem of how to save the menu settings. I'm taking a day off from my work, I'll se if I can cook up something''

I have been trying to modify the style sheet without success. I cannot get the footer, commentsheader and smallprint areas to align as they should. They keep flowing below the menu. Could you offer any help, please.
The code for the layout that I'm trying to achieve is like below, any help would bew much appreciated.
An example header.php with the ordered list and id tag would also help.
""<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML lang=en><HEAD><TITLE>Two columns with color - Final layout</TITLE>
<META http-equiv=content-type content="text/html; charset=iso-8859-1">
<STYLE type=text/css media=screen>
hr {
margin-left: auto;
margin-right: auto;
margin-top: 1.25em;
margin-bottom: 1.25em;
width: 100%;
height: 4px;
background-color: #6BB300;
body,html {
scrollbar-face-color: #6BB300;
scrollbar-shadow-color: #E6FFBF;
scrollbar-highlight-color: #E6FFBF;
scrollbar-3dlight-color: #E6FFBF;
scrollbar-darkshadow-color: #E6FFBF;
scrollbar-track-color: #E6FFBF;
scrollbar-arrow-color: #000033;
.highlight {
scrollbar-face-color: #6BB300;
scrollbar-shadow-color: #E6FFBF;
scrollbar-highlight-color: #E6FFBF;
scrollbar-3dlight-color: #E6FFBF;
scrollbar-darkshadow-color: #E6FFBF;
scrollbar-track-color: #E6FFBF;
scrollbar-arrow-color: #000033;
BODY {
PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; COLOR: #000; PADDING-TOP: 0px; FONT-FAMILY: georgia, times, "times new roman", serif; BACKGROUND-COLOR: #ddd
#container {
BORDER-RIGHT: #333 1px solid; BORDER-TOP: #333 1px solid; BACKGROUND-IMAGE: url(images/background.jpg); MARGIN: 1em 5%; BORDER-LEFT: #333 1px solid; BORDER-BOTTOM: #333 1px solid; BACKGROUND-REPEAT: repeat-y; BACKGROUND-COLOR: #fff
#banner {
BORDER-BOTTOM: #333 1px solid; BACKGROUND-COLOR: #6BB300
#banner H1 {
PADDING-RIGHT: 0.5em; PADDING-LEFT: 0.5em; PADDING-BOTTOM: 0.5em; MARGIN: 0px; PADDING-TOP: 0.5em
div#sitenav {float: left; width: 145px; margin-top: 0;
font-size: 14px; background-color: white;
border-right: 1px solid black;
border-bottom: 1px solid black;}
div#sitenav a {display: block; padding: 4px 8px; margin: 0;
text-decoration: none; text-align: right;
border-top: 1px solid gray; background: #E6FFBF}
div#sitenav a:hover {background: #6BB300;}
div#sitenav a:hover {color: black;}
div#sitenav a {color: #6BB300; text-align: left;}
div#sitenav h4 {background: rgb(33%,33%,33%); color: white;
text-align: center; margin: 0; padding: 0.25em 0 0.125em 0;}
#nav {
FLOAT: left; MARGIN-LEFT: 10px; WIDTH: 145px; PADDING-TOP: 1em
#nav a {display: block; padding: 4px 8px; margin: 0;
text-decoration: none; text-align: right;
border-top: 1px solid gray;}
#nav a:hover {background: #FB9;}
#nav h4 {background: rgb(33%,33%,33%); color: white;
text-align: center; margin: 0; padding: 0.25em 0 0.125em 0;}
#nav P {
MARGIN-TOP: 0px
#content {
MARGIN: 0px 2em 0px 200px; PADDING-TOP: 1em
#content H2 {
MARGIN-TOP: 0px
#footer {
CLEAR: both; PADDING-RIGHT: 1em; BORDER-TOP: #333 1px solid; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; BACKGROUND-COLOR: #E6FFBF; TEXT-ALIGN: right
#footer2 {
CLEAR: both; PADDING-RIGHT: 1em; BORDER-TOP: #333 1px solid; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; BACKGROUND-COLOR: #CCFF80; TEXT-ALIGN: right
#footer3 {
CLEAR: both; PADDING-RIGHT: 1em; BORDER-TOP: #333 1px solid; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; BACKGROUND-COLOR: #99FF00; TEXT-ALIGN: right
</STYLE>
</HEAD>
<BODY>
<DIV id=container>
<DIV id=banner>
<H1>Site name</H1></DIV>
<DIV id=sitenav>
<P><b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=HomePage">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
<b><a href="http://www.jamesmcl.co.uk/wikka/wikka.php?wakka=">Home Page</a></b>
</P></DIV>
<DIV id=content>
<H2>Page heading </H2>
<P>Ut wisi enim ad minim veniam, quis <a href="www.aol.com">Home Page</a> nostrud exerci tation ullamcorper suscipit
lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure
dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore
eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui
blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla
facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
<form>
<textarea class="highlight" rows=3 cols=45>
in hendrerit in
vulputate velit esse
molestie consequat
, vel illum dolore
eu feugiat nulla
facilisis at vero eros
et accumsan et iusto odio dign
issim qui
blandit praesent luptatum zzril delenit augue duis
</textarea>
</form></P>
<P>Ut wisi enim ad minim veniam, quis <a href="www.aol.com">Home Page</a> nostrud exerci tation ullamcorper suscipit
lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure
dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore <br><hr>
eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui
blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla
facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
</P>
<P class=nextbutton><A href="javascript:history.back()">< Back to
tutorial</A> </P></DIV>
<DIV id=footer>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV>
<DIV id=footer2>Footer stuff here </DIV></DIV></BODY></HTML>%%
--JamesMcl

and add (after ""//inserted""))

~~and add (after //inserted))~~

(see new code below)
Yes, I have read your remarks in the SB. But this is (hopefully, as i can't test it) an easy solution for the problem, as long as it isn't modified towards your suggestions.
The problem is, that there is no handling for "deletion". Instead, "strikethrough" is missused for it. To change this:
change in **formaters/wakka.php**
static $trigger_inserted = 0;
static $trigger_center = 0;
static $trigger_inserted = 0;
static $trigger_deleted = 0;
static $trigger_center = 0;
and
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_italic =$trigger_keys = 0;
to
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic =$trigger_keys = 0;
and
// strikethrough
else if ($thing == "++" || $thing == "¥¥")
{
return (++$trigger_strike % 2 ? "<span class=\"deletions\">" : "</span>");
}
to
// strikethrough
else if ($thing == "++")
{
return (++$trigger_strike % 2 ? "<span class=\"strikethrough\">" : "</span>");
}
and add (after //inserted))
// deletions
else if ($thing == ""¥¥")
{
return (++$trigger_deleted % 2 ? "<span class=\"deletions\">" : "</span>");
}

How about changing the line in **formaters/wakka.php** (shortly after ""// strikethrough"")
return (++$trigger_strike % 2 ? "<span class=\"deletions\">" : "</span>");
return (++$trigger_strike % 2 ? "<span class=\"strikethrough\">" : "</span>");
?
Could someone test it for me, please?

Of course you need a browser like [[http://mozilla.org Firefox / Mozilla]] to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].

Of course you need a brower like FireFox / Mozilla to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].

''Just give the unordered list itself an id (which indicates //which// menu it is!), and it can be "moved around the page" as desired. No need to wrap it in a div just to do that (though a div may be useful for other purposes). I agree though that **all** menus should be marked up as unordered lists and styled with CSS.
-- JavaWoman''
''Marking "a strikethrough" as "deletion" in order to get a certain rendering is just a roundabout way to go back to presentational markup instead of structural, semantic markup! The class should indicate its purpose (i.e., real clasification!); so if the purpose is "strikethrough" rather than "deletion", it should indeed be a separate class. In the CSS you then have the freedom to either style both classes the same, or to style them differently.
See also my remarks about "markup of diff pages" in the SuggestionBox!
-- JavaWoman''
(BTW, a formatter for css would be nice ;-)) - See [[http://qbnz.com/highlighter/ GeSHi!]] which several other Wikis are already using...)

~~(BTW, a formatter for css would be nice ;-)))~~

How about changing the line in **formaters/wakka.php** (shortly after ""// strikethrough"")

~~How about changing the line in **formaters/wakka.php** (shotrly after "// strikethrough")~~

How about changing the line in **formaters/wakka.php** (shotrly after "// strikethrough")
?
Could someone test it for me, please?

How about changing the lines in
**formaters/wakka.php**
// strikethrough
else if ($thing == "++" || $thing == "¥¥")
{
// strikethrough
else if ($thing == "++" || $thing == "¥¥")
{
? Could someone test it for me, please?

How about changing the lines in
**formaters/wakka.php**
// strikethrough
else if ($thing == "++" || $thing == "¥¥")
{
return (++$trigger_strike % 2 ? "<span class=\"deletions\">" : "</span>");
to
// strikethrough
else if ($thing == "++" || $thing == "¥¥")
{
return (++$trigger_strike % 2 ? "<span class=\"strikethrough\">" : "</span>");
? Could someone test it for me, please?
--NilsLindenberg (no own computer, no installed wikka :(

1) be put in a dedicated ##<DIV id="menu">## so that it can be moved around the page and its layout freely modified. See as an example this wikka site: http://www.awug.net/HomePage

~~1) be put in a dedicated ##<DIV id="menu">## so that it can be moved around the page and its layout freely modified~~

--SergiO
CategoryDevelopment

~~--SergiO~~

== A Better Horizontal Menu ==
I find that the current Wikka horizontal menu allows very limited layout control.
A well formed CSS menu should IMO:
1) be put in a dedicated ##<DIV id="menu">## so that it can be moved around the page and its layout freely modified
1) be coded as an **unordered list**. See this [[http://www.sovavsiti.cz/css/horizontal_menu.html tutorial]]
Your ideas?

**Also relevant**:
-an unofficial [[http://skins.openformats.org/wikka.php?wakka=HomePage Wikka Skin Repository]]
--SergiO

~~--SergiO~~

==Better code rendering==
I found that bits of code sometimes are rendered hard to understand, with both loss of original indents and line wrapping. The cause is 1) inheritance of the body's "justify" text alignment, and 2) the fact that lines are allowed to wrap (overflow: auto; doesn't prevent this).
My suggested solution is the following change for the code class in wikka.css:
.code {
color: black;
background: #ffffee;
border: 1px solid #888;
font: 11px "Bitstream Vera Sans Mono","Courier New", monospace;
width: 95%;
margin:auto;
padding: 3px;
text-align: left; /* override justify on body */
overflow: auto; /* allow scroll bar in case of long lines - goes together with white-space: nowrap! */
white-space: nowrap; /* prevent line wrapping */
}
(BTW, a formatter for css would be nice ;-)))
-- JavaWoman
== Alternate stylesheets ==
I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :
* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :
%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%
* in header.php this two lines just after the last link and before the "style" box :
%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%
(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Of course you need a brower like FireFox / Mozilla to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].
--SergiO

''See also my note on **markup of diff pages** in the SuggestionBox!'' -- JavaWoman
----

Wikka : WikkaCSS

Revision history for WikkaCSS

Revision [23171]

Additions:

Deletions:

Revision [19078]

Revision [16432]

Additions:

Deletions:

Revision [16406]

Additions:

Deletions:

Revision [8685]

Additions:

Deletions:

Revision [5258]

Additions:

Revision [2711]

Additions:

Revision [2709]

Additions:

Deletions:

Revision [2708]

Additions:

Revision [2705]

Additions:

Deletions:

Revision [2703]

Additions:

Revision [2686]

Additions:

Deletions:

Revision [2673]

Additions:

Revision [2642]

Additions:

Revision [2641]

Additions:

Revision [2637]

Additions:

Deletions:

Revision [2619]

Additions:

Deletions:

Revision [2617]

Additions:

Deletions:

Revision [2616]

Additions:

Deletions:

Revision [2602]

Additions:

Revision [2595]

Deletions:

Revision [2576]

Additions:

Revision [2350]

Additions:

Deletions:

Revision [2300]

Additions:

Deletions:

Revision [2203]

Additions:

Revision [2202]

Additions:

Revision [2200]

Additions:

Deletions:

Revision [2192]

Additions:

Revision [2190]

Additions:

Deletions:

Revision [2189]

Additions:

Revision [2163]

Additions:

Revision [2157]

Additions: