(anonymous guest) (logged out)

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

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 

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 77.128.29.49  

This page was created on 02-Apr-2007 12:02 by YvesPiguet

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 100 added 42 lines
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
Version Date Modified Size Author Changes ... Change note
13 13-Apr-2007 22:55 16.905 kB 77.128.29.49 to previous
12 13-Apr-2007 22:46 16.791 kB 77.128.29.49 to previous | to last
11 13-Apr-2007 22:45 16.791 kB 77.128.29.49 to previous | to last
10 11-Apr-2007 23:23 14.391 kB 85.221.141.46 to previous | to last all users would have to learn css
9 11-Apr-2007 22:43 11.36 kB Gregor Hagedorn to previous | to last chem etc. plugin not general enough
8 11-Apr-2007 10:42 10.522 kB RadomirDopieralski to previous | to last <>
7 11-Apr-2007 04:10 9.507 kB Gregor Hagedorn to previous | to last
6 05-Apr-2007 12:19 8.071 kB 85.221.141.46 to previous | to last advanced formatting
5 04-Apr-2007 23:24 5.855 kB Gregor Hagedorn to previous | to last Proposal misunderstood? Definitely NotNew!
4 03-Apr-2007 09:37 2.614 kB ChristophSauer to previous | to last seems not to be quite common, reject
3 03-Apr-2007 09:06 1.636 kB YvesPiguet to previous | to last Agree
2 03-Apr-2007 07:51 1.295 kB 85.221.141.46 to previous | to last -- is out :(
1 02-Apr-2007 12:02 0.693 kB YvesPiguet to last Why not XML?
« This page (revision-13) was last changed on 13-Apr-2007 22:55 by 77.128.29.49