Please give some comments here regarding the development of the Wiki markup. But remember that we don't really want to reinvent HTML in a more cumbersome form.

Simple markup#

Why are the simple markup characters for bold (two underscores) and for italic (two ticks) two characters instead of simply one? I mean a lot of other Wikis use double brackets for links but JSPWiki uses single brackets what I regard as good, because it's less to type and the source can be read easier. IMHO it would be more intuitive to use the simpler forms that are commonly used in email communication for years: _underline_, *bold*, /italic/. Some MUAs, e.g. mozilla already display these words in the right way.

-- BorisFolgmann

I came here after doing a google search for "wiki markup font size" to find out whether any wikis had a standard for changing font size. I like the comments I read here .... they are just the sensible stuff I've missed on the Creole project which was a bit like watching old grannies (with hearing aids turned off) discussing knitting.

The first problem of a wiki markup (which is why I add this comment here) is to decide on a meta-standard for the symbols. Forget whether (...oops... how do I talk about characters for titles etc) and forget how or if to change font size, start by defining a meta-standard for which character combinations are POTENTIAL markup symbols.

Following Creole, I've decided to try and implement a standard that says:

1. Only symbols are used for markup

2. Markup requires two of more of the same symbols

3. OR a newline then another symbol

4. Markup will be relative not absolute (i.e. it does not prescribe the actual format to use, but the relative formatting. I.e. bold does not mean "use the html bold tag" but instead "this text should stand out". And indeed, the markup should be useable on almost any media from a black&white LCD to a spoken book.

But like any standard, as soon as I've decided what it is, the very first time I try to use it I realise that I personally want to put some big text on the page (it's a diary entry e.g. inviting people to a party) and hence the google search to find some kindred souls.

-- Mike

Simple markup response#

Well, I actually think we should follow what Wikipedia and Very Quick Wiki where it makes sense to do so. This is to use two ticks for em (which is styled as an i tag) and three ticks for strong (which is styled as a b tag). Two understores I would use for underline. As mentioned, it's already a convition with email. As for * for bold, it's overloading the existing use for * (lists). And slash for italics is a good idea but not needed if we do what others are doing (two ticks). But more importantly, I would generalize the parsing methods into an interface and allow admins to configure which one to used. As it stands, I am going to have to change JSP wiki to match these others for bold. On the other hand, I would never change how tables are handled in JSPWiki. I think it's great the way it is.

-- Thomas Cherry

New lines#

Can anyone explain why a single new line is ignored but two new lines are interpreted as two? I wanted to paste a long directory listing but this required me to either add explicit line breaks to every line, insert literal line breaks by hand or put triple curly braces around the whole thing and not be able to use markup within it.

If I've inserted a literal linebreak can't we assume I wanted a linebreak to appear? When would you want consecutive lines to be run together without doing it yourself?

-- James Ferguson

There are a lot of places where a paragraph is going to have newlines that survive when the paragraph text is cut'n'pasted and it is best for such a paragraph to be rendered as a paragraph not including a bunch of line-breaks. Forcing one to remove all of those line breaks after pasting the paragraph is as obnoxious as forcing you to add \\ to the end of each line of your listing.

But I propose that fixed-width rendering translate spaces to   and newlines to line breaks so that you could have "pre-formatted" blocks that include mark-up simply using something like:

{{
 Directory of [C:\]

2009-04-14 15:28         0 AUTOEXEC.BAT
2009-04-14 15:28         0 CONFIG.SYS
2009-12-01 16:47   <DIR>   __Documents and Settings__
2009-12-17 13:23   <DIR>   __Program Files__
2009-12-22 14:24   <DIR>   __WINDOWS__
               2 File(s)          0 bytes
               3 Dir(s)  12,345,678 bytes free
}}

to get:

Directory of No InterWiki reference defined in properties for Wiki called "C"!

2009-04-14 15:28         0 AUTOEXEC.BAT
2009-04-14 15:28         0 CONFIG.SYS
2009-12-01 16:47   <DIR>   Documents and Settings
2009-12-17 13:23   <DIR>   Program Files
2009-12-22 14:24   <DIR>   WINDOWS
              2 File(s)          0 bytes
              3 Dir(s)  12,345,678 bytes free

-- Tye McQueen (2010-01-05)


Escaping Characters#

