Revision history for WikkaExtensibleMarkup


Revision [18871]

Last edited on 2008-01-28 00:13:01 by NilsLindenberg [Modified links pointing to docs server]
Additions:
Extending the number of [[Docs:FormattingRules formatting rules]] to include [[WantedFormatters new formatters]] looks like a necessary step for future development. Yet, the number of available combinations of symbols that might be good candidates for future formatters is very limited. The requirement that should be met by a specific formatter are the following:
Deletions:
Extending the number of [[FormattingRules formatting rules]] to include [[WantedFormatters new formatters]] looks like a necessary step for future development. Yet, the number of available combinations of symbols that might be good candidates for future formatters is very limited. The requirement that should be met by a specific formatter are the following:

Revision [14381]

Edited on 2006-05-29 17:47:49 by NilsLindenberg [def lists added to trac]
Additions:
[[Ticket:194]]

Revision [8748]

Edited on 2005-05-31 12:35:37 by JavaWoman [extra category]
Additions:
CategoryDevelopmentMarkup CategoryDevelopmentDiscussion
Deletions:
CategoryDevelopmentMarkup

Revision [8747]

Edited on 2005-05-31 12:23:34 by JavaWoman [reply to Nils about inline comments]
Additions:
~~~~~&It is if you indent them extra - see how I fixed it ;-) --JW

Revision [8744]

Edited on 2005-05-31 12:16:35 by NilsLindenberg [reply to jw]
Additions:
~~~~&I had added a sentence about that above, but when you use inline-comments for your whole text it is not that easy to find the comments :) --Nils

Revision [8743]

Edited on 2005-05-31 12:14:51 by JavaWoman [smal fix for inline comment]
Additions:
~~~&On #wikka we came up with the idea that two symbols might actually be better than symbol and letter. So what about "~??" and "~?!" --Nils
Deletions:
~~&On #wikka we came up with the idea that two symbols might actually be better than symbol and letter. So what about "~??" and "~?!" --Nils

Revision [8740]

Edited on 2005-05-31 12:09:40 by JavaWoman [comment re: definition list syntax]
Additions:
~~~&I just had a little discussion about this with NilsLindenberg on #wikka - we came up with more "distinctive" alternatives: **##~??##** for the term to be defined and **##~?!##** for the description (question - answer); both ? and ! are also equally "high" characters, making it easier to see them as a unit. --JW

Revision [8738]

Edited on 2005-05-31 12:00:53 by DarTar [Replying to JW on definitions]
Additions:
~~& It's a nice idea. I agree on everything except the specific convention (**##""~?t""## / ##""~?d""##**) you suggest to use to distinguish terms from descriptions. I think this convention fails to address the //distinctiveness// principle, producing strange strings like **##""?danyone""##**, **##""~?tMSG""##** about which it is difficult to say where markup stops and where content begins. This is one of the reasons why I suggested that alphanumeric characters used to specify properties be wrapped in brackets - like ##**::(properties) text ::**##: this helps avoid confusions between markup and content. Maybe just using: **##""~?""##** for terms and **##""~??""##** for definitions (or maybe **##""~?(t)""## / ##""~?(d)""##**) would do the job. My 2 Cents -- DarTar
Deletions:
~~& It's a nice idea. I agree on everything except the specific convention (**##""~?t""## / ##""~?d""##**) you suggest to use to distinguish terms from descriptions. I think this convention fails to address the //distinctiveness// principle, producing strange strings like **##""?danyone""##**, **##""~?tMSG""##** about which it is difficult to say where markup stops and where content begins. This is one of the reasons why I suggested that alphanumeric characters used to specify properties be wrapped in brackets - like ##**::(properties) text ::**##: this helps avoid confusions between markup and content. Maybe just using: **##""~?""##** for terms and **##""~??""##** for definitions (or maybe **##""~?(t)""## / ##""~?(d)""##**) would do the job. My 2 Cents -- DarTar

Revision [8737]

Edited on 2005-05-31 12:00:23 by DarTar [Replying to JW on definitions]
Additions:
~~& It's a nice idea. I agree on everything except the specific convention (**##""~?t""## / ##""~?d""##**) you suggest to use to distinguish terms from descriptions. I think this convention fails to address the //distinctiveness// principle, producing strange strings like **##""?danyone""##**, **##""~?tMSG""##** about which it is difficult to say where markup stops and where content begins. This is one of the reasons why I suggested that alphanumeric characters used to specify properties be wrapped in brackets - like ##**::(properties) text ::**##: this helps avoid confusions between markup and content. Maybe just using: **##""~?""##** for terms and **##""~??""##** for definitions (or maybe **##""~?(t)""## / ##""~?(d)""##**) would do the job. My 2 Cents -- DarTar
Deletions:

