(anonymous guest) (logged out)

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

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

With the single pipe rule for tables (i.e. "all cells separated by single pipes"), are table headings now implied? It's not clear to me what the recommended XHTML for table headings should be. Is it really a <td> tag as recommeded? Or should it be a <th> tag...

<table>
<tr>
<th>Heading Col 1</th>
<th>Heading Col 2</th>
</tr>
<tr>
<td>Cell 1.1</td>
<td>Cell 1.2</td>
</tr>
<tr>
<td>Cell 2.1</td>
<td>Cell 2.2</td>
</tr>
</table>

-- MarkWharton, 2006-12-10

It cannot be known whether headers are on the top or the left side or both, so headers are not implied.

-- Chuck Smith, 2006-12-11

I'd like to suggest some additions/changes which are in line with the currently proposed standard:

Additions#

Underlined text

Creole: __Underlined text__ (two underscores)

Proposed XHTHML: <span class="underlined"> </span>

Stricken text

Creole: --Stricken text--

Proposed XHTML: <del> </del>

Superscripted text

Creole: ^^This is superscripted text^^

Proposed XHTML: <sup> </sup>

Subscripted text

Creole: ~~This is subscripted text~~

Proposed XHTML: <sub> </sub>

No wiki markup

While I realise that you could use the {{{ / <pre> }}} code for this, people might not want to have some markup parsed without it being interpreted as "code". I would like to suggest using: {{{ ==no markup== }}} for simple no markup sections. {{{ {{code}} }}} on a line of their own would be more logical for blocks of {{{ <code> }}}. It would also be more in line with the rest of Creole if these were double instead of tripple, while another option might be: {{{ >> preformatted << }}} for regular preformatted text? !!Changes __Tables__ I'd like to suggest a small addition to the table definition. To define something as a header entry, we could use the DocuWiki syntax with a minor modification: {{{ |^ header cell |^ header cell | | normal cell | normal cell | |^ header cell | normal cell | | normal cell | normal cell | }}} Proposed XHTML: {{{ <th> </th> }}} __Headlines__ Is it possible to change the headlines standard to an exclamation mark? Or at least make it optional? A lot of people seem to find exclamation marks more logical. {{{ !Level 1 headline! !!Level 2 headline!! etc. }}} -- MartijnVanDerKleijn, 2006-12-11 Thanks for your interest in WikiCreole and for your suggestions. I think that some of them are helpful, but many other suggest a misunderstanding. WikiCreole is not supposed to be a second HTML, a standard embracing all wiki markup and defining how the wiki markup should be designed. There were several projects like this and they all failed. Instead, we want WikiCreole to be a small subset of wiki markup, the absolutely smallest subset of features, that can be used to contribute to any wiki site with unknown (yet) markup. It's also a format for writing articles in such a way, that you can put them on any wiki, no matter what engine it uses. That's why WikiCreole must be limited. Another problem is the choice of markup. Often there are little "technical" differences, and the choice of markup becomes a [http://www.c2.com/cgi/wiki?BikeShed|BikeShed] -- literally __everyone__ has their own idea. That's why we always try to explain the reasons behind chosing certain markup -- often simply selecting the more widespread one. Also note, that the exact rendering of the page is outside the scope of the WikiCreole specification. Whether ''emphasis'' or __strong__ is rendered as italic, underlined, colored, inverted, scrolled, blinking or just insanely huge text -- is irrelevant. Same goes for {{{escaped text}}} rendered as monospaced or not -- I think that Creole even suggests that it shoudn't be monospaced. It's very hard to respond to this kind of proposition made in bulk -- could you please put the comments on respective talk pages, together with some explanations and rationales behind them, so that they can be discussed together with other propositions? -- [RadomirDopieralski], 2006-12-11 I have my problems with a table with single pipes and links like [Go to my page|MyBigPage]. How should this be distinguished ? And why should {{{ === **not** //parsed// === }}} not be parsed? This is a correct heading. -- JoachimStolberg I'm very surprised at the (X)HTML examples of that "not parsed" in the specs -- because I seem to remember we agreed that text inside headings is not parsed. They are also in conflict with the [Headings] page, on which there is the version we agreed on. As I check the previous versions of spec, I can see the (X)HTML examples of "not parsed" headings are also wrong on them. I didn't notice it before. What's going on? And if it's intentional -- what should be the effect of __bold__ in already "weight:bold" heading? As for hard-to-parse markup, I'm really, really think that Creole should be designed so that it's easy to adopt in new wiki engines -- so in particular, it should avoid hard to parse or ambigous markup and special cases. -- [RadomirDopieralski], 2006-12-13 Still no good... Now the HTML tags are not inserted, but the markup is removed -- which means that the parser needs to still parse headings, and apply the rules for '' and __, just with different result than in paragraph. I think such a special case is worse than allowing bold and italics inside headings.__'' Why can't we use the example on [Headings]? -- [RadomirDopieralski], 2006-12-13 Sorry for my new comments, but there are still inconsistences: * in the chapter headings (spec): " Bold, italics, links and preformatted text are allowed in headings" * between the page [News] [{ImagePro src='' }] and the Spec [{ImagePro src='' caption='Heading Col 1 ' }] ** JoachimStolberg, 2006-12-13 Thanks for catching this. I fixed the spec, but I think the news is ok -- after all, it __is__ how the proposition looked like at the time of posting that news item. -- [RadomirDopieralski], 2006-12-14 I think having bold, italics, etc in headings is fine, it doesn't create invalid XHTML standard, and makes parsing simpler. Keeping to either all creole markup is enabled, or disabled (preformatted block/inline) seems the simplest way to go. Not allowing bold, italics etc but allowing images in headings just seems an unnecessary complexity to a parser, for no real benefit. -- [JaredWilliams] 2006-12-14 Images in headings??? Where? [ checks the specs and the discussions ] Ok, now that's a straight fantasy. On the [Headings] page there are even examples of unacceptable (in Creole) combinations, and they include links and images inside headings. So it's as consistent as it gets -- ''no markup in headings''. This makes it extremely easy to fish headings with a single regular expression, without any need for a stack or multi-pass parsing. Besides, what ''semantic'' does an image in heading have? Sure, there are those books with illuminations and stuff -- but that's rather a question of style. Smileys? Non-unicode symbols maybe? -- [RadomirDopieralski], 2006-12-14 My apologies, I think I've been reading too much about various markups or something. Just reviewing my own creole parser written a while back, and it does not parse markup within headings. But as for why would want to have images inside headings, if images are not shown on the client, then the alternate text may need to be a heading. Whats also confusing the issue, is that I've expanded the meaning of {{{ {{ }} }}} to perform general inclusion/transclusion. For other things like csv, plain text, wiki pages (or parts of), and google maps. So thinking wether inclusion into headings should be allowed. -- [JaredWilliams], 2006-12-14 Well, Creole is supposed to be extensible -- so you can create additional rules like that and it's still compatible. But I think we shoudn't require csv parsing or concrete ways of handling transclusion from the wiki engines -- they are just so different in this regard. Maybe there could be "recommendations" saying that *if* the engine has it, the markup should be like this... -- [RadomirDopieralski], 2006-12-14

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 14-Dez-2006 14:02 by 150.254.78.35.