Talk.Creole0.6 seemd to indicate that it wouldn't be a good idea to make the escape character an addition. That's still my opinion.
I have difficulty in understanding how the decision process works, especially since last week.
-- YvesPiguet, 2007-Apr-9
Isn't embedding the style directly in the generated (x)html a mark of bad, uhm, style? I mean, it should be <div class="mail-quote"> rather than <div style="some arbitrary presentation that might not fit the overall style of the site">. Then again, there is the question of users using browsers that are not CSS-enabled -- they should at least see that they are missing something.
I think that the spec should show a "good" solution, or just don't show any at all if no good solution exists. I see several possibilities:
- only say that the text should be rendered as indented,
- only say thet the text should be marked as a quotation, in any way, not necessarily by indentation (some styles might use colors or colored bars),
- generate the quted parts as a blockquote (with a class),
- generate the quoted parts as a single-element, unordered list with special class for styling (with a class),
- generate the quoted parts as a single-element definition list with empty 'term' part,
- generate the quoted parts as a div, but with the '>' left in the text, and removed with style,
All of these solutions have their pros and cons, as far as I can tell none is 100% "correct".
-- RadomirDopieralski, 2007-06-12
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.
-- ChuckSmith, 2007-Jun-12
I've replaced "recommended" with "possible" for the XHTML with embedded style. Maybe this should be done everywhere. I agree that embedded style isn't very nice; however, the simplest, shortest rendition is sometimes more informational than clean output following W3 advices, which recommends against <i> and <b>.
-- YvesPiguet, 2007-Jun-12
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?
-- JasonBurnett, 2007-Sep-04
If it's going to be included in Creole, I'd prefer the same syntax for captions for tables and images. See the recent discussion at Talk.Images.
-- YvesPiguet, 2007-Sep-04
It's interesting that other people have had the same pursuit of creating a standardized Wiki markup. I've been using Tiki Text
in my Perl scripts for some time. Overall, WikiCreole is quite similar to Tiki Text in markup, except Creole doubles the Wiki markup to make sure it's markup.
Here's my Tiki Text Cheat Sheet to illustrate it:
My TikiText Cheat Sheet
Formatting: Links:
!1 h1 CamelCase
!6 h6 [Text]:URL
*bold* http://cpan.org
/italics/ {alt text}:IMG-URL
*/both/* ACRONYM(ACRONYM desc)
+inserted+
-strike- Lists:
^superscript^ * Unordered list
~subscript~ # Ordered list
"quote" ; Definition
@cite@ : item 1
SP or Tab pre : item 2
% code
%code% Entities:
---- HR (TM) (R) (C) ... --
> blockquote 1/4 1/2 3/4
Tables:
|!heading 1|heading 2|heading 3|
|< left |^ center |> right |
|^ centered across 3 columns ||| (empty cells span)
I think it should be considered to glean some of the markup styles from Tiki Text for the next version of Creole.
In particular, the table cell justification, -strike through-, +inserted+, some form of quoting, maybe even @cite@. Obviously, if we double the markup for the Creole standard, --strike--, ++insert++ , the style consistency would be maintained.
In addition, having Tiki Text is under Perl's Artistic Creative license. Someone would probably need to check with Timothy Appnel for his blessing to use, extract and modify anything of his. I wouldn't think any Perl programmer using the Artistic license would have a problem with it.
-- MarkStinson, 2007-Nov-9
I especially like the table justification and cell spanning, very useful, which wouldn't conflict with Creole 1.0. I'd rather not include any entity in the core of Creole, though.
-- YvesPiguet, 2007-Nov-9
Yes. Table justification is nice, just the ^ would conflict with other wiki markup (I think e.g. DokuWiki) which uses it as table heading markup. I don't mind too much though, since Mixed Mode seems to become very unlikely for most engines anyway...
-- ChristophSauer, 2007-Nov-09 12:46 (CET)
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.
If you have empty cells in the beginning of a row, such as a column header, it shouldn't necessarily span:
| |= col 1 |= col 2 | |row 1| r1c1 | r1c2 | |row 2| r2c1 | r2c2 |
but, if trailing cells are empty, should it span automatically unless you put in a space or ?
| |= 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 ||(examples of with and without natural white space, and source-text alignment.)
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.
Using another cell markup might be in order to determine if a cell should be spanned into the next cells until the next markup command or content is encountered. If, for this example, + was the markup command to span/join cells.
Should it add the indicated cell to the previous on a per cell basis ?
| |= c1 |= c2 |= c3 |= c4 | | r1 |< lt |^ ct |+ |> rt | | r2 | |+ |+ |+ |Should it be modifier to skip until the next markup command or content is encountered?
r1c2 spans until r1c5; r2c1 spans until plain text appears in r2c4; but r2c5 is empty cell.
| |= c1 |= c2 |= c3 |= c4 |= c5 | | r1 |< lt |^+ ct| | |> rt | | r2 |+ | | | etc | |
The logic would still need to be determined due to some potentially confusing or illogical combinations.
To maintain consistency with the alignment markup, if a span modifier is used, it must by a continuation of the "|" cell indicator without conflicting with existing or proposed markup (if markup such as ++insert++ is considered) .
Update, 2007-Nov-13
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.
Column spanning hasn't been addressed yet but I don't see that as frequently in most Wiki markup.
-- MarkStinson, 2007-Nov-12
I would like to suggest that the ":" be optional for the first item of a definition. So the following two blocks would be equivalent, with the second being somewhat cleaner:
; Term : definition ; Term 2 : definition
; Term definition ; Term 2 definitionThis means a newline ends each <dt>, which seems reasonable as most of the time one line is enough.
-- StephenDay, 2007-Nov-12
Why would you do that? If "most of the time" is correct, which I agree with, then the exception wouldn't be supported anymore with lines of bounded length. And the more you relax the rules, the less readable and the more risky the markup becomes; see for instance past discussion about bullet lists and spaces after the stars.
-- YvesPiguet, 2007-Nov-13
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.
I first thought about this when implementing it in Creoleparser.py, where it just seemed that rendering:
; Term definition ; Term 2 definition
as two terms without definitions, was not very intuitive.
-- StephenDay, 2007-Nov-13