Revision [8734]

Edited on 2005-05-31 11:48:09 by NilsLindenberg [comment on definition lists]
Additions:
~~&On #wikka we came up with the idea that two symbols might actually be better than symbol and letter. So what about "~??" and "~?!" --Nils

Revision [8733]

Edited on 2005-05-31 11:34:39 by NilsLindenberg [headers]
Additions:
===General-purpose tag-like markup:===
===General-purpose class-driven markup:===
==Markup closed by end-of-line==
==Definition lists==
Deletions:
==General-purpose tag-like markup:==
==General-purpose class-driven markup:==

Revision [8732]

Edited on 2005-05-31 10:30:44 by JavaWoman [definition list proposal (ypot)]
Additions:
</dl>
</dl>

Revision [8731]

Edited on 2005-05-31 10:27:12 by JavaWoman [Definition list proposal]
Additions:
~&Wikka currently supports **unordered lists** (with inline-comments as a special case) and **ordered lists**. What's missing is **definition lists**. Building on the principles that:
~~-it should follow the same markup mechanisms as used for other lists;
~~-other lists start with one or more ""~"" (or tabs), followed by a **symbol** (to distinguish it from simply "indented text");
~~-only the //items// are defined; the formatter takes care of wrapping a list within its <ul> or <ol> tags;
~&I have the following proposal for a definition list syntax:
~~-unlike ordered and unordered lists, definition lists have **two types of items**: definition terms and definttion descriptions
~~-as with the other list types, an item is started with one or more ""~"" (or tabs) indicating "level"
~~-use a symbol to mark the specific type of list (I propose "**##?##**")
~~-supplement the symbol with a "**##t##**" or a "**##d##**" to indicate which type of item it is
~&--- Definition lists (or rather the descriptions) can be nested, so an example might look like this: %%
~?t/msg
~?d
~~?tPurpose:
~~?dSends a private message to a nick or a command to a service
~~?tWho:
~~?danyone
~~?tSyntax:
~~?d
~~~?tMSG <nick> <message>
~~~?dsends a private message to <nick>
~~~?tMSG <service> <command> [<parameters>]
~~~?dsends a command to a service
~~?tHelp:
~~?d/help msg
~~?tExamples:
~~?d/msg JavaWoman hello there
~~?d/msg ChanServ op #wikka%% ---
~&The formatter should then translate this into: %%(html4strict)
<dl>
<dt>/msg</dt>
<dd>
<dl>
<dt>Purpose:</dt>
<dd>Sends a private message to a nick or a command to a service</dd>
<dt>Who:</dt>
<dd>anyone</dd>
<dt>Syntax:</dt>
<dd>
<dl>
<dt>MSG <nick> <message></dt>
<dd>sends a private message to <nick></dd>
<dt>MSG <service> <command> [<parameters>]</dt>
<dd>sends a command to a service</dd>
<dl>
</dd>
<dt>Help:</dt>
<dd>/help msg</dd>
<dt>Examples:</dt>
<dd>/msg JavaWoman hello there</dd>
<dd>/msg ChanServ op #wikka</dd>
</dl>
</dd>
</dl>%% ---
~&Which would then be rendered something like this (depending on styling, of course):
~&--- ""<dl>
<dt>/msg</dt>
<dd>
<dl>
<dt>Purpose:</dt>
<dd>Sends a private message to a nick or a command to a service</dd>
<dt>Who:</dt>
<dd>anyone</dd>
<dt>Syntax:</dt>
<dd>
<dl>
<dt>MSG <nick> <message></dt>
<dd>sends a private message to <nick></dd>
<dt>MSG <service> <command> [<parameters>]</dt>
<dd>sends a command to a service</dd>
<dl>
</dd>
<dt>Help:</dt>
<dd>/help msg</dd>
<dt>Examples:</dt>
<dd>/msg JavaWoman hello there</dd>
<dd>/msg ChanServ op #wikka</dd>
</dl>
</dd>
</dl>"" ---
~&I'd say our list syntax is pretty extensible ;-) --JavaWoman

Revision [8650]

Edited on 2005-05-29 08:42:34 by JavaWoman [move to subcategory]
Additions:
CategoryDevelopmentMarkup
Deletions:
CategoryDevelopment