Is there a way to escape markup characters other than code blocks (ie. triple curly braces) these start a new paragraph and often I want to escape characters within a single paragraph. Eg. if I want to refer to a Windows share I'd like to begin with double backslashes but can't do this without beginning a code block. Any comments?

-- James Ferguson

Use a ~ character. For example \\host\share. --KieronWilkinson

Cleaner table syntax#

The current table syntax is horrific to look at in the edit mode. It's just unmaintainable with big tables. There must be some cleaner way of defining tables, or tabular content, maybe something that would not mind linebreaks. For example, to produce the following table, below are the current and proposed ways:

Heading 1heading 2heading 3heading 4
First row, first columnsecond columnthird columnfour column, which is very long, but still cannot be split on multiple rows

Current way:

||Heading 1||heading 2||heading 3||heading 4
|First row, first column|second column|third column|four column, which is very long, 
but still cannot be split on multiple rows

Proposal:

||Heading 1
  ||heading 2
  ||heading 3
  ||heading 4
|First row, first column
  |second column
  |third column
  |fourth column, which is very long, but still cannot be split on multiple rows. 
   But now it can.

-- Heikki


Add my vote for cleaner table syntax. I want to be able to have line breaks within a cell as well so that I can do something like:
||This could be a lot of text\\
  for just one cell||
Currently this renders as:
This could be a lot of text
for just one cell.||
Also some means to set the table, row, and cell attributes to get better formatting.
-- JtBell

For formatting see also Aligning text within table cells.

You can include forced line breaks in table cells like so:

||This could be a lot of text\\for just one cell
which renders as:
This could be a lot of text
for just one cell
-- MortenHattesen

Centering and right-aligning in tables#

HowToAlignTextInTableCells seems a good example of "re-inventing HTML in a more cumbersome form". Here is a proposal that borrows from other wiki table layout schemes but is pretty backward compatable with JSPWiki table formatting.

It seems common to want to center or right-align text in parts of tables. In other wikis, this is possible by just adding additional whitespace. To right-align, put at least 3 spaces in front of a cell's contents and no more than 1 space behind. To center, put at least 3 spaces at front and behind. For example, the following:

|| Name ||   Score || Position ||
|   Some Are Long   |   3,771,456 | L |
|        Ed         |           3 |     R |
|      Melissa      |     n/a     |   C   |

would render like the following:

Name Score Position
Some Are Long 3,771,456 L
Ed 3 R
Melissa n/a C

This also motivates the improvement of ignoring trailing vertical bars so that the trailing spaces can be easily noticed (without adding a blank cell on the end).

Another improvement would be to translate spaces to &nbsp; when inside a fix-width font span, {{...}}, which would provide a relatively easy way to simulate center-/right-alignment or even other types / combinations of alignment.

I also support ignoring literal newlines, but via a trailing single tilde (~) on the line, so tables can be more cleanly defined. I think I've seen more than one proposal for a trailing \\ to cause the newline to be ignored, but I think that is a confusing idea as can be seen by MortenHattesen perhaps misunderstanding JtBell's proposal above.

For example:

||Author||Text
|Fred|This could be a lot of text ~
  for just one cell ~
  and I don't want to run ~
  it all together on one line ~
  in the wiki source edit box ~
  nor do I want to force line ~
  breaks in the rendered table

Should be rendered as:

AuthorText
FredThis could be a lot of text for just one cell and I don't want to run it all together on one line in the wiki source edit box nor do I want to force line breaks in the rendered table

And tables could be entered as:

||Heading 1 ~
  ||heading 2 ~
  ||heading 3 ~
  ||heading 4 ~
|First row, first column ~
  |second column ~
  |third column ~
  |fourth column, which is very long, but still cannot be split on multiple rows. ~
   But now it can.

with less need for the parser to look ahead.

Minor gotcha when combining these feature ideas: the leading spaces on a line after a ~-escaped newline should be ignored. So

|   Right ~
   |   Centered   ~
   | Left |

would right-justify text in the first cell, not center it.

-- Tye McQueen (2010-01-05)


Syntax Highlighting for Languages (i.e. Java) - December 4, 2003#

