(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.


It seems to be against several goals of Creole. There is already a markup similar to this proposal, less verbose, with end tags which can be recognized easily, standard and very popular: XML. Since Creole doesn't use single angle brackets, it would be easy to mix both.

We're soon going to have assigned a meaning to all double punctuation signs, so Creole won't be much more complicated than it is now. I'd suggest to reserve $$ for LaTeX math, __ for underlined, -- for deleted text and ++ and %% for future uses (all optional), and we're done. Both !! and ?? are too frequent in plain text to be safe.

-- YvesPiguet, 2007-Apr-2

As far as I know, XML is a general markup language, not a set of text formatting rules. You surely mean HTML or XHMTL or one of the other text-formatting SGML/XML derivatives :)

I'd say that "--" is also too frequent in text to use it for markup, so while it fits so fine semantically with "deleted" and visually with "strike trough", it is better avoided -- see the discussions in HyphenListMarkupProposal. You can always use things like "[-foo-]" of course, but we are just making a poor reimplementation of HTML and friends this way.

-- Radomir Dopieralski, 2007-Apr-03

XML: yes, anything more or less based on SGML, XML or SML would be better than underscores, and this should be left outside Creole Core.

Double hyphens: I thought the same quickly after posting, but I didn't want to hide my point with a minor edit.

-- YvesPiguet, 2007-Apr-03

I agree that it looks like a poor reimplementation of HTML. I think what you have in mind, Gregor, is something like the %% markup element in JSPWiki you can use to "extend" the markup by simply defining div tags in the css file and use the tag names in combination with the %% element. The comment boxes in this wiki are an example of this:


This text is displayed in a gray comment box on the right hand side

You can also use css directly to make a text red


Unfortunately I think this collides with the rule of NotNew. It only makes sense to create a common element if a lot of wikis are using similar functionality. I don't know if other engines have this functionality, but I guess it's quite rare. So first of all we would have to find out how many engines are using it already.

Therefore I reject this proposal, unless you prove that it is quite common.

--ChristophSauer, 2007-Apr-03

I probably have expressed myself poorly, but I would like one more try. I think some of the response actually show my point: Yves is proposing a large number of double-punctuation signs, some of which would conflict with existing markup, or appear rather frequently in wiki content. This is the kind of extension that only works with new content, but introduces incompatibility with old content. And, sorry, no, you cannot simply use xhtml, unless we start in Creole by specifying the all occurrence of single angle brackets in the content must be escaped. People will discuss how to format their html pages on a wiki, so the advice: use "use <em>emphasis</em> for..." is content, not markup.

To rephrase my point: Can we provide a good basis that can be used by wiki-engines to integrate the markup-features they desire to support?

This is user-driven, not programmer-driven. Most people here seem to be programmers, so they think that monospace and perhaps code-highlighting is incredibly important. I don't care, but I wish that the Wiki engine may support their needs. For my biological users, italics in parts of a link or heading (formatting only the scientific organism name, being only part of the link or heading), and super- and subscript are incredibly important. Then we have underline, math, inserted, deleted, CSS-support. We already discussed in passing the need to define a non-breaking space. And on wikimatrix I further find: Aligning text, Text indentation, and definition lists as further wiki-supported formatting. That is eleven more formatting commands than Creole currently supports. I cannot see why the need to support richer formatting than current Creole collides with the NotNew rule... Supporting more formatting than Creole 0.6 is indeed quite common.

My point is that by some method (which may be different than what the proposal illustrates) I believe it to be highly beneficial if the structure of Creole is such that after the first tier of frequently used formatting, being represented by very simple formatting commands, a second tier comes that is flexible enough to be used both for Creole internal purposes (I still hope for superscript/subscript...) and for the formatting extensions Wiki-software desires to support. The CSS support of JSPWiki is just one example, not the purpose of the proposal.

Realising that html will be discussed a lot on wikis, I proposed using a html-analogue to avoid the issues of having to escape each and every occurrence of a greater than/smaller than character (as you have to do on Wikis using xhtml markup for exactly the extensibility purpose, like TWiki).

However, if there is agreement to reserver simple greater/smaller sign as wiki-markup this would just as well serve the purpose of this proposal. Again, as (at least) TWiki and MediaWiki show, using extensible markup is NotNew.

The proposal is about the structure or creole, not about using specific characters to achieve the extensibility. The Creole grammar structure that is proposed is an alternative to Yves proposal to add yet another n (I count 11 already!) double punctuation signs...