Revision [7210]

Edited on 2005-04-12 02:35:06 by MonstoBrukes [move to subcategory]
Additions:
~&IMO it's these kinds of very simple markups that set a wiki apart from BB's and W3C approved markup. The trick tho is to identify the most used markups and give them the most intuitive wiki tags/markup, and leave everything else (<th> tag for example) to html inclusion. having the wiki do what it's supposed to do very cleanly and intuitively is better than having a huge markup page when 90% of the ppl will only use half the tags --MonstoBrukes
Deletions:
~&IMO it's these kinds of very simple markups that set a wiki apart from BB's and W3C approved markup. The trick tho is to identify the most used markups and give them the most intuitive wiki tags/markup, and leave everything else (<th> tag for example) to html inclusion. having the wiki do what it's supposed to do very cleanly and intuitively is better than having a huge markup page when 90% of the ppl will only use half the tags
:::

Revision [7209]

Edited on 2005-04-12 02:34:33 by MonstoBrukes [move to subcategory]
Additions:
~&IMO it's these kinds of very simple markups that set a wiki apart from BB's and W3C approved markup. The trick tho is to identify the most used markups and give them the most intuitive wiki tags/markup, and leave everything else (<th> tag for example) to html inclusion. having the wiki do what it's supposed to do very cleanly and intuitively is better than having a huge markup page when 90% of the ppl will only use half the tags
:::
Deletions:
~&
~&IMO it's these kinds of very simple markups that set a wiki apart from BB's and W3C approved markup. The trick tho is to identify the most used markups and give them the most intuitive wiki tags/markup, and leave everything else (<th> tag for example) to html inclusion. having the wiki do what it's supposed to do very cleanly and intuitively is better than having a huge markup page when 90% of the ppl will only use half the tags :::

Revision [7208]

Edited on 2005-04-12 02:33:57 by MonstoBrukes [move to subcategory]
Additions:
~&I'm not sure how you'd make it fit into your definitions above, but i you've missed the 'single line' markup style that is only closed by the end of line. for this comment, i'm using ##~&## which is automatically and **only** closed by a <br> (or whatever).
~&
~&IMO it's these kinds of very simple markups that set a wiki apart from BB's and W3C approved markup. The trick tho is to identify the most used markups and give them the most intuitive wiki tags/markup, and leave everything else (<th> tag for example) to html inclusion. having the wiki do what it's supposed to do very cleanly and intuitively is better than having a huge markup page when 90% of the ppl will only use half the tags :::

Revision [6152]

Edited on 2005-02-18 16:56:19 by JavaWoman [minor]
Additions:
~&I originally proposed using the ##(...)## syntax to add **properties** to an element, as we're already doing now with code blocks where we can indicate language and line number as properties (which the formatter hands off to GeSHi for interpretation): that's not a class at all. Since generally every Wiki markup element does result in an XHTML **element**, this "properties" syntax can be applied to any and all Wikka markup elements. Only, keeping in mind that we don't want a comlpete "layout engine" but keep things simple, we could allow (element-dependent) pre-defined "keywords". Thus we could have %%::^(red)hot^::%% resulting in %%(html4strict)<sup class="red">hot</sup>%% where "red" is a **predefined** class in the default stylesheet. No need for %%::(red)::^hot^::::%% (but even if you do that, it should result in the **same** XHTML - not a ##span## wrapped around a ##sup##!).
~&So, I'd like to see ##**::(properties) text ::**## (for general-[purpose inline markup) and ##**:::(properties) text :::**## (for general-purpose block markup); whether they'd result in separate span or div elements, or the properties applied to already-existing elements should depend on where they are used. (Yes, we do need a more "intelligent" formatter for all this.) IMO, "class" is too limiting - what you need is **properties** that the formatter knows how to interpret. ---
Deletions:
~&I originally proposed using the ##(...)## syntax to add **properties** to an element, as we're already doing now with code blocks where we can indicate language and line number as properties (which the formatter hands off to GeSHi for interpretation): that's not a class at all. Since generally every Wiki markup element does result in an XHTML **element**, this "attribute"" syntax can be applied to any and all Wikka markup elements. Only, keeping in mind that we don't want a comlpete "layout engine" but keep things simple, we could allow (element-dependent) pre-defined "keywords". Thus we could have %%::^(red)hot^::%% resulting in %%(html4strict)<sup class="red">hot</sup>%% where "red" is a **predefined** class in the default stylesheet. No need for %%::(red)::^hot^::::%% (but even if you do that, it should result in the **same** XHTML - not a ##span## wrapped around a ##sup##!).
~&So, I'd like to see ##**::(properties) text ::**## (for general-[purpose inline markup) and ##**:::(properties) text :::**## (for general-purpose block markup); whether they'd result in separate span or div elements, or the properties applied to already-existing elements should depend on where they are used. (Yes, we do need a more "intellignet" formatter for all this.) IMO, "class" is too limiting - what you need is **properties** that the formatter knows how to interpret. ---