I'd love to see the ability to do automatic syntax highlighting of code in the wiki. HTML and Java support would be ideal. I've always thought this would be great, but didn't think it was possible. But then I saw that VeryQuickWiki has this - example. If you click on "Edit Page" at the bottom, you can see the author simply has to wrap the code with [<java>] code goes here [</java>].

Maybe Java2HtmlPlugin is what you need? --TomZ
That's exactly what I was looking for - thanks Tom! It would be nice to control the HTML (i.e. so everything's not centered, but I can probably figure something out with CSS (i.e. center table {width: 100%}) -- Matt

-- MattRaible


Undefined pages flag#

Instead of putting a ? next to an undefined page reference (which can get really distracting and messy if there are many of them in the same paragraph) it would be a neat idea to take advantage of CSS's ability to change the mouse cursor to the "help" version. This way, when flying over the missing page reference, the mouse cursor would show that it doesn't exist, a more subtle hint. As a result, if you go and make a bunch of antipcated page references, it doesn't affect the flow of the page so much.

-- Dan Allen, 2003-07-04


Code section handler configurable#

A bit similar to "Generic DIV tag support" below, I think it would be beneficial to allow something like { { {=java ... }}} as an alias for a plugin call with the contents of the code-block passed like the body of a plugin. Which Plugin is responsible for which language should be configurable in the properties file.

-- Torsten, 2003-03-02


Generic DIV tag support#

Refactored to CSSInWikipages.


2003-01-15 -- Adding now text format option: Struck (strike) thru text#

I have a situation at work where it would be helpfull to have the ability to make text in a table appear struck thru. Quite simply I need to be able to make things look like they are completed / cancelled or pending deletion.

STRIKE is a valid html markup (http://www.w3.org/TR/html4/present/graphics.html#edef-STRIKE) though it is now marked for depreciation in the html4.01 spec. It appears to have become "line-through" in the ccs1 spec as a text decoration (5.?.3 and 16.3 in the CCS2 spec).

I had been thinking that the would be the character I would use for this formatting option i.e "~some text~" as it doesn't tend to be something that is generally used. Certainly the only time I would use it is to say that something is roughly equal (~=).

I am quite happy to add this myself, I have the source checked out but I would like to ask others for thoughts?

-- RobertMcGovern

We already use '' as a generic "do not process the following directive" sign, so there is a possibility of confusion here. For example ThisIsNotALink, where stops CamelCase.

We're fast running out of candidates, though :-).

It might not be a bad idea to have the markup result in a <span> element: <span class="strikethrough">some text</span> instead of using a deprecated element.

-- JanneJalkanen

Hmmm, how easy is it for people to generate a ¬ (uk keyboard: shift + key to left of 1).

As to the using <span>, it makes sense I suppose. I need to read a little more on it mainly on how supported will it be for older browsers?

-- RobertMcGovern

How about '--' for strike-out? To avoid normal uses of '--', the rule would be that strike only applies when the test surrounded by -- doesn't contain any spaces. So if you want to see strike-out for phrases, you changes spaces to hyphens. For example,

struck not-struck
--exercise-- --so long.
--take-out-the-garbage-- --as far as I know--

--Daggerbox 2003-12-01


2003-01-13 -- Definition List behavior consistent with other lists#

I noticed that definition lists behave a bit different from ordered and unordered lists, which is probably unnecessary.

  • definition description can't span multiple lines (i.e. continue the item on the next line by putting a space in the first line)
  • no multiple levels

I would like to have the current syntax enhanced a little to allow something like:

* foo
*# bar
*#;Test: description
 this continues description for Test
*#;;subtest : sub-definition list for Test
I admit, this looks a bit wired at first, but reflects the logical structure (and later presentation) better than the current
* foo
## bar
;;;Test: not possible
 impossible description for Test


though not preventing it.

-- Torsten

Well, yes. Definition lists should be allowed to continue over several lines, I agree. However, nested definition lists... I am not entirely sure whether they are a good thing. They would at least encourage threaded conversations, which is probably not a good thing in Wikis. :-)

--JanneJalkanen


Dec 5, 2002 -- Enhanced Tables#

PikiePikie has some advanced table syntax. The features I find particularly useful are:

  • Column spanning
  • Table width control
  • Cell alignment
  • Table border size

I include the last because I like to use tables to format the display of text and graphics and find that it is often cleaner and easier to read without borders.