--Gregor Hagedorn, 2007-Apr-04

Gregor, I agree with you that we need either this, or one of the other things you proposed. Currently I'm in favor of the GenericExtensionElementProposal, but that may be just because it was discussed best so far.

Now, to address your needs, I see several problems and several possible solutions -- these are to start the discussion, not to counter your arguments, mind you. Also note, that there is already Superscript And Subscript Proposal and that it will likely be included in Creole Additions.

The problem with advanced formatting in links and page names: URLs don't support it! They do support the Unicode alternatives I mentioned in the Talk.SuperscriptAndSubscriptProposal, at least when the engine uses UTF-8. So, Creole would have to specify an algorithm for encoding this formatting into URLs -- which is out of the Creole scope and poses an additional problem, as not all wiki engines allow the same set of characters in their page names, due to either design decisions or implementation of their storage (think C2). Note how the original wiki swiftly sidesteps this problem by spelling out any advanced markup in page names (CeePlusPlus).

Another problem with advanced formatting -- it's going to be, by necessity, quite elaborate. I doubt your users will me happy writing 2m__sup__2__sup__, and I'm pretty much sure they won't be happy reading it. Using Unicode (with some nice way of enabling the users to enter it comfortably in the engine, like buttons or even just a list of them for copy-pasting) is the most readable and portable way. Using a LaTeX-like plugin (not necessarily LaTeX, it may render to normal HTML and use even simplier syntax, custom-crafted for the purpose) is a second-in-order comfortable option, at least in my opinion and limited experience. Compare:


Lastly, things like text alignment, floating of elements, spacing, colors, etc. are the domain of web designers and are best accomplished using styles and style sheets. Sure, a way of inserting a classed div or span would be then handy, but that's hardly core wiki syntax.

-- Radomir Dopieralski, 2007-Apr-05

Re: "The problem with advanced formatting in links and page names: URLs don't support it!"

My apologies: I mean in the link display text, not in technical page name. What my community needs need is "Synonyms: [[Abies_alba_var._alba L.|//Abies alba// subsp. /alba// L.". In biology, the Genus names and epithets MUST be italics, but not the rank or the author name. There is a single page for this subspecies, and using the name to link to it is natural. But the display of the link inside a paragraph must be formatted.

I agree about my proposal being poorly readable, but I find the original super/subscript with specific Creole just as bad. Unfortunately, Unicode has only very few super/subscript characters; I believe it is not a solution to super/subscripting. I still counted 11 more formatting proposals...

Perhaps we should forget the proposal to use html-like syntax, perhaps indeed what we need is CSS support. My major point was that currently Wiki engines support a lot more than is in Creole, and I hate having to use a mixed mode with 11 more reserved characters for the native-wiki extensions. Open up a structured way in Creole to let Wiki-developers extend their formatting, and I am happy. And perhaps, start using the same methods for the medium-important formatting issues - in my mind that includes monospace formatting, so I think this proposal is timely...

--Gregor Hagedorn, 2007-Apr-11

How about using a special plugin custom-written for the specific use case, giving you a way to achieve desired markup easily:

<<chem c2h5oh>>
the plugin would know how to format the text -- simply from the context, and would output
<span class="chem">C<sub>2</sub>H<sub>5</sub>OH</span>
or maybe even with colors to highlight important details. Note how the raw source is still readable. The text is also easily readable on wikis that don't have this plugin installed -- just not as nice.

I think this is the way to go when a wiki community has some special needs -- making the wiki markup universal also makes it complicated and unreadable. It is so simple just because it is small.

Then again, there is nothing wrong with extending Creole -- it was meant to be just a small common subset of most important things, to ease transition between wikis -- not a complete wiki markup with all bells and whistles that any wiki engine can have.

-- Radomir Dopieralski, 2007-Apr-11

I don't mind having such a custom plugin, but it is not very general and does not solve most problems. I believe there should be a general solution. The real problems to me are the variable names that include subscripts/superscripts, including letters.

I don't mind if the solution is a bit more complicated than normal markup. There is a huge difference between not possible using very simple markup, and not possible at all. Not possible at all means I get the mail from content authors how to do it, and if I cannot offer them a solution they walk away. I don't believe they will walk away if I can tell them: well, it is a bit complicated, but here you go. The JSPWiki CSS extensibility is a great thing in this respect, and it would be enough to cover super/subscript, monospace, etc.

--Gregor Hagedorn, 2007-Apr-11

There are already general markups for solving anything that can be solved automatically -- they are called "programming languages", but somehow not everyone loves them. Wonder why.

