Talk:Wikitax
Add topicUntitled
[edit]Note: the disappearing $1 bug is fixed. --Brion VIBBER 23:05 Dec 21, 2002 (UTC)
Whatever syntax you design, please keep in mind that on foreign keyboards many characters are _very_ hard to get. For example on a german keybord the [ ] keys need three keys pressed down and are most unpleasant to type.
So when at all possible, please design something internationally as easy to use as most of the KwikiFormattingRules are. -- Martin Häcker
- A solution could be an alternate diagraph syntax. ((*bold*)) instead of ((*bold*)). That gets horrific with ((((links)))) though. The problem is that different keyboard layouts leave out different keys. The only ones which seem to be universal are parentheses, commas, hyphens and periods. -- IanBollinger
See Tomasz's email and my reply. He suggests that opening and closing tags should not be the same; e.g., '!!bold!!' or '//italic//'. And that there should not be any prefix-overlap with tags; e.g., '', ''', '''', etc.
What should we do to rectify this? Maybe something similar to [!bold!], [/italic/], [=monospace=], [-strike-], etc., for text formatting and other similar tags? Or {!bold!}, |!bold!|, (!bold!), `!bold!`, ~!bold!~, etc. What would be a good, clean, small, and simple syntax where the opening and closing tags are different from each other and where the tags are unique from character sequences that normally occur in written language?
And how do we fix the prefix-overlap problem? What would be a better syntax for providing three levels of emphasis (<em>, <strong>, and <em><strong>)? --Jizzbug
- Maybe [~ emphasis ~], [~~ strong emphasis ~~], and [~~~ very strong emphasis ~~~] could be used as alternative. Hmm, maybe '~' isn't the best character, because of the '~~~' and '~~~~' signature conventions. Maybe, then, [+ em +], [++ strong ++], [+++ em strong +++]. And here, the '+' kind of eludes to the idea that you're adding emphasis to the text. --Jizzbug
- I like [!bold!] or [*bold*], [/italic/], [=monospace=] or [|monospace|], [-strike-] 63.205.40.4 19:53, 15 Feb 2004 (UTC) User:Noldoaran(I forgot my password, so i'm not logged in)
Hi,
first, let me say that I, too, am planning to work on a wiki-weblog combination, with a common syntax for both parts of the system. I run infoAnarchy, a Scoop weblog, and am currently hacking Scoop to make the user interface internationalizable (mostly finished) because I want to use it for this site and this site as well. infoAnarchy already has a Usemod wiki (with Recent_Changes hooked up as a Scoop box), but this is hardly a satisfying long-term solution because you want stuff like wiki-links from stories to pages, a common syntax etc.
Because of this, I think it's important for us to work together, so I will definitely keep an eye on this page. There are some similar efforts in the Python world like Structured Text and Restructured Text which I have not yet fully investigated, but they looked too complex to me.
I'm actually mostly happy with the Wikipedia syntax, because a) it works, b) people are used to it. But there are some things I dislike and other things that I miss:
- '' and ''' are clearly non-intuitive and hard on the eyes. I don't think having the same character for the beginning and the end is too bad, but it can lead to problems.
- The link name/page name distinction ([hello world|hello] is also non-intuitive. In the beginning I always forgot which one had to come first. Actually, I just had to think about it right now. Perhaps something like an arrow -> would help: hello->hello world seems more obvious.
- The double square brackets syntax for links is too long. Links are too common to have them represented by four characters. I'd be much more willing to tolerate some requirement for character masking or an ugly link character. I think the following characters are rarely used: # \ {} |
- indentation of several paragraphs needs to be simpler, i.e. a blockquote tag.
- We need a wiki syntax for tables.
I have to think hard about these different problems. You can find some of my preliminary thoughts here. Here's what I think right now would look nice, but parsing would have to be checked:
- |foo bar| for links, titles are not case sensitive
- |foo->foo bar| for links that point to different pages
- |CNN->http://www.cnn.com%7C for CNN
- _foo_ for italics, __foo__ for bold
More complex stuff could be done with extensions to the [ ] characters, like
[>
indentation block
<]
[%
preformatted block
%] (also a replacement for nowiki)
[_
block in italics
_]
[__
block in bold
__]
Careful there not to limit the link namespace too much, but the above should be no problem.
What we could keep: *,**.. for bullet lists, #,##.. for number lists, : for line indentation, ; for ~~~ for signatures, space for single line indentation, == for sections.
I think we should also think about a syntax for references, so you can do something like {see also: Meyer (1972)} or {see also: |http://www.cnn.com%7C} and get a numbered, linked endnote and a list of endnotes with anchors at the bottom.
From the above we would get the following consistent rules:
- -> is the pointer sequence, it is used everywhere where we have a name that points to a different target
- markup that can occur only over the span of a single paragraph (bold, italics, links) can be represented with same character pairings
- | is the link character, it is used exclusively for links
- [x x] are characters for complex formatting sequences, where x specifies the sequence. These should be as visually intuitive as possible.
--Eloquence 05:14 Dec 22, 2002 (UTC)
The only problem I see with using the pipe (|) for URLs is that you'll find pipe delimited URLs fairly often out in the wild. They're certainly more rare than '?' and '&' as delimiters, but they exist. One example we should all be familar with: remember the old 'file:///C|/mydir/mypage.htm'? While that particular example shouldn't worry us too much in a wiki, there are large, popular sites that use pipe characters in their URLs. I actually had this particular issue in mind when I was thinking about the Template:... syntax for URLs. In an example, I used:
- {{http://hackunix.org/ hackunix}}
instead of
- {{http://hackunix.org/|hackunix}}
for this very reason. Spaces are just about the only characters not used in URLs.
You've mentioned that you think [[...]] is too much. Personally, I don't think so. I'm actually rather fond of how it looks, too. *grin* But that's just a personal opinion, and those things vary wildly. My only problem with going down to single square brackets for wiki links is that single square brackets are used quite a lot when embedding parenthetical phrases within parenthetical phrases.
For example:
- I like using parentheses (really, I do [no kidding]).
- an even more common use is for insertions in quotes 4.61.249.109 09:39 Jan 25, 2003 (UTC)
How will the software know whether 'no kidding' is an article identifier or not, when in this context it certainly isn't? This was my rationale behind doubling up the square and curly brackets for wiki links and URLs, respectively. Curly brackets aren't overly abundant in plaintext, but they occur often enough that I think it pays off to double them up for URLs. While you may be a fan of escaping characters, I'm not. *smile*
I really like your pointer idea! And since the pointer comes before the URL, you don't have to worry about '-' or '>' being common URL characters.
So I have to say,
- {{hackunix->http://hackunix.org/}}
feels much more natural.
- I agree. I still have to use my fingers to understand the current syntax. ;-) Maybe we could also allow a backward arrow for downward compatibility (easy conversion)? SebastianHelm 10:30 Jan 25, 2003 (UTC)
Anyways, you've provided me with a lot to think about, so I'm gonna go think now. --Jizzbug
note to self:
Idea for both headings (XHTML) and sections (XHTML 2) support all in one shot.
First off, should it be:
e.g.,
Or should it be:
e.g.,
I tend to favor the former. When the syntax is compressed as above, the former's visual appearance tends more to hint at the hierarchy of the sections. It's very aesthetically pleasing. And it allows for easier and more consistent "infinite" subsectioning (I can explain, it's just a lot of verbage for now).
- That was what I expected when I started. But now I see it differently: The more characters there are, the more indented it becomes. And the biggest advantage is that it has no upper limit. So I would stay with the old syntax. SebastianHelm 10:30 Jan 25, 2003 (UTC)
Declairing a heading defines a named anchor at that point. (Or when XHTML 2 comes along, it also opens up a section [if certain tests are satisfied {e.g., is there a corresponding 'end section' advanced tag?}].)
Whether current browsers support section semantics now or not, if there's any easy way of usin' 'em, we ought to start usin' 'em now. For forward-compatibility and allowing for more efficient use of existing technology, e.g., outputting to TeX or Postscript or PDF from Wikitax, and for better/cleaner [[:toc:]] support.
At the end of the block of text that is to make up a section, you would use the advanced features tag, [[:end-section: "heading's title"]] (or some better, but similar, syntax). E.g.,
-=== Important Paragraphs ===- The following paragraphs belong to a section about important paragraphs. I suppose that means this paragraph is somehow important. I don't see it. In any case, since there doesn't seem to be much of importance here, we ought to close out discussion of this topic. [[:end-section: "Important Paragraphs"]] |
Also:
[% ... %] or [$ ... $] should be the string literal syntax (i.e., <nowiki>). As an added mental-cue-for-techies, '%' and '$' are both reminiscent of stringy things in various scripting and programming languages. String literal syntax should be usable inline and in a block. And it should not provide any <pre> functionality.
[= ... =] inline provides for technical-looking, monospaced text. So it sort of follows that using [= ... =] in block mode would be preformatted text--i.e., <pre>.
For example, <pre><nowiki> ... </nowiki></pre> would be achieved via:
[=[%
This text is pre-formatted.
In real rendering, it will look exactly like this.
But without the box,
and the markup,
above
and
below.
[[nothing is evaluated]]
%]=] |
which would be rendered in a browser like:
This text is pre-formatted.
In real rendering, it will look exactly like this.
But without the box,
and the markup,
above
and
below.
[[nothing is evaluated]]- I don't think the user should have to think about [:end section:]. That's what a computer is good for. A section ends where the next one of the same or a higher level starts. -- User:JeLuF
- The only reason I thought [:end-section:] might be necessary is when you have a section nested in the middle of a larger section. For example:
<section> blah blah blah <section> blah blah </section> blah </section>
This kind of nesting/embedding of sections couldn't be figured out by software without explicitly ending sections. It's a minor point, but might as well be accounted for. Most people, as you point out, would never need to know of or use something like [:end-section:]. I think I might have had another rationale needing something like [:end-section:], but I can't remember. Hmm, on second thought, though, maybe [:end-section:] really is unnecessary. --Jizzbug
- The only reason I thought [:end-section:] might be necessary is when you have a section nested in the middle of a larger section. For example:
The syntax ought to intelligently handle currencies, etc. That way people can specify their locale in their preferences, and currencies could automagically be converted to their locale.
$.02 $0.02 $2.02 USD$2.02 CAD$2.02 £.02 £2.02 GBP£2.02 ¥35000 etc.
should all be distinct enough to be handled specially/properly in software. --Jizzbug
Specific named anchor syntax:
[[:anchor: name="anchor_name"]]
Anchors ought to be automagic for headings, media, etc. (see note to self above). But some functionality for explicit named anchors would be good. --Jizzbug
Perhaps there should also be an XML syntax of Wikitax. -- nichtich
- What exactly do you mean? Could you give an example? --Jizzbug
- Addendum: Oh, nevermind that, when I wrote the above, XML syntax didn't exist yet. --Jizzbug
There should be some consideration : 1. Matching start and End is a lot of troubles. 2. The Wikitax should be apply to all available text safely, with thoese discussing themselves (which got a lots of marked up in them), or text that got generated by programs. 3. Extensiblility: With a defined mapping, the system shold be able to translated the text (in Wikitak) into a well-formed xml. With the above, I would like to suggest: 1. Change [*, ... to [[* 2. Escape [[ by [ [ (Simply insert the space between, and output as [[ ᢇ is Zero width no-break space, to escape [space[ use [ [) 3. Allow short hands like [[*_=]]this is bold underline monospace This is normal again Which end at the line break. Of cause, the original [[*bold [[=Monospace=]] [[_underline_]]*]] should work unchanged. and allow omit the end symbols if possible, i.e., [[*bold [[=MonoSpace]] [[_underline]] bold]]. 4. Use [[ for everything. Including user defineded tags: [[author]]Samuel, Chan or [[titleandauthor: Some fine topic / [[author: Samuel Chan]]]] which should translated to <author>Samuel, Chan</author> and <titleandauthor>Some fine topic / <author>Samuel Chan</author></titleandauthor> 5. Allow extra specification to be included: [[#use user-define-format]] Which allow customer format to be used. The user can then responsible for their own creations. This will be a big-hole : there are various formats to be defined: c, c++, perl, python, tex, csv, isbd (bibliographical description), bibtex, man pages, etc. 6. Define the translation as logical-translation + css instead of physical markup, i.e., [[*bold]] --> <span class="emph">bold</span>. Even, this can be done as logical markup + xslt + css, i.e., [[*bold]] --> <emph>bold</emph> with apropriated xslt and css to format them. 7. As a short-hands, the format block commands can be [[* ]]. With a space inside, it will apply to the block. As an extra feature, I would like to add a alias-table to the system. which can perform two tasks: allow one page to be as different titles; and allow multiple pages sharing a single title which is presented as a selection page, for example, ''Computer'' is a common name for ''Analog computer'', ''Digital computer'', ''Electrical Computer'', ''Electronic Computer'', ''Machanical Computer'', ...... (may be allow selection instructions). Also, there should be macros like [[:include: page_or_url]], [[:auto_date:]], [[:auto_text: some_defined_text]], etc.
kentsin@yahoo.com.
I'll keep this brief...
This is increasingly reading like a reinvention of html all over again, except with different tags.
I tend to believe in the 10/90 rule - 10% of the features (or less) will satisfy 90% (or more) of the needs.
Before I heard of wikitax, I'd been working independantly on my own simple wiki markup system - it's not as polished as Wikitax, and the page is full of notes and being-discussed points... but it expresses my views better than I could by rewriting it all out here ;)
http://www.nut.house.cx/cgi-bin/nemwiki.pl?NEWS/TextFormatting
.../Nemo <wiki@nemo.house.cx>
Think about this:
- [[homeworks>>homework]] insted of using ->
- Using html, <em> <b> <u> <i> isn't bad at all(!?)
- What about using § when you want to §link a word.
I think it's important to look at some of the existing variants of wiki markup that already exist, and see what works, what doesn't, and what alternative methods have been handled for things.
For eg, the UseMod wiki method of handling lists is
* list item * list item ** nested list item * original list item
By comparison, MoinMoin wiki does:
* list item * list item * nested list item * original list item
Handling nesting by indents shouldn't be appreciably harder to handle in the code, and is visually MUCH more pleasant and obvious as to what is happening.
- I have a question. Does the current or proposed wiki syntax allow embedding complex markup into list items? I would really like to be able to put multiple paragraphs into a single list item. I would also like to space separate list items. Then I could have text rendered like this, which would be cool:
1. paragraph 1 2. paragraph 2 paragraph 3 3. paragraph 4 paragraph 5
- newhoggy 23:32 Jan 12, 2004 (UTC)
Similarly, MoinMoin handled indented text by indenting it. (this is the KISS principle at its best. :)
- I agree, it also fits better to the syntax of ###, where each charater stands for another symbol. (Maybe, though, we can use both. The former if you want the bullets to change according to a prescribed order, the latter if you don't.)
- This allows us also more flexibility with our special charaters. We won't have to restrict them to single digits anymore.
We could e.g. code the numbering system as follows:
<ordinator> = [" "]..<specialcharater><formatstring>" "
- * stands always for a bullet
- # stands always for a number, separated by dots.
- @A stands always for a capital letter
- @a stands always for a lower case letter
- @I stands always for a capital Roman number
- @i stands always for a lower case Roman number
- @g stands always for a lower case Greek letter
- @(a) stands always for a lower case letter in parentheses
- @aa stands always for a doubled lower case letter
- % stands for automatic change in the form II.A.2.a.i
- + stands for Explorer-like branched lines
- SebastianHelm 10:30 Jan 25, 2003 (UTC)
- So does:
- So does:
@aa pig @aa cow
- mean:
- mean:
a. a pig b. a cow
- or:
- or:
aa. pig bb. cow
- newhoggy 00:03 Jan 13, 2004 (UTC)
- It should mean
- newhoggy 00:03 Jan 13, 2004 (UTC)
aa. pig bb. cow shouldn't it? Interpret upto the first space, count alfabetically, using two digits. Aliter 16:48, 13 May 2004 (UTC)
With regard to link hiding, I find [[pagename|linkname]] to be just as sane as [[linkname->pagename]]. The first is the syntax of unix `ln` where the pointed to name comes first, and the second is the syntax of the output of `ls`. I actually prefer the first method, since I consider the pagename to be the most important information in the link block, and the displayed text is secondary importance, and thus comes later.
Lastly, with regard to the basic markup of strong and emphasis more easily considered as bold and italic... what's wrong with *bold* and /italic/?
- It's visually obvious without being visually bloated
- By clever use of surrounding characters, the start marker is not nescessarily the same as the end marker. ie, "non-alphanumeric char, *, alphanumeric char" is the start marker, and reverse that order for the end marker. The actual code might need to be a little more complex than that to handle emphasis on a question, including the questionmark, for example, but I'd rather the complexity be in the code, not in the markup. I'd also allow pure html for these, for those (imho very rare) occassions that the provided markup can't handle the task. (eg, my suggested markup cannot handle emphasis within a word)
- I'd rather not. Simple, strict code tends to be bug free and there'd be less disagreement between various 'conforming' implementations to wikitax. Something that is complex to code is usually complex to specify after all. But if it has to be, then being able to fall back on [*bold*] and [/italic/]? is much better than falling back on HTML.
- newhoggy 11:32 Jan 12, 2004 (UTC)
Lastly, using § as a link character - I'd argue against it simply because, while we increasingly live in a unicode world, our keyboards are much more limited.
.../Nemo
Re: Nemo's comments
I, too, have thought a lot about the format for lists; i.e.,
+ list item I ++ list item I.A + list item II |
vs.
+ list item I + list item I.A + list item II |
... or ...
# list item 1
@ list item 1.A ... this list item's text is
really long and can be hard-wrapped and
indented by the author like so
# list item 2
|
vs.
# list item 1 @ list item 1.A ... this list item's text is really long and isn't hard-wrapped/indented by the author, but is typed on one line which is soft-wrapped by the browser within a <textarea> # list item 2 |
I tend to think it would be simple to support all varieties of the above:
- UseMod-style hard-wrapped/indented;
- UseMod-style soft-wrapped;
- MoinMoin-style hard-wrapped/indented; and
- MoinMoin-style soft-wrapped.
With all these varieties supported, it could be left up to the authors' personal preferences as to which methods they choose to employ.
Also, in regard to [[text->target]] vs. [[target|text]], again, I suppose it would be possible (would it be practical?) to support both methods. The latter style ('|') could be officially depreciated, but supported, and the former style ('->') could be the recommended syntax. I tend to think pointer-style syntax ('->') is more immediately intuitive without having to consult some syntax guide.
Yet again, with regard to [*bold*] vs. *bold*, I suppose it would be possible (with the same question of practicality) to support both methods. I think it's very important to support [*bold*] regardless, so that the cases in which formatting can be applied aren't as limited as they would be for *bold*. If people preferred *bold* they could use it and still have the flexibility of [*bold*] to fall back on should they need it.
Aside from all the debating, I think it's important to discuss and consider all these issues, and I'm glad we all are. By doing so, hopefully we can avoid creating a hodge-podge mess of a syntax that we have to use in the wikies of today. --Jizzbug
I think all markup should be standardized into the [x ... x] format, x being the special characters that identify what the markup means.
I would dare propose the following syntax for some things:
[[text->article]] and [[article|text]] for internal links
[{text->url}] for [{url|text}] external links
[*text*] and ['''text'''] for bold
[/text/] and [''text''] for italic
[=text=], [==text==] etc. for headings (I think less equal signs should mean larger heading)
[----] for <hr>
...
Basically, put most of the current wikipedia markup into []s. What would this policy mean for list markup? Maybe
[#] 1 [#] 2 [##] 21 [###] 211
But this might be taking it too far... The purpose should be to make it easy to enter formatted text. Inventing whole new consistent markup language might be equivalent to inventing hot water. HTML already exists. Maybe we should focus on shorthand for HTML.
On a related note, I've been thinking... shouldn't the pipe trick also remove stuff after (and including) the first comma, so that [[St. Petersburg, Russia|]] becomes [[St. Petersburg, Russia|St. Petersburg]]? It would make entering all those geographical links much easier.
Zocky 00:06 Jan 21, 2003 (UTC)
re: using [x...x] vs x...x
To me, it's a question of goals - I don't specially want a shorthand to html - because the code becomes almost as unreadable as html already is.
I want a markup which is invisible to the layman. I want to be able to take the raw code to a page, drop it into a text-only email to my mother, and not worry about it being utterly confusing - hence i argue for the obvious-to-a-laymant *bold* syntax, instead of the "the-brackets-are-confusing,-why-are-they-there?" [*bold*] syntax.
Sure, I concede that not everything can be made layman friendly - internal links being the prime example, but I still hold this up as a goal.
Another example - if I want to link a URL, and I don't care to mask the link with another word, then just including the URL should be sufficient. It's not that hard to pattern match "http://" at the start of a string, and end it at the next space (possibly with a bit of extra intelligence to drop any trailing punctuation - like a comma or close-parenthesis).
Ditto for image URL's that should be made inline.
.../Nemo
My question is, what happens to current markup when it's drastically changed like above suggestions? If I have a bunch of '''words''' already posted and the markup is suddenly changed, isn't that problematic? Why not build on current markup? What's the diff between /fdsafdsa/ and what's already around?
~ciaran
Simple ideology of Wikitax discusses some of the above questions, and offers strong views on what the priorities of Wikipedia syntax must be.
Could we begin by changing the name for this proposal? It sounds too much like some fundraising proposal to charge everybody for using Wikis. Eclecticology 18:13, 1 Oct 2003 (UTC)
I'd definitely look at restructured text. I know it's mentioned above as "looked too complex", but there's been a lot of thinking into its design. Even if you don't adopt it looking at its extensive documentation about design considerations would be more than worth it. Some of the proposals here to me look at least as complex as restructured text. The devil with this kind of thing is in the details, and restructured text tries hard to cover such details.
http://docutils.sourceforge.net/rst.html
with this being a document about syntax alternatives which have not been adopted, with reasons:
http://docutils.sourceforge.net/rst.html
and this being a document describing what was wrong with structured text, its predecessor, and how restructuredtext tries to improve on it:
http://docutils.sourceforge.net/rst.html
Martijn Faassen
- Renamed from Wikitax to Wiki syntax. - Patrick 17:35, 3 Oct 2003 (UTC)
Quotation
[edit]In German texts it is very common to use "..." for quotation, since in early ASCII days „...“ („...“) were impossible in browsers and many users are today still are not used to HTML entities. But, In Software like MS word these "false" quotations are automatically replaced by the correct ones depending of the characters before or after the "-character. I know that in Switzerland instead of "..." they use «...» and in France « ... » is used. Is there a possibility to integrate those typographic quotations in the software? 82.82.129.206 01:05, 23 Nov 2003 (UTC)
Hyphens
[edit]In example in LaTex it is common to write -- and you will get an en-dash (– / –). If you use --- this will lead to an em-dash (&mdash / —). This could be realized in Wikitax, too, since ---- will lead to <hr> 82.82.129.206 01:08, 23 Nov 2003 (UTC)
concerning those wrongly overlapping tags e.g.: begin italic, begin bold, end italic, end bold - i think the good idea would be to fix them automatically, but at the same time provide a clear warning about this... (e.g.: the text you have entered contained some improperly nested (overlapping) blocks. they were modified to most probable intended form. please check the effect and try to avoid that in future)... just my $.03 -- blueshade.
I second Martin Häcker's opinion on the awkwardness of some characters. Almost all European keyboard make typing not only [] but also {}\@| exceedingly hard to type.
However, I don't support the conclusion, at least not immediately, because, unfortunately, {[]}\@| are precisely those characters that are used rarely in normal text, and hence most useful for delimiting markup.
There's a trade-off involved: more common characters are generally easier to type, but this also means more need to escape them for verbatim use. HTML used mildly-common characters for markup, "<...>". For a Wiki, this choice is probably too far on the common-character side.
Personally, I'd like something like "((...))". That's rare enough to keep quoting overhead low, yet the individual characters are easy enough to type.
(My first idea was to propose "<<...>>" since that's nearer to HTML, but then I remembered the double angle brackets are used for quotations in some languages.)
-- Joachim Durchholz
Using ((...)) would be bad in the case of any discussion of Scheme programming language or Lisp programming language though. D'oh! is there an easy way to link to standard Wikipedia articles from the meta site?
Somebody said above that Wikitax is reinventing HTML, just with a different syntax. There's a lot of truth in that, but it's justified to invent a new syntax: the trade-offs are different.
HTML is for techies, Wikitax is for non-techies. Some decisions that were acceptable for HTML are simply too complicated, too awkward, to alien for non-techies.
Then there's security. HTML offers ways to overlay stuff outside the area that some text was supposed to go into. It offers ways to embed scripting, so anonymous users could implant malicious HTML in a Wiki, with all sorts of legal hassles following.
Then Wikis are about editing other peoples' texts. Even allowing HTML markup to coexist with Wikitax would mean that those who don't know about HTML will be unable to edit text with HTML markup.
The latter aspect is actually generally important. It's a massive incentive to stick with the KISS principle: make it as simple as possible. Make the syntax rules as simple as possible. Don't offer features that are complicated, even if that limits what you can do in a Wiki. (For example, this means that you can't reasonably use tables, unless you find some really ingenious way to do them.)
-- Joachim Durchholz
Tables
[edit]Well, here *is* the ingenious way to do table syntax *gg*
Something like the following, which would define a table of 3 rows à 4 columns, the second cell in the last row left empty.
[[table]] 1 2 3 4 5 6 7 8 A - B C [[1]] Contents for cell 1. [[2]] Contents for cell 2. ... [[C]] Contents for cell C.
Just a thought that occurred to me when I wrote the above on disallowing tables because the table syntax is generally too difficult on non-tech users :-)
-- Joachim Durchholz
- How do you define the end of the last cell? R3m0t 15:41, 16 Mar 2004 (UTC)
- Did we give up on pipe-syntax for tables? Like:
[| This is the first item | This is the second | Third | Fourth |] [| This is the first & second item || Because we skipped one | Fourth] [| First | Second | Third | Continues in the gap below|] [| First | Second | Next one doesn't exist.|/|] [[ Last line, | since next | has no | pipe mark |]
For several close tags, how about
[*\ bold italic \*]
? R3m0t 15:42, 16 Mar 2004 (UTC)
Are all these formatting options really required? If you ask me they only serve to bloat the parser and make things more complicated. Instead, we should go the way of HTML and emphasize structure over formatting.
Also, it might not be so hard to parse en dashes (even though TeX requires seperate tokens.) You'd need to distinguish between numerical character and letters, however. For instance: 1-1 would en dash while a-a would yield a hyphen and a--a would yield an em-dash.
-- IanBollinger
Go for structure not style.
[edit]Use a structured markup not a style based one. An ultra simple XML dialect would be best I think.
Additional needs for markup
[edit]When you look for something in the Encyclopaedia Britannica you run over the following passage every now and then: Consult the Index first. And the Britannica has an excellent index. If Wikipedia wants to come close to that we should have something like an index entry. It's a bit like the complement of a wiki link ... (which is the start of an arrow from one article to another), the index entry is the end of the arrow. It will perhaps not have an impact on the markup, but will be useful for index generation.
Martin Läuter Oct 3, 2004
Please move
[edit]{{edit request}} Please move to wikitax--no need for the disambiguation and there are some incoming links to the name without it. —Justin (koavf)❤T☮C☺M☯ 10:36, 23 June 2020 (UTC)