On our wiki we maintain and periodically update status info in tables, some quite large. We use a simple, low tech method to maintain the wiki tables, which is painful to do in raw text. For ease of entry, we use Excel spreadsheets with embedded wiki formatting characters, which a publishing macro saves as a text files in the wiki files folder. (If anyone would find this useful, let me know and I'll provide a sample.)

The details of the PikiePikie table syntax would clutter up this page; the info can be found on my personal page.

-- PaulDownes


Keeping structure and presentation separate.#

October 11, 2002

I think, that it must be possible to make some text center aligned. --Mortena

Shouldn't wiki markup keep structure and presentation separate? Think about the mess html became because it didn't do so, and how hard it has been to remedy that. Wikis, or at leas JSPWiki should avoid that.

My suggestion is that JSPWiki should strive to produce validated XHTML 1.1, for example. Just pick a subset of the html tags to use, such as h1, h2, h3, em, strong, table, div, ol, ul, li span,etc..; decide what the corresponding wiki tags will be, and let presentation be handled through style sheets. If more control is needed, then come up with a wiki markup extension to assign class attributes to the tags, perhaps something along these lines:

!toc-title: This is a the table of contents header
which would then render to the following html:
<h1 class="toc-title">This is a the table of contents header</h1>
then you could have the following in your style sheet:
h1.toc-title: { text-align: center; }

This would, I believe, allow much greater control to wiki masters and users, and would still keep the wiki markup from getting out of control.

It could even be possible to come with WikiStyleSheets, which would simplify stylesheets in the same way that wiki markup simplifies html.

Hmm, got to run. What do you all think?

--VictorRodriguez


Linear, moderate hypertext--the scrolling page with hyperlinked subheadings#

Sept 17, 2002

To do this in JSPWiki we need just one more thing:

  • support for named anchors within a page. So I can write a link that jumps to an anchor within the same page

Can I do this already?

Yep. Use footnotes. You'll just need to modify the default stylesheet to display them as something else as footnotes, though. --JanneJalkanen

A nice-to-have would be some sort of support for quick TOC production on all heading levels.

Note that this goes against the Wiki principle of keeping the pages short, and concerned about one topic only. If your page gets so long that you actually need to build a TOC, then you probably need to refactor that page into multiple pages. --JanneJalkanen

OK, buckled in under the pressure. From 2.1.78 all headings define a named anchor within a page. --JanneJalkanen

Thanks!

Defining links inside pages#

How about an ability to define alternate hyperlinks on pages - sort of shortcuts. For example, by writing something like this on a page:

{AlternateLink:Development}

Would cause the WikiEngine to consider all references to Development to refer

to this page. This is already sort of implemented (through page aliases, see SystemInfo for an example - it actually points to a JSP page instead of a Wiki page), but it's configurable only through a property file, to which users have no access, of course.

Oh yeah, take a look at Manila. It's a commercial application, but looks very, very good.

This feature is available in 2.1: You can just do a [{SET alias='Page'}] to define a page alias.

Underlines#

Almost all text exitors support underlining but I don't know it is really needed. -- Asser

Currently the NonexistantLinks are underlined to show that they are links, they just don't exist. I think adding underlining would confuse this, so we would either need to change the way the links are shown, or forget underlining. --Janne

Good point - I am happy to live without underlinings :) -- Asser

They only reason underlining exists is that when manuscripts were written in longhand, it was the standard, unambiguous way for an author to indicate which passages should be italicized. Underlining should never be seen in print. -- AlexCruise

Looks like TWiki has done away with underlining non-existant pages and has moved to high-lighting it instead with: <span style='background : #FFFFCE;'>. Seems to be a good pattern. -- JeffPhillips

Emphasis, Strong#

<EM>, <STRONG>
: I don't think we need this, since they are already represented by bold and italic.

Maybe we can create our own emphasize tag using a red color for example (I think we all hate those <BLINK> things and they are not HTML anyway). Sometimes it realy makes sense to emphasize something big time. This thing can be used for warnings and some extremely important and short notices within a longer text. -- Asser

Perhaps a simple ==text== for important, ===text=== for more important, ====text==== for even more important... The headings are currently handled in a similar way. Or be could just continue using the _ and ' marks for added effect. --Janne

Yes, that is a good notation. What about the implementation? Different colors for different levels? -- Asser

