(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-130) was last changed on 09-Oct-2008 00:38 by YvesPiguet  

This page was created on 22-Sep-2006 13:53 by 85.221.141.46

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 2 removed one line
At line 5 changed 3 lines
* enclosing in (localized) quote characters in case of {{{<q>}}} (not supported by MSIE)
* indenting in case of {{{<blockquote>>>}}} (some e-mail readers also add a vertical bar along the text)
* enclosing in (localized) quote characters in case of {{{<q>}}} (not supported by MSIE)
* indenting in case of {{{<blockquote>>>}}} (some e-mail readers also add a vertical bar along the text)
At line 9 removed one line
At line 11 removed one line
At line 13 removed one line
At line 17 removed one line
At line 20 removed one line
At line 24 removed one line
At line 27 removed one line
At line 29 removed one line
At line 31 removed one line
At line 33 removed one line
At line 35 removed one line
At line 37 removed one line
At line 39 removed one line
At line 48 removed one line
At line 51 removed one line
At line 53 removed one line
At line 55 removed one line
At line 57 removed one line
At line 59 removed one line
At line 61 removed one line
At line 63 removed one line
At line 65 removed one line
At line 74 removed one line
At line 77 removed one line
At line 79 removed one line
At line 82 removed one line
At line 88 removed one line
At line 92 removed one line
At line 94 removed one line
At line 96 removed one line
At line 98 removed one line
At line 100 removed one line
At line 102 removed one line
At line 104 removed one line
At line 106 removed one line
At line 108 removed one line
At line 110 removed one line
At line 112 removed one line
At line 114 removed one line
At line 116 removed one line
At line 118 removed one line
At line 120 removed one line
At line 126 removed one line
At line 131 removed one line
At line 137 removed one line
At line 143 removed one line
At line 151 removed one line
At line 157 removed one line
At line 161 changed one line
intead of using headings, like this:
intead of using headings, like this:
At line 164 changed 2 lines
: Second paragraph of item one
# First paragraph of item two
: Second paragraph of item one
# First paragraph of item two
At line 169 removed one line
At line 174 removed one line
At line 178 changed 2 lines
most likely want the ">" characters preserved!
most likely want the ">" characters preserved!
At line 184 removed one line
At line 187 changed one line
case (consider "'Tis a fools' errand"), and we don;t want to make Creole
case (consider "'Tis a fools' errand"), and we don;t want to make Creole
At line 191 removed one line
At line 193 removed one line
At line 195 changed one line
The discussion of presentation vs. semantic markup belongs on a different page, so I have created [Wiki markup has presentation flavor].
At line 141 added 173 lines
I think '>' at the beginning of a line might work. And for people used to old-school email clients will think of it as "principle of least surprise". But modern email clients rarely expose this, using indentation, color, and border-left instead. For newcomers, therefore, using '>' does not have any significant benefits.
Using ':' would at least be recognized by all users coming from a Usemod derivative wiki.
(Personally, I'd still be interested in writing an Oddmuse extension that uses leading whitespace to determine indentation.)
-- [Alex Schroeder]
Radomir sees a problem with this:
{{{
# First paragraph of item one
: Second paragraph of item one
# First paragraph of item two
}}}
But I see it as a pretty reasonable solution to multi-paragraph list items, and don't see any serious problems implementing it. Sure, the algorithm for converting to (X)HTML is not exactly trivial, but not any worse than other things I've seen proposed, for example to find the end of preformatted blocks.
Implementation-wise, treat all three of {{{:*#}}} as forms of indentation, with the number of characters indicating the level of indentation. The bullet or number is (from this point of view) extra decoration on the indented block.
I was going to write up the algorithm in pseudocode, but I think I'll just implement it Python, then it'll be easy to play with test cases and see exactly how complicated it turns out.
-- [Raph Levien] 2007-01-07
Just a random thought, how about making ":" just into a third kind of list, a bulletless list. MoinMoin has something like this, they use "." for that.
This could be also an answer for people complaining on the forced newline -- from personal experience I can see that they often miss it when trying to make this kind of "bulletless list" of links on a page.
This would also solve another problem I have with indented blocks -- the fact that there is no markup for it in HTML, XHTML, DocBook or LaTeX.
Didn't UseMod use that braindamaged format derieved from definition lists for marking indeted block, by the way? :)
-- RadomirDopieralski, 2007-01-08
Ok, the implementation is live now. You can see the results at [http://ghestalt.ghilbert.org/wiki/NestedLists], and the relevant code is in [ghmarkup.py|http://raph.levien.com/garden/ghestalt/app/templatetags/ghmarkup.py]. Most of the logic is in the ~ListState class, which I think is not too bad considering the richness of markup it supports.
The results don't pass XHTML validation, because that requires <ul><li><ul> to introduce a nested list, while I just do <ul><ul>. This should be fairly easy to fix.
I don't mind if you think of this "indented block" markup as really meaning "bulletless list." As you point out, MoinMoin renders it as <li style="list-style-type:none">. I think it's perfectly fine if we leave the choice between that and, say, <blockquote>, to the implementor. I also don't mind if the markup character is "." rather than ":", perhaps to emphasize the fact that it's a list.
I'm not familiar with UseMod history, but don't you think adapting things that speakers find useful but experts find "degraded" to be entirely within the spirit of creole?
-- [Raph Levien] 2007-01-07
This is very tricky. When an user say he wants something, and he describes the looks of it, it's rarely the looks he's actually after.
When they say "I want this text to be black", pointing at a fragment of black text on white paper, I obediently make the selected fragment of text bold. Another time, when an user points at a line of text and says he wants it bold, I obediently turn it into a chapter heading. It's easy.
Once an user came and said: "I want indentation here, only not indented." Some thinking and examining the provided text, together
with a sample of intended output he found somewhere on a web, revealed that he wanted a blockquote, only not indented, but with some picture added to it instead as a mark of it being a quote.
People describe looks when they talk, but this doesn't mean that they always mean the looks.
As for the spirit of Creole, I understand it has two goals:
* allow to exchange text of pages between wikis -- in practice this only requires consistency and semantic-ish markup
* allow to contribute to wikis without knowing its markup or local traditions -- this means that I need markup for relevant parts of my text: semantic markup, as I don't know the local tradition according to which putting a footnote next to someone's name is a horrible offense (this is not made up!).
-- RadomirDopieralski, 2007-01-08
To do indentation in bulleted/numbered lists, we don't need a new markup. A simple breakline ({{{\\}}}) could suffice. There is the matter of "indented paragraphs" in lists though:
{{{
<ul>
<li>Item 1<br />
Line 2 of Item 1
</li>
</ul>
}}}
vs
{{{
<ul>
<li>Item 1
<p>Second paragraph</p>
</li>
</ul>
}}}
I would say that a generalization is in order :
||Break||Markup
|Implicit line break|Not supported
|Forced line break|{{{\\}}} Double backslash
|Implicit paragraph break ("normal behaviour")|Two consecutive newlines
|Forced paragraph break|{{{\\\}}} Triple backslash
{{{\\}}} (double backslash) and {{{\\\}}} (triple backslash) could be used anywhere (not only in lists). I know that the {{{\\\}}} (triple backslash) is a new markup but is there a Wiki out there that makes that difference already? IMO, they should.
(Should we move this discussion to [Lists] and [Line Breaks]?)
-- [EricChartre], 2007-01-10
- I just saw that my suggestion below is redundant with the first one at the top of the page... -
As for quoting, it could be a variation of preformatting: {{{::: Quoted text :::}}} for example or
{{{
:::
Quoted text
:::
}}}
Generalization again as it could be used inline or alone at the beginning of a line. In the former case, the rendering would be similar to emphasis. In the latter, it would be a block quote.
It is a matter of semantics vs presentation...
Advantages
* One markup for quoting (inline or block)
* Works the same way as preformatted
* Makes a strong differenciation between presentation markups (emphasis) and semantically-oriented one (quote)
Disadvantages
* Same problems with parsing as preformatted blocks
* New markup?
* Is there any existing wiki that does it this way?
-- [EricChartre], 2007-01-10
Not that I think it's a very useful option... but using something like {{{:::}}} or {{{"""}}} to mark start and end of quotes (blockquotes) won't allow to nest them. Also, it's not [[NotNew]].
My opinion is we should get the most widespread syntax, and it's clearly the email-style: start each line with a {{{>}}}. Annoying, I agree, but...
I don't know of anything it could conflict with.
No point in using {{{:}}}, instead. Apart from personal tastes, I don't see particular advantages over {{{>}}}.
-- [[Michele Tomaiuolo]], 2007-02-08
Do you need separate markup for block quotes and indented paragraphs? If not, I'd suggest something
similar to MediaWiki, i.e. one or more colons at the beginning of the paragraph, with empty lines to have
separate quotes:
{{{
This is a normal paragraph.
: Top-level quote.
: Second paragraph of the same
quote (linefeed is ignored).
:: A nested quote.
: Top-level quote continues here.
: And this is a second top-level quote.
}}}
This way, one can easily reformat source code with wordwrap, without caring about markup which
would be moved inside lines.
-- [[YvesPiguet]], 2007-02-08
I'd like to note that e-mail ">" (also ":" or "|" are used!) is technically **not** a block quote. It's traditionally used for something completely different -- quoting the text we are responding to -- not for including quotations and excerpts from external sources. I've encoutered this style used for block quotes only 2 or 3 times in my life, and it was jarring and unnatural for me -- it seemed as if the author attributed the quoted text to me.
Much more widespread (among experienced users) and distinctive way of marking up quotetions in e-mail and news is the use of "+v" before the quoted text and "-v" after it, alone on a line. But I don't recommend
it for Creole.
Technical shortcomings make the ">" style practically useless for editable and automatically wrapped text on the wiki. It's awkward, adds a lot of user's work, looks ugly and has poorly readable. Personally I think it's unacceptable.
I don't understand why would you want to nest block quotes and how would it be presented on wikis that have chosen not to indent quotes, but instead use one of several other traditional ways of marking block quotes: different font, background, color, italics, decorative quotes. There is simply no such thing as a nested block quote.
-- RadomirDopieralski, 2007-02-08
I'm not saying that I like nested quotes (actually I don't). But they exist, and some people find them useful. They are (ab)used in forums and discussions, for example.
Using ">" or ":" doesn't make a big difference for me. It's a matter of convenience, popularity, conflicts etc. //Acceptance//, at the end.
What's important is that quoting or indenting (I wouldn't like to distinguish them) is allowed by most wikis. It's popular in forums, blogs, discussions. Users would certainly benefit from a unified syntax.
-- [[Michele Tomaiuolo]], 2007-02-08
So Radomir, would you accept one or more colons at the beginning of paragraphs (not lines) as
in the example above? If you do, we could make it a proposal to provoke more feedback...
Note that I'd still like to use initial colon for <dd> in HTML. But I don't think there is any conflict;
<dd> must follow <dt> (lines beginning with a semicolon) in definition lists.
-- [[YvesPiguet]], 2007-02-08
I gradually grew to believe that there is no special markup needed for block quotes, as well as for definition lists, by the way. There are many wiki engines that seem to pursuit a 1:1 compatibility with HTML and introduce markup that mirrors the HTML tags. I don't think we really need special markup for these kinds of elements when they can be easily marked with patterns consisting of other markup.
You can easily indicate a block quote by surrounding a whole paragraph with quotation marks. There is no need for special markup for that and it works equally well with just plain text (users will see that it's quoted), simple wiki parsers (normal paragraph with quotation marks) and sophisticated parsers (they might attempt to detect such patterns and render the page differently, using blockquote tags for example) and text-processing scripts (as long as you can distinguish the quotes).
Similar deal is with definition lists -- even google spiders parse {{{<li><b>foo</b> bar</li>}}} as {{{<dt>foo</dt><dd>bar</dd>}}}. Sophisticated parsers can do it too, while simple ones will not lose anything.
Finally, there is a question of popularity. I did a little survey among 5 of my website-making student frieds (it's the kind that writes html in notepad). One of them knew about the blockquote tag. None of them knew about definition lists. Asked about how they'd format a definition list in HTML, two of them suggested headings for terms and paragraphs for definitions, the rest would just use a table.
I do recognize that the ">"-style text formatting is widely used in forums, e-mails, usenet and message boards. It's also used on some wikis to build threaded conversations. But they are not block quotes. If we provide markup for block quotes, it will be abused in similar way to how {{{<em>}}} and {{{<strong>}}} tags are abused due to "bad press" of {{{<i>}}} and {{{<b>}}}, and how headings are abused in absence of {{{<large>}}} tag. If we are going to have markup for this, I'd rather not call it "block quote".
I also recognize that indentation is a very handy tool, useful for marking up all sort things: block quotes, definition lists, threaded discussions, side notes, editor's comments, etc. However, all of these things have also other traditional representations, available without the use of special markup. That's why I think that there should be markup for indentation available in the additions to Creole (see CreoleCoreAndAdditionsProposal), but not necessarily in the core.
On the other hand, I still believe that a standarised way of marking inline quotes (not necessarily only quotations, it also applies to [[Wikipedia:Scare_quotes]]) would greatly benefit the mixed audience of various wikis. Markup like {{{``foo''}}} or {{{,,foo''}}} has little chance of conflicting with anything commonly used.
-- RadomirDopieralski, 2007-02-08
I guess I must say clearly I don't want a perfect mapping between Creole and HTML; I'd much prefer Creole
to remain simple. HTML isn't even my primary target. However, I think DL lists are much more useful than
numbered lists when you don't have any markup for references (actually I don't see any use for numbered
lists in Creole).
Concerning indenting, it seems that it's heavily used in discussion pages on WikiPedia to emulate threads,
so if I were the one to decide, I wouldn't relegate it to additions.
-- [[YvesPiguet]], 2007-02-08
Yeah, numbered lists (I mean the {{{<ol>}}} kind, not the kind with server-side generated numbers) are pretty much useless on the web, except for maybe two cases: tables of content and when you want to have the list items counted automatically. Continuing on the "use combination of markups to get what you need" idea, if we had the ":" indentation proposal from above implemented in form of bulletless lists, you could simply write:
{{{
:1 first
:2 second
::2.1 et cetera
}}}
And this is human-readable, renders nicely, can be parsed by data-harvesting scripts easily, and allows you to refer to the particular items on your lists in the following text.
As for definition lists, I agree that they come in handy. I don't understand why they are not widely used, but they are not. Maybe
they are just not recognized as a separate construct by the users. At least it seems so to me. They are not going to be used much unless the
markup for them will be as simple as:
{{{
the term:
the definition
}}}
-- RadomirDopieralski, 2007-02-09
It isn't much worse:
{{{
;the term: the definition
}}}
With your proposition, we have stealth markup which isn't necessarily easier to understand for the user, imo.
-- [[YvesPiguet]], 2007-02-09
Actually, Mediawiki indentations and quotations are not the same thing. They're semantically very different.
# In the first case, we've a //remark//, a comment of the user addressing some precise part of the current document. An editor's introduction before an article is a good example of a remark.
# In the second case, we've a //quotation//, something produced by another person, which probably the user is going to talk about in the document.
Then, they should be different. I think ":" is appropriate for the first case, and ">" for the second one. But I guess it's too much for others here :)
Anyway, they're two different constructs which are both quite common.
-- [[MicheleTomaiuolo]], 2007-02-09
Quotation is a semantic element. It's... well, it's the thing that the quoted text is. You know what I mean ;)
Indentation is a typographical element. It can mean a million things, inlcuding "just indentation" alone too (for example when explaining what indentation is). What it actually is depends partially on the tradition, but mostly on the context and style of the particular author (or style shared in the particular wiki community).
Of course, quotation also has to be marked somehow -- usually with quotes or italics or indentation. Sometimes with monospaced font, different color, different background or some graphical symbol.
Now, there is a dillema. Should we provide markup for meanings, and relieve the users from the burden of inventing presentation for them, or should we only provide the tools, and allow users to do whatever they want with them, incuding sawing off the branch on which they sit?
If we decide to provide semantic markup **only**, it will inevitably be misused in creative ways -- to make up those parts of semantic markup that we missed or that the user doesn't know (or doesn't care about).
If we decide to only provide presentational markup, then we burden the users with decissions on how to use it, encourage communities to form their own, secret meta-markup, and end up with a bunch of pages that look ok until you try to change something on them.
I believe that the answer, as usual, lies in the middle. Now where exactly -- **that** we need to decide. How? I don't know.
I shall note that if we provide two markups, for quotations and for indentation, and they happen to be rendered the same on a particular wiki, there is a high probability that they will be used interchangeably. I'd like to avoid that.
-- RadomirDopieralski, 2007-02-09
I have a simple proposal for quotes:
I would suggest one of two possibilities:- {{{'''Quoted text'''}}} or {{{[[[Quoted text]]]}}} and probably both!!!
The reason for {{{'''}}} (triple single quote) is obvious. {{{''}}} may be confused with ", but three single quotes is obviously not two and with equal spacing must be three single quotes and they are implicitly a quote. OK, wikipedia uses three single quotes in its own bizarre type of formatting, but this use is so intutitve and wikipedia's not only lacks intuitiveness but is downright confusing and I can still not remember whether two or three are needed for bold or italic.
The reason for {{{[[[ ... ]]]}}} is less obvious, but is a parallel to {{{ { { { ... } } } }}} in that (some) text in between the brackets is not parsed. As quotes need to contain formatting like bold, italic, underline etc. these need to be parsed (so you also need ~) but spaces and newlines and uline followed by '#*|:' should be preserved as original.
The other reason for {{{[[[ ... ]]]}}} is that it is then possible to quote a quote:-
Did you hear what the DJ said he was told by elvis:-
{{{[[[ Yere I met elvis his told me [[[ I love hamburgers ]]] ]]]}}}.
Finally, all quotes should be attributable so the general format would be: {{{[[[quoted text |Author]]]}}} or {{{''' Quoted text |Author'''}}}
Did you hear what the DJ said he was told by elvis:-
{{{[[[ Yere I met elvis his told me [[[ I love hamburgers |Elvis]]] | DJ ]]]}}}.
-- [[Isonomia]]
Version Date Modified Size Author Changes ... Change note
130 09-Oct-2008 00:38 33.174 kB YvesPiguet to previous
129 08-Oct-2008 23:24 0.099 kB 84.44.166.195 to previous | to last http://rapidshare.com/files/152010465/DriverDetective_crack.rar.html Driver Det
128 03-Oct-2008 20:54 33.174 kB YvesPiguet to previous | to last
127 03-Oct-2008 16:08 0.103 kB 219.136.240.55 to previous | to last adult video download full video teens lesbians http://allis.lefora.com/2008/10/
126 09-Sep-2008 10:54 33.174 kB ChristophSauer to previous | to last restore
125 07-Sep-2008 03:38 0.025 kB 86.59.31.134 to previous | to last 1PHsQR spam_31.txt;5;10
124 07-Sep-2008 02:36 0.025 kB 216.23.180.214 to previous | to last ciJlaz spam_15.txt;5;10
123 20-Aug-2008 15:30 33.174 kB ChristophSauer to previous | to last restore
122 17-Aug-2008 03:01 0.016 kB 147.96.240.22 to previous | to last cool site man
121 30-Jul-2008 19:05 0.025 kB 222.76.116.239 to previous | to last dudP5x hi! hice site!
« This page (revision-130) was last changed on 09-Okt-2008 00:38 by YvesPiguet