(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 3 added one line
At line 6 added one line
At line 8 added one line
At line 10 added one line
At line 18 added one line
At line 20 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 26 added one line
At line 28 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 34 added one line
At line 36 added one line
At line 38 added one line
At line 40 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 67 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 73 added one line
At line 75 added one line
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 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 91 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 97 added one line
At line 99 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 114 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 128 added one line
At line 130 added one line
At line 132 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 140 added one line
At line 142 added one line
At line 144 added one line
At line 159 added one line
At line 161 added one line
At line 163 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 171 added one line
At line 178 added one line
At line 180 added one line
At line 182 added one line
At line 184 added one line
At line 188 added one line
At line 190 added one line
At line 192 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 198 added one line
At line 200 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 206 added one line
At line 208 added one line
At line 210 added one line
At line 143 changed one line
-- StephenDay, 2007-Dec-24
-- StephenDay, 2007-Dec-24
At line 216 added one line
At line 218 added one line
At line 220 added one line
At line 222 added one line
At line 224 added one line
At line 235 added one line
At line 240 added one line
At line 242 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 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 267 added one line
At line 274 added one line
At line 276 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 283 added one line
At line 192 changed one line
{{{
{{{
At line 289 added one line
At line 291 added one line
At line 295 added one line
At line 297 added one line
At line 299 added one line
At line 301 added one line
At line 307 added one line
At line 309 added one line
At line 313 added one line
At line 315 added one line
At line 317 added one line
At line 320 added one line
At line 322 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 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 349 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