Colors don't really fit in with the KISS principle. Clutter and confusion. I'd say we should keep it to just one color, and use even that sparingly. -- ebu

Then again, the nature of Wiki allows anyone to remove offending text or formatting... Here's an idea (I'm using $$, because == might be confused with Java conventions):

  • $$text$$ prints text in some dark color, almost close to black.
  • $$$text$$$ prints text in some bright color (such as red).
  • $$$$text$$$$ prints text in larger letters
  • $$$$$text$$$$$ prints text in bright color, larger letters
  • $$$$$$text$$$$$$ starts a new line, centers text, and uses bright color, large letters (this could be used for really important alerts on the main page.)
  • $$$$$$$text$$$$$$$ starts a huge party (to which you're not invited), calls the police, paints your dog yellow and passes out in your kitchen.

Comments? --Janne

I vote for all these new features but my dog just bite me and told that she is voting agains the last extension but agrees with the others. --Asser

No longer an issue, since in 2.1.38+ you can defined your own styles at will. --JanneJalkanen

teletype, preformatted, code, ars#

<TT>,<PRE>,<CODE>,<VAR>

We probably do want something like this to represent things like Java classes. How about double double quotes (""text"") or triple single quotes? How about a variation of the text theme? This would be logical because you use three braces to start a block of preformatted text.

<CODE> and <VAR> might be useless as long as we have <PRE> and <TT> tags, respectively. <TT> is definitely something that we need ASAP. <TT> does not add any line breaks and can be used within the text. -- Asser

As of JSPWiki 1.1.0, the <TT> tag is supported with by using two consecutive braces. --Janne

Superscript a,d Subscript#

<SUP>,<SUB>

Superscript and subscript are probably useful if you're talking about things mathematical. Any ideas? Perhaps use a variation of the TeX ^ and _?

That would be neat at least. -- Asser

Figuring out how the delimiters work is hard... Any ideas? Ah, but how about ^^text^^ is superscript and something else is subscript? ^^^? What is logical? Is subscript really needed? --Janne

Well, ^^superscript^^ is quite intuitive. It's a pitty there isn't and upside-down caret on the keyboard. How about ^_subscript_^? By the way, if you're trying to write mathematical text, you really need both! -- YishayMor

Here is a hack for superscript... to write "order n squared" in my Computer Science notes, I used: O(n2).

The markup looks like this:

O(n%%(position: relative; top: -0.8em; font-size: 0.8em;)2%%)

A bit ugly, so I am very much in favor of something like O(n^^2^^) as an alternative. -- pconrad

More wiki-ish approach would be O(n2)

O(n%%sup 2%%)

Font markup#

Probably not. <FONT> is deprecated in HTML 4.01, and can be easily used to destroy the browser-independence of Wiki.

I personally think monospaced, serif and sans-serif are both necessary and sufficient. -- ebu

For the monospaced fonts please join our discussion about <TT> and <PRE> tags. -- Asser

Block-quote#

<BLOCKQUOTE>

Well, we might need some sort of a way to emphasise replies and comments. BLOCKQUOTE might work, but I'm not certain. Any other ideas?

At the moment you can write:

> ...quotations within { { {-blocks but
> this means that you will have to use your
> own greater than signs and more over this
> is something quite different from HTML
> <BLOCKQUOTE>, which usually indents the text
> and encloses it with quotation marks.
-- Asser

Span, Div#

<SPAN>, <DIV>

GamesBook: Perhaps its just my current Cocoon conditioning around the separation of style/appearance from logic from content, but I would say a relatively simple fix for most of the above requirements is to allow for the creation of <span> and <div> tags that support a class attribute. That way the site designer has precise control over how elements appear, and user can decide what text must look like what... I am not sure what syntax/notation one could use in Wiki to indicate this, as I do not have enough experience of the language.

No longer an issue, since in 2.1.38+ you can defined your own styles at will. I will support <span> as soon as I figure out how =) --JanneJalkanen

Allowing Raw HTML#

Discussion moved to AllowingRawHTML.

Links within code blocks#

sj: Code blocks are great in current jsp wiki, my only complaint is that to use links inside the code block. I use this jsp wiki to write pseudo rules for one of the configuration engine we are developing. These rules are edited by many people in our organizaiton. So for references inside a code block to show that it has been written some where I would like to use links. Here is a example.

ForEachTopology:
     if [TotalPortsAvailableOnTopology] is atleast equal to [PortsRequired] then
               addTo:validTopologiesList
Above TotalPortsAvailableOnTopology is calculated else where, and also PortsRequried

And yes, KISS, as much as possible. Under the current markup things that I like are headings, lists and horizontal ruler. Any thing that has more than one character to indicate its markup is an overkill, I think an editor(one who edits) should be able to understand the text even in editing mode and having markups in between reduces his chances of understanding and attempting to edit other author contributions.

JanneJalkanen: Ah yes, I totally forgot about this. My bad. Sorry. 1.6.11-beta should fix this problem. :-) Go to JSPWikiDownload to get it.

sj: 1.6.11-beta did not fix it, links are being recognized in the first line of the code markup not in the second line. Ex:

    [ThisIsRecognized]
[ThisIsNot]

No, that's a bug. The first line should not be recognized as a link.

However, try this:

if( Main ) gosomewhereelse else Go edit Sandbox

Note just two braces. Three braces is still "copy everything verbatim". Two braces is "format as usual, but please use TT.

Aw. I just recognized the mistake in my ways. You lose indentations.

Anyway, it's really difficult to do links inside pre-blocks, since in normal source code you have things like String[] myArray , which will show incorrect.

sj: May be for normal code we can use escape sequence link Array[].And I think in your example you have used monospaced font markup instead of the code markup, may thats the reason why its loosing the indentations.Hai and the new caching provider is great its lightening fast!.

JanneJalkanen: Yes, yes. I was confused. Sorry.

JanneJalkanen: Okay, how's about: Four consecutive braces make things preformatted, but retain links? It's not beautifully hierarchical, but I think it would work.

No longer an issue, since in 2.1.38+ you can defined your own styles at will. For example, you could use:

%%( white-space: pre )
public class MyClass
{
   ...
}
%%
which would have all of the whitespace intact, but WikiMarkup would still be expanded.

--JanneJalkanen

Comments in Wiki code#

RobertMcGovern : Thinking out loud, would it be possible to add tags, that when applied around a word, the word wouldn't be rendered in the HTML version of the page. Essentially a comment tag. This way when people add their email address to this page, they are only available in the editable version + version available via RPC? This would stop an possibilty of a web spider getting the email address ... okay till they make them smarter. It would also make it slightly more natural to enter the email address onto this page.

JanneJalkanen : For the purpose you outline, I don't think so. Each page contains a link to the "Edit" page, and each Edit page would then have the emails available. Of course, you can state that robots are not supposed to reap those files (using the robot exclusion standard, but I don't believe that this would mean an inkling to any dedicated email harvesting spambot.

Since 2.1.38 you could say:

%%( display:none )
My comments
%%

-- JanneJalkanen

Coloured text in Wiki code#

It would be nice if you could implement a possibility to colour some text in a wiki code block.

-- Marcel

Robots Plugin#

Heinz-Josef Lücking: Wouldn't it be a good idea to use the content/code of the index for generating a starting index.html (or default.htm etc...) as a starting file for the/a wiki too make the content of a wiki available to search engines. This file could redirect the users to the "real" wiki.

I'm sorry, I don't understand. Wiki content is already available to search engines, try Google:JSPWiki if you don't believe me... =) --JanneJalkanen

Sub-sections within page#

It would be nice to be able to divide the page into different sections that can then be displayed in different places by the JSP template.

I have hacked this at the JavaSWF Wiki by post-processing the page html in the JSP and recognizing left{ ..content.. } to be the left part and right{ ..content.. } to be the right part. Everything else is in the main page body.

-- Some unknown person

If I understand you correctly, thus should be quite possible with the generic style support described above. You'll need to do the whole thing in CSS, but yeah, you should be able to do stuff like floating menus on pages, redefining layout, etc.

-- JanneJalkanen

Multiple levels of indentation#

One thing I find lacking here is the ability to indent paragraphs multiple levels deep. UseMod does this by using the semicolon. Each : represents a level of indentation. This is especially helpful in discussion ThreadMode. -- MatthewSimpson

I've just encountered this, too. I needed to indent some lines of text, but I can't find a way to do it. I might go create an "indent" invisible GIF that I can insert, but that seems very hackish. Any thoughts here? --MichaelGentry

2.1 allows you to do the following:

%%(indent:2em)
Indented text
%%(indent:4em)
More indentation
%%
%%

But perhaps we should consider extending the ; -notation for multiple indentation levels.

-- JanneJalkanen

OK, between JohnVolkar wanting my template to work with 2.1.x and this feature, maybe it's time I consider upgrading ... living on the bleeding edge! Also, I think UseMod uses a ":" at the beginning of the line to control indents (more ":"'s = more indentation). That seems reasonable enough to me, too. Especially if a \: or ~: would escape it.

Thanks!

--MichaelGentry

In an out-of-the-box installation, I didn't have any luck with the example above, but the examples in HowToIndentText did work.

-- RaganHaggard


HTML to JSPWiki Markup convertor#

Are there any tools available that convert/translate HTML markup into JSPWiki markup?

I want to set up a JSPWiki website internally for the purposes of creating, collaborating, and maintaining software specification documents e.g. functional specs, design specs. etc.

We currently have a sizable set of specs. and spec. templates already in existence in HMTL format. I need a way to quickly convert these into compliant JSPWiki format for instant incorporation into the website? -- GarryCronin

AFAIK no, but this is a wonderful idea. I've been thinking about a XHTML -> WikiMarkup converter, as that would solve many issues for InterWiki compatibility. And you can easily get XHTML from HTML via HtmlTidy for example.

--JanneJalkanen

I think the main issue with InterWiki compatability is that it's difficult for users to remember all the slight variations in syntax all the different Wiki Engines use. In the medium (and maybe even long) term it's reasonable to expect that JSPWiki won't be as widely adopted as e.g. MoinMoin or MediaWiki. Given that's what users know it therefore slows JSPWiki's adoption to not support their WikiMarkup (even if JSPWiki's is arguably more intuitive). So I'm more interested in converting from those markups than I am in converting from the HTML those Wikis render. --LorrinNelson


