(anonymous guest) (logged out)

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

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

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:

%%commentbox

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

%%(color:red)
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 whish 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:

C₂H₅OH
$$C_2H_5OH$$
##C__sub__2__sub__H__5__OH##

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

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 05-Apr-2007 12:19 by 85.221.141.46.