(anonymous guest) (logged out)

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

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
View Attach Info

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-105) was last changed on 02-Apr-2008 10:50 by ChristophSauer  

This page was created on 25-Mar-2007 14:22 by 222.46.18.34

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 1 added 4 lines
<<ALLOW edit Admin>>
<<ALLOW view All>>
[[UnlockMe]]
At line 7 added one line
At line 10 added one line
At line 12 added one line
At line 14 added one line
At line 22 added one line
At line 24 added one line
At line 16 changed one line
The examples are just a possibility of how the markup could be represented. Developers have to decide for themselves which way would make most sense for their situation.
The examples are just a possibility of how the markup could be represented. Developers have to decide for themselves which way would make most sense for their situation.
At line 30 added one line
At line 32 added one line
At line 20 changed one line
I haven't managed to find any discussion of a table headers addition. I understand not supporing all of the possible table markup, which is extensive. But captions seem pretty obvious to me. I'm finishing up a Perl module that parses Creole 1.0 and will probably add an optional caption syntax. I'm thinking {{{|? caption text}}}. Opinions?
I haven't managed to find any discussion of a table headers addition. I understand not supporing all of the possible table markup, which is extensive. But captions seem pretty obvious to me. I'm finishing up a Perl module that parses Creole 1.0 and will probably add an optional caption syntax. I'm thinking {{{|? caption text}}}. Opinions?
At line 38 added one line
At line 40 added one line
At line 42 added one line
At line 44 added one line
At line 28 changed 6 lines
Formatting: Links:
!1 h1 CamelCase
!6 h6 [Text]:URL
*bold* http://cpan.org
/italics/ {alt text}:IMG-URL
*/both/* ACRONYM(ACRONYM desc)
Formatting: Links:
!1 h1 CamelCase
!6 h6 [Text]:URL
*bold* http://cpan.org
/italics/ {alt text}:IMG-URL
*/both/* ACRONYM(ACRONYM desc)
At line 35 changed 6 lines
-strike- Lists:
^superscript^ * Unordered list
~subscript~ # Ordered list
"quote" ; Definition
@cite@ : item 1
SP or Tab pre : item 2
-strike- Lists:
^superscript^ * Unordered list
~subscript~ # Ordered list
"quote" ; Definition
@cite@ : item 1
SP or Tab pre : item 2
At line 42 changed 3 lines
%code% Entities:
---- HR (TM) (R) (C) ... --
> blockquote 1/4 1/2 3/4
%code% Entities:
---- HR (TM) (R) (C) ... --
> blockquote 1/4 1/2 3/4
At line 47 changed one line
|< left |^ center |> right |
|< left |^ center |> right |
At line 71 added one line
At line 50 changed one line
I think it should be considered to glean some of the markup styles from Tiki Text for the next version of Creole.
I think it should be considered to glean some of the markup styles from Tiki Text for the next version of Creole.
At line 77 added one line
At line 79 added one line
At line 81 added one line
At line 83 added one line
At line 85 added one line
At line 87 added one line
At line 58 changed 2 lines
I too like the simple cell alignment control and use it regularly. (Note: I don't use spanning in Tiki Text in my situation. I like having a consistent grids in my scripts' output controlled by CSS.)
In regards to Creole, when it comes to cell spanning, considerations must be made on how empty cells span.
I too like the simple cell alignment control and use it regularly. (Note: I don't use spanning in Tiki Text in my situation. I like having a consistent grids in my scripts' output controlled by CSS.)
In regards to Creole, when it comes to cell spanning, considerations must be made on how empty cells span.
At line 95 added one line
At line 62 changed 3 lines
| |= col 1 |= col 2 |
|row 1| r1c1 | r1c2 |
|row 2| r2c1 | r2c2 |
| |= col 1 |= col 2 |
|row 1| r1c1 | r1c2 |
|row 2| r2c1 | r2c2 |
At line 101 added one line
At line 103 added one line
At line 68 changed 3 lines
| |= col 1 |= col 2 | | |= col 1 |= col 2 | | |= col 1 |= col 2 |
|row 1| r1c1 | r1c2 | vs. |row 1| r1c1 | r1c2 | vs. |row 1| r1c1 | r1c2 |
|row 2| r2c1 | | |row 2| r2c1 (spans) || |row 2| r2c1 ||
| |= col 1 |= col 2 | | |= col 1 |= col 2 | | |= col 1 |= col 2 |
|row 1| r1c1 | r1c2 | vs. |row 1| r1c1 | r1c2 | vs. |row 1| r1c1 | r1c2 |
|row 2| r2c1 | | |row 2| r2c1 (spans) || |row 2| r2c1 ||
At line 73 changed 4 lines
Maybe it should be if there's "no space" between vertical bars, it represents a NULL resulting in a SPAN. I believe this is how Tiki Text does it.
This might go against the grain for some folks whose old markup
# used || for separating cells
# who space their source-text for alignment but natural white space in cells are treated as NULLs.
Maybe it should be if there's "no space" between vertical bars, it represents a NULL resulting in a SPAN. I believe this is how Tiki Text does it.
This might go against the grain for some folks whose old markup
# used || for separating cells
# who space their source-text for alignment but natural white space in cells are treated as NULLs.
At line 118 added one line
At line 80 changed 3 lines
| |= c1 |= c2 |= c3 |= c4 |
| r1 |< lt |^ ct |+ |> rt |
| r2 | |+ |+ |+ |
| |= c1 |= c2 |= c3 |= c4 |
| r1 |< lt |^ ct |+ |> rt |
| r2 | |+ |+ |+ |
At line 87 changed 3 lines
| |= c1 |= c2 |= c3 |= c4 |= c5 |
| r1 |< lt |^+ ct| | |> rt |
| r2 |+ | | | etc | |
| |= c1 |= c2 |= c3 |= c4 |= c5 |
| r1 |< lt |^+ ct| | |> rt |
| r2 |+ | | | etc | |
At line 132 added one line
At line 134 added one line
At line 136 added one line
At line 94 changed 2 lines
If the span modifier is used, followed by any number of white space before the cell's content & markup is encountered, (ex. {{{ |<+ r8c7 ||+^ r8c9 | | }}} ) then the white space would indicate the termination of cell property's markup. The order shouldn't matter for the cell modifiers, nor if whitespace is contained in the cell to span (i.e. ignore SPs and TABs).
It would mean, the parser would have to keep track of columns when row spanning and would have to evaluate the row entirely before rendering most of the row.
If the span modifier is used, followed by any number of white space before the cell's content & markup is encountered, (ex. {{{ |<+ r8c7 ||+^ r8c9 | | }}} ) then the white space would indicate the termination of cell property's markup. The order shouldn't matter for the cell modifiers, nor if whitespace is contained in the cell to span (i.e. ignore SPs and TABs).
It would mean, the parser would have to keep track of columns when row spanning and would have to evaluate the row entirely before rendering most of the row.
At line 144 added one line
At line 146 added one line
At line 148 added one line
At line 163 added one line
At line 165 added one line
At line 167 added one line
At line 116 changed 2 lines
For the most common use-case (one term followed by one definition) users would only have to remember the ';' and not the ':'
The behavior of definition terms would be more like headings than list items, which seems to make sense also. After all, if a term is so long that multiple lines are needed, the definition list is probably not being used correctly in the first place.
For the most common use-case (one term followed by one definition) users would only have to remember the ';' and not the ':'
The behavior of definition terms would be more like headings than list items, which seems to make sense also. After all, if a term is so long that multiple lines are needed, the definition list is probably not being used correctly in the first place.
At line 175 added one line
At line 182 added one line
At line 184 added one line
At line 186 added one line
At line 188 added one line
At line 192 added one line
At line 194 added one line
At line 196 added one line
At line 134 changed one line
But for wiki markup, maybe the Perl motto is more appropriate, i.e. "there is more than one way to do it"?
But for wiki markup, maybe the Perl motto is more appropriate, i.e. "there is more than one way to do it"?
At line 202 added one line
At line 204 added one line
At line 138 changed one line
On the other hand, we leave a lot of wiggle room and flexibility of the spec -- for developers. We know that developing a wiki engine is hard already. We know that many of the engines being developed are created specifically to experiment, among other things, also with markup. We believe that the developers are experienced and knowledgeable enough to make the decisions -- after all they need to make the same kinds of decisions with other parts of the engine, not related to the markup. We don't expect each and every user to be an usability expert.
On the other hand, we leave a lot of wiggle room and flexibility of the spec -- for developers. We know that developing a wiki engine is hard already. We know that many of the engines being developed are created specifically to experiment, among other things, also with markup. We believe that the developers are experienced and knowledgeable enough to make the decisions -- after all they need to make the same kinds of decisions with other parts of the engine, not related to the markup. We don't expect each and every user to be an usability expert.
At line 210 added one line
At line 212 added one line
At line 214 added one line
At line 143 changed one line
-- StephenDay, 2007-Dec-24
-- StephenDay, 2007-Dec-24
At line 220 added one line
At line 222 added one line
At line 224 added one line
At line 226 added one line
At line 228 added one line
At line 239 added one line
At line 244 added one line
At line 246 added one line
At line 248 added one line
At line 250 added one line
At line 252 added one line
At line 254 added one line
At line 256 added one line
At line 258 added one line
At line 171 changed one line
Sometimes we want to use colon (:) in the term, requiring ~~ to quit is inconvinient. Also,
Sometimes we want to use colon (:) in the term, requiring ~~ to quit is inconvinient. Also,
At line 176 changed one line
is hard to read in source. Usrs usually cannot distinct terms and descriptions at a glance.
is hard to read in source. Usrs usually cannot distinct terms and descriptions at a glance.
At line 271 added one line
At line 278 added one line
At line 280 added one line
At line 186 changed one line
;E. M. A. C. S.
;E. M. A. C. S.
At line 189 changed one line
:Emacs Makers Are Crazy Sickos
:Emacs Makers Are Crazy Sickos
At line 287 added one line
At line 192 changed one line
{{{
{{{
At line 293 added one line
At line 295 added one line
At line 299 added one line
At line 301 added one line
At line 303 added one line
At line 305 added one line
At line 311 added one line
At line 313 added one line
At line 317 added one line
At line 319 added one line
At line 321 added one line
At line 324 added one line
At line 326 added one line
At line 328 added one line
At line 330 added one line
At line 332 added one line
At line 334 added one line
At line 336 added one line
At line 338 added one line
At line 340 added one line
At line 342 added one line
At line 344 added one line
At line 346 added one line
At line 228 changed one line
The "talk" link is not visible for new visitors, and one of the wiki rules is "be bold" - so please don't be annoyed.
The "talk" link is not visible for new visitors, and one of the wiki rules is "be bold" - so please don't be annoyed.
At line 353 added one line
Version Date Modified Size Author Changes ... Change note
105 02-Apr-2008 10:50 19.726 kB ChristophSauer to previous restored locked version
104 02-Apr-2008 10:01 0.06 kB 86.96.226.14 to previous | to last
103 02-Apr-2008 08:50 19.668 kB ChristophSauer to previous | to last unlocked
102 13-Mar-2008 09:36 19.726 kB ChristophSauer to previous | to last
101 13-Mar-2008 09:36 19.704 kB ChristophSauer to previous | to last
« This page (revision-105) was last changed on 02-Apr-2008 10:50 by ChristophSauer