Hey y'all. I've updated the MeatBall:WikiSyntax list with a view to move towards a MeatBall:WikiParserModel, and then a workable MeatBall:WikiInterchangeFormat (a MeatBall:WikiMarkupStandard is not a good idea). The TikiWiki guys are trying to put together an RFC for wiki markup for the IETF, so it looks like the pressure is on to finally do something. Please come over, add whatever you think is needed, like missing syntax, parser theory, algorithms, best practices, refactoring, etc. -- SunirShah


CSS markup not possible for inline text.#

Currenty, JSPWiki supports only CSS markup for blocks of text. The means that today it is impossible to change the style of one word or a part of a paragraph. The percent markup is always rendered to a <div> and not into a <span> element.

An obvious markup would be to use 2 percent signs for inline css, and 3 percent signs for block css. (as is done with the curly braces markup ). Unfortunately, this would not be compatible with the current approach.

Another approach would be to decide between <span> or <div> based on the surrounding text; similar to the decision whether some text still belongs to a paragraph or not.

--DF

Actually, it is possible to change the style of one word or a part of paragraph using the percent markup, adding display: inline; to style definition. Requires some tweaking when inside <p> </p> though.
--MinusDee

It does work with the current setup like so: %%(color:red)Check this out.%%, which renders as Check this out.
CSS markup is now possible without the "display:inline" -hack. --JanneJalkanen

CategoryIdeas


Wiki Text Format-Table Format Suggestion#

For the table formatting, I suggest keeping the edit text in comma separated format. This way, one could use a spread sheet program to maintain the table, and export it as a .cvs file. This may not make the edit text more readable, but I think you would want to maintain a large table in a spreadsheet anyway. The cvs format text would look like this in the Wiki:

head1,head2,head3,head4
1-1,1-2,1-3,1-4
2-1,2-2,2-3,2-4
3-1,3-2,3-3,3-4

--AnonymousNewbie, 08-Dec-2006


RDF statement in JSPWiki WikiPage#

  • By reusing the definition markup
  • and by extending the InterWiki reference to namespace
JSPWiki could present RDF statements
[Old_MacDonald];[foaf:Person]
[Old_MacDonald];[myOntology:have]|[Farm]

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-161) was last changed on 03-Jul-2012 19:09 by 194.168.223.147