Revision [6151]

Edited on 2005-02-18 16:54:21 by JavaWoman [reaction (plus layout)]
Additions:
~&This is a nice idea as it would allow to cover more formatters than what we have right now.
~&The drawback is that it would even more go far from a wiki standardization. And the users will have to learn a new syntax.
~&So my proposal would be something the users can change as they wish: Wikka defines right now ""**"" to be the bold tag, you propose a new way that could drive to ::b for the same thing, others could prefer to use <bold>: so we should rather imagine something that can be configured by the users. Moreover, this would facilitate the migration fron other wikis to wikka.
~&I am pretty sure that the standard of the killer wiki will anyway be wysiwyg in the future. -- ChristianBarthelemy
~&While I welcome the idea (we have had discussions about this a few times on #wikka already) it ... well, it needs some work. :) Especially the bit about ##span##s and blocks is a bit muddled (sorry). For instance, a span **can** be repositioned; and if you want to add a class (or other attribute) to something that already is an element by itself, you don't use a span, but add the attribute directly to that element.
~&While end users may not need to know, in designing a formatting syntax and the fornatter to handle it, it's important to keep in mind just how Wikka (wiki) syntax maps to XHTML. For instance, any **element** can be repositioned, but only blocks can be given a width; and you cannot wrap a block in an inline element. A formatter must ensure that incorrect usage (even in the wiki syntax) is ignored (or corrected) so that we always produce valid XHTML. ---
~
~&I originally proposed using the ##(...)## syntax to add **properties** to an element, as we're already doing now with code blocks where we can indicate language and line number as properties (which the formatter hands off to GeSHi for interpretation): that's not a class at all. Since generally every Wiki markup element does result in an XHTML **element**, this "attribute"" syntax can be applied to any and all Wikka markup elements. Only, keeping in mind that we don't want a comlpete "layout engine" but keep things simple, we could allow (element-dependent) pre-defined "keywords". Thus we could have %%::^(red)hot^::%% resulting in %%(html4strict)<sup class="red">hot</sup>%% where "red" is a **predefined** class in the default stylesheet. No need for %%::(red)::^hot^::::%% (but even if you do that, it should result in the **same** XHTML - not a ##span## wrapped around a ##sup##!).
~&So, I'd like to see ##**::(properties) text ::**## (for general-[purpose inline markup) and ##**:::(properties) text :::**## (for general-purpose block markup); whether they'd result in separate span or div elements, or the properties applied to already-existing elements should depend on where they are used. (Yes, we do need a more "intellignet" formatter for all this.) IMO, "class" is too limiting - what you need is **properties** that the formatter knows how to interpret. ---
~
~&Finally (@Christian), as I see it, this proposal is not for a //replacement// of our current Wikka syntax, but for a method to //extend// it in a way that's consistent with what we already have (e.g., the "everything twice" principle to indicate a "tag" and the ##(...)## notation to indicate properties for code blocks), without painting ourselves into a corner when we want to add more "tags" but have run out of easily-typed symbols to do so. Even ##::...::## is building on already-existing syntax (for "clearing" floated blocks). We still have some symbols available, and should use those wisely - in particular using || for //some// kind of table markup (which would also require **properties** to be defined) would fit in with what's sort of conventional with what other wiki engines are using for table markup.
~&That's it for now - I've probably forgotten a few things, which I'll add later. :) --JavaWoman
Deletions:
This is a nice idea as it would allow to cover more formatters than what we have right now.
The drawback is that it would even more go far from a wiki standardization. And the users will have to learn a new syntax.
So my proposal would be something the users can change as they wish: Wikka defines right now ""**"" to be the bold tag, you propose a new way that could drive to ::b for the same thing, others could prefer to use <bold>: so we should rather imagine something that can be configured by the users. Moreover, this would facilitate the migration fron other wikis to wikka.
I am pretty sure that the standard of the killer wiki will anyway be wysiwyg in the future. -- ChristianBarthelemy

Revision [6137]

Edited on 2005-02-18 11:16:12 by ChristianBarthelemy [Thinking out of the box]
Additions:
This is a nice idea as it would allow to cover more formatters than what we have right now.
The drawback is that it would even more go far from a wiki standardization. And the users will have to learn a new syntax.
So my proposal would be something the users can change as they wish: Wikka defines right now ""**"" to be the bold tag, you propose a new way that could drive to ::b for the same thing, others could prefer to use <bold>: so we should rather imagine something that can be configured by the users. Moreover, this would facilitate the migration fron other wikis to wikka.
I am pretty sure that the standard of the killer wiki will anyway be wysiwyg in the future. -- ChristianBarthelemy

Revision [6136]

Edited on 2005-02-18 11:14:35 by DarTar [Changing terminology to avoid confusion]
Additions:
The choice of using ##**::**## for span's is meant to suggest that this markup produces a result similar to tag-like markup, i.e. it results in formatted text, while ##**:::**## results in blocks that can be repositioned, added a border etc.
Deletions:
The choice of using ##**::**## for span's is meant to suggest that this markup works in the same way as tag-like markup, i.e. it results in formatted text, while ##**:::**## results in blocks that can be repositioned, added a border etc.

Revision [6135]

Edited on 2005-02-18 11:13:12 by DarTar [Changing terminology to avoid confusion]
Additions:
==A. tag-like markup==
==B. Class-driven markup ==
==C. Pseudo-markup==
==General-purpose class-driven markup:==
This syntax is consistent with the existing code formatters and could be used to format other customizable CSS-driven content.
~-on the one hand, this markup is less intuitive since it requires the user to learn a //textual tag// instead of an //iconic// sequence of symbols: it would be extremely user-unfriendly to use a markup like this for basic formatting rules like bold, italic, small caps etc.; it would also be difficult to make sense of what markup is being closed in the case of nested markup.
Notice that I propose two distinct class-driven markup models, the first resulting into ##<span>## markup, the second into ##<div>## markup.
The choice of using ##**::**## for span's is meant to suggest that this markup works in the same way as tag-like markup, i.e. it results in formatted text, while ##**:::**## results in blocks that can be repositioned, added a border etc.
Deletions:
==A. Tag-like markup==
==B. Block markup ==
==C. Pseudo-formatters==
==General-purpose block markup:==
This syntax is consistent with the existing code block formatters and could be used to format other block-oriented content.
~-on the one hand, this markup is less intuitive since it requires the user to learn a textual tag instead of a meaningful or iconic sequence of symbols: it would be extremely user-unfriendly to use a markup like this for basic formatting rules like bold, italic, small caps etc.; it would also be difficult to make sense of what markup is being closed in the case of nested markup.
Notice that I propose two distinct block markup models, the first resulting into ##<span>## markup, the second into ##<div>## markup.
The choice of using ##**::**## for span's is meant to suggest that this markup works in the same way as tag-like markup, i.e. it results in formatted text, while ##**:::**## results in blocks that can be positioned, added a border etc.

Revision [6132]

Edited on 2005-02-18 10:22:49 by DarTar [Opening a discussion]
Additions:
~-**Distinctiveness** --- good markup should be distinctive enough to avoid conflicts with content: --- e.g.: ##**vv text vv**## is a bad solution since ##**vv**## is a sequence that is likely to occur in many natural languages and hence create conflicts between content and markup;
Deletions:
~-**Distinctiveness** --- good markup should be distinctive enough to avoid conflicts with content: --- e.g.: ##**vv text vv**## is a bad solution since **vv** is a sequence that is likely to occur in many natural languages and hence create conflicts between content and markup;

Revision [6131]

Edited on 2005-02-18 10:22:25 by DarTar [Opening a discussion]
Additions:
~-**Distinctiveness** --- good markup should be distinctive enough to avoid conflicts with content: --- e.g.: ##**vv text vv**## is a bad solution since **vv** is a sequence that is likely to occur in many natural languages and hence create conflicts between content and markup;
Deletions:
~-**Distinctiveness** --- good markup should be distinctive enough to avoid conflicts with content: --- e.g.: ##**.. text ..**## is a bad solution since **..** is a sequence that is likely to occur in natural languages;

Revision [6130]

The oldest known version of this page was created on 2005-02-18 10:20:23 by DarTar [Opening a discussion]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki