At line 128 changed one line |
It does not matter, and in fact, "img" is a violation of the basic principle of making the markup language-independent. You see, if you see image inclusion as a just a special case of "transclusion", you'll see that templates and images can be embedded using ''the exactly same syntax''. It's just up to the WikiEngine to figure out what the media type is, and include it appropriately. MediaWiki just puts all the images in the "Image:" -namespace, which makes it really easy for MediaWiki to support this. |
(a) It does not matter, and in fact, "img" is a violation of the basic principle of making the markup language-independent. You see, if you see image inclusion as a just a special case of "transclusion", you'll see that templates and images can be embedded using ''the exactly same syntax''. It's just up to the WikiEngine to figure out what the media type is, and include it appropriately. MediaWiki just puts all the images in the "Image:" -namespace, which makes it really easy for MediaWiki to support this. |
At line 130 changed one line |
In fact, I believe this syntax was suggested by BrionWebber, the lead developer of MediaWiki. And if he doesn't think there's a problem, I'm inclined to agree ;-) |
(b) In fact, I believe this syntax was suggested by BrionWebber, the lead developer of MediaWiki. And if he doesn't think there's a problem, I'm inclined to agree ;-) |
At line 138 added 10 lines |
In reply to (a) above: my comment was made in accordance with the [goals] stated on this site: the most important goal was being "collision free", whereas the "avoiding Text Tags (principle of I18N)" goal was only 12th in priority. |
|
In reply to (b) above: I should have explained myself more clearly. When I said "...it would probably be impossible for MediaWiki to adopt this syntax..." I did not mean that it would be impossible (or even difficult) to implement. What I meant was that it would be just too confusing for the content writers. I think that, for the average author, it is important to have different syntax for images and templates. I agree that they are both, in some sense, transclusion, but to an author including an image and including a template are different things. |
|
I also think the fact that Brion is thinking of implementing Creole in "Edit Creole" mode supports my case. We should be trying to come up with a syntax that enables all the major wikis to implement in mixed mode (even if they initially choose to implement in "edit creole" mode). I restate my point: using {{{ {{...}} }}} for images would make a mixed mode MediaWiki impractical because it would be too confusing for the authors. |
|
(I've taken the liberty of labeling points made by previous authors (a) and (b), to enable me to more easily comment.) |
|
-- [MartinBudden] 11-Sep-2006 |
|
At line 153 added 63 lines |
|
!Anchors |
|
Will Creole have a syntax for anchors? |
|
-- [MartinBudden], 11-Sep-2006 |
|
Comment by Max: Isn't this inconsisten with "linebreaks create BR elements"? I think the result should be: |
{{{ |
<ul> |
<li>This is a single list item<br /> |
followed by a paragraph?</li> |
</ul> |
}}} |
|
No, because a linebreak signals the end of a list item. |
|
-- [Chuck Smith], 18-Sep-2006 |
|
! Moving to and from emails |
|
* One criterion I've always considered import is: can I easily copy/paste from and to emails? Two Creole constructs currently fail this test: |
** Line breaks: email programs frequently insert line breaks of their own! This would break the wiki markup. Why not use the LaTeX double backslash for line breaks? |
** bullet lists: I often see lists written like this (especially by Emacs users) and actually like the WYSIWYG quality it has: |
{{{ |
- this is a list item that spans |
several lines |
- this is a nested list |
This line is not part of the list. |
}}} |
* I would like to see a minimal markup language. For the more frequently used constructs, ASCII art-like syntax is OK, but for more esoteric commands it makes sense to introduce a uniform macro syntax. |
* For our own home-grown wiki syntax, we used a staged translation into a proper abstract syntax tree: The final syntax is nested, much like HTML; i.e., there is clearly defined scope and arbitrary structured blocks can be nested. Before, there is a special translation step that transforms line-centric wiki markup to the block-centric abstract syntax. Advantages: |
** I can use our syntax in emails and convert it easily to both HTML and LaTeX (because we have an abstract syntax tree). |
** For styled Ajax-based text entry, one needs to convert from HTML to a wiki syntax. A macro syntax permits a very simple solution here: translate HTML tags to macros while keeping the name. |
** Reference: "A Wiki as an Extensible RDF Presentation Engine", Rauschmayer, Kammergruber. [http://www.pst.ifi.lmu.de/~rauschma/bib/#rauschma:swemwikked_eswc:2006] |
|
-- [Axel Rauschmayer], 2006-09-19 |
|
There is one problem with using indentation to indicate list nesting. Space counting. It's especially annoying when you want to make a nested list and then return to the previous level -- especially if you use indentation large enough to be easily visible. Broken TAB key only adds to the inconvenience. |
|
As for macros, I agree that it's a nice solution to extending wiki markup, but the exact mechanism is usually very engine-dependent. For example, in the [[MoinMoin]] plug-in I re-used the "placeholder" syntax for macros. I'm not sure if it's right, but seems appropriate -- after all the spec doesn't say how you should serialize the object, quoting it raw is also one possible manner of serialization. |
|
The exact method of parsing the raw text is left up to the wiki engine authors. Some wikis use full-blown context-free parsers, other rely almost exclusively on regular expressions, most use some ways of home-brew hybrid solutions. That's ok, as long as the users can use the common markup in all of them (even when there are some occasional artifacts of the parser showing up once in a while). |
|
Maybe there should be a separate page describing the *scope* of this spec? |
|
-- [RadomirDopieralski], 2006-09-19 |
|
I'm currently parsing the creole markup at save time, and storing XML (actually subset of XHTML). Then applying the reverse transformation at edit time, XML to Creole. So could implement a specific XMLToEmail transformation. |
I think it has a number of advantages. Like sloppy creole markup is corrected, can just embed the XML directly into web pages, and XML to Creole transformation is far easier than the reverse for displaying for editting purposes. |
|
-- [JaredWilliams], 2006-09-20 |
|
Radomir: good points, especially about list indentation levels and scope description. I'm really warming up to Creole, it's not easy to go beyond matters of taste. |
|
Two more comments: |
|
//italics// |
Why not ~~italics~~? But for me clashing with URIs is not a problem, I don't want free-standing URIs anyway. Only excluding http:// and ftp:// seems a bit limited, though. How about https and mailto? |
|
Line breaks: This is something I cannot live with. Again: I think the LaTeX way (empty lines produce paragraphs, line breaks have to be explicitly introduced via double backslash) of doing this works best, as especially under Unix, programs frequently insert line breaks. I hardly ever use explicit line breaks and thus think that one should explicitly mention them if one really needs them. |
|
-- [Axel Rauschmayer], 2006-09-23 |