Creating a Creole extension that makes use of CSS (or LaTeX, or Perl, or Assembler) should be pretty simple, and the use of such an extension (or addition, or plugin, or snapin, or macro) would be trivial for anyone who already knows these languages. Then again, anyone who doesn't know them would have to learn all of them at once to be able to edit Creole-based wikis.

As long as you use specific solutions for exactly the problem you have -- and exactly when you have the problem -- you have pretty good chances of keeping things simple, or at least on a manageable level of complexity. As soon as you devise a general and universal solution to all problems you might ever anticipate: you are in trouble.

Consider this user story: Suppose that Creole includes some markup that allows users to include CSS on the pages. Suppose also, that you have a CSS wizard on your wiki, a guy who breathes HTML tags, who can do incredible magic -- that even renders correctly in MSIE. Obviously, this lad will (ab)use the CSS capabilities to "enhance" the looks of all pages he edits. Obviously, he will use hist style-fu to help other users -- by correcting their clumsy attempts or answering their questions about "how to do this". Of course, most of the tricks will force the wiki site to never change its general looks, as it would break all the pages -- but that's a small price for... flexibility? Never mind that.

It is obvious that as soon as you include any feature in your wiki, there will be some users who will be using it, and declaring it "for special purposes only" won't help.

Now, imagine that the guy leaves for some reason. Maybe it's just long vacation, maybe he gets bored of the site, maybe the real life strikes and he no longer has so much time. Anyways, he's gone, and the wiki community is left by a mass of some arcane code they don't understand. Any attempt at editing or reusing it results in strange, unpredictable results. The new generation of browsers that comes in the mean time doesn't interpret the css-tricks correctly anymore either. Of course, you can fix the site's style globally, but you'd have to still hunt and replace all the little code snippets your users typed to get the symbol for empty set rendered nicely.

Yes, I am exaggerating. No, I don't think that Creole should include html, css, latex, csv or bnf in the core standard. Yes, I've seen this scenario I described happen (not exactly on a wiki though). No, I don't think I'm going to convince you here and now. I'm not convinced myself. I know that there lies insanity in this direction, but I'm not sure the opposite direction is sane -- I guess we have to go and see, because just sitting there won't help much.

I hope you're enjoing these rants as much as I do :)

-- Radomir Dopieralski, 2007-Apr-11

Sure I enjoy goofing to this! I take the point Radomir, and no, I don't want all of html, css, latex, whatever. I feel wary about what may happen with allowing all of CSS. However, using JSPWiki, it has not caused trouble so far, whereas allowing html has caused such trouble.

I hate the 95-ASCII-character-which-can-we-double-to-get-the-next-bit-of-required-formatting approach (Hints On Extending). I believe this creates a mess in regard to the complexity of escaping and de-escaping content, and I believe it creates a mess for content authors who will have a very steep and long learning curve.

I know my users need to markup super/subscript generically. The computer programmers here want to have some markup for code (monospace). The next real stumbling block for content authors seems to be the usually inadequate table support. I get very dissatisfied responses about this (especially lack of cell spanning in JSPWiki). This wiki makes a lot of use of CSS floating comment boxes... I can imagine a need for inserted/deleted - but in my user community. But that is about it - for me. But every community may need a bit more.

Where is the compromise?

I am looking for some extensible method that Creole may already use for the lesser important formatting issues, which are still considered important enough to be generalized. Doing so will actually make Creole easier, not more difficult. It will create layers: Most important markup, secondary Creole markup, software-specific formatting extensions. I suggest opening a path for software specific extensions in a creole-only syntax, that allow secondary Creole markup and software-specific formatting extensions to coexist.

That was my original proposal, and I got charged or reinventing the wheel. You say that using the wheel is silly and gets us into trouble. I tend to agree... Could we suggest only a limited number of second level formatting constructs, but use CSS syntax for those?

What do you propose? Do you think that Hints On Extending is the best approach?

PS. There is a big difference between you and me. "Creating a Creole extension that makes use of CSS (or LaTeX, or Perl, or Assembler) should be pretty simple" -- no, it is impossible for 99.99% of Wiki content authors - except for the few programmers who use a Wiki for their own purposes like you... We need you and all the other programmers, but here I believe you need to take a different perspective!

-- Gregor Hagedorn, 2007-Apr-13

Add new attachment

Only authorized users are allowed to upload new attachments.

« This page (revision-13) was last changed on 13-Apr-2007 22:55 by