I posted a draft of WikiCreole 0.1 http://www.wikicreole.org/wiki/Creole0.1 to wikicreole.org and we believe all the rough edges have been smoothed out, but are still seeking comments and criticisms from the wiki community.
Please either reply on http://www.wikicreole.org/wiki/Talk.Creole0.1 or just email me. We plan to release a final spec on **Monday**, so last day to comment on Creole 0.1 is this Sunday.
Chuck
I think the bold and italics notation is confusing, especially the italics // makes me think about comments instead of italics... why not just use bbcode (=already widespread standard on fora) for your wikicreole standard and add the items for wiki-specific features which are not available yet in bbcode?
Cheers, Peter.
On 9/7/06, Chuck Smith chuckssmith@gmail.com wrote:
I posted a draft of WikiCreole 0.1 http://www.wikicreole.org/wiki/Creole0.1 to wikicreole.org and we believe all the rough edges have been smoothed out, but are still seeking comments and criticisms from the wiki community.
Please either reply on http://www.wikicreole.org/wiki/Talk.Creole0.1 or just email me. We plan to release a final spec on **Monday**, so last day to comment on Creole 0.1 is this Sunday.
Chuck _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 9/7/06, Peter ipbwiki.list@gmail.com wrote:
why not just use bbcode (=already widespread standard on fora) for your wikicreole standard and add the items for wiki-specific features which are not available yet in bbcode?
If you use BBcode, you may as well use HTML. The former is just a stripped-down version of the latter with a couple of minor tweaks. The advantages of wikitext are that it's more readable at a glance (the basic shape of '' is very different from that of [[ or {|, for instance) and quicker to type (many of the syntaxes rely on doubled or tripled characters, for instance). The disadvantage, of course, is that it's hell to parse.
Anyway: why would we want to replace our insane and byzantine markup system, which tens of thousands of users have grown used to, with another insane and byzantine markup system that's completely incompatible with the markup used in probably over ten million pages on Wikimedia alone, and unfamiliar to our users to boot? Reverse-incompatible markup changes, *maybe* (that's IMO: in Brion's, absolutely not, and he's in charge), but only if there's a really good reason for each and every change . . . which there isn't, here.
Simetrical wrote:
Anyway: why would we want to replace our insane and byzantine markup system, which tens of thousands of users have grown used to, with another insane and byzantine markup system that's completely incompatible with the markup used in probably over ten million pages on Wikimedia alone, and unfamiliar to our users to boot?
That's not what WikiCreole is trying to do. Creole is attempting to provide a small set of standardized markup that wiki engines can support in addition to their native markup; eight wiki engines, including MediaWiki, have committed to providing Creole support.
Ivan Krstić wrote:
Simetrical wrote:
Anyway: why would we want to replace our insane and byzantine markup system, which tens of thousands of users have grown used to, with another insane and byzantine markup system that's completely incompatible with the markup used in probably over ten million pages on Wikimedia alone, and unfamiliar to our users to boot?
That's not what WikiCreole is trying to do. Creole is attempting to provide a small set of standardized markup that wiki engines can support in addition to their native markup; eight wiki engines, including MediaWiki, have committed to providing Creole support.
We're committed? I must have missed that bulletin.
-- Tim Starling
Tim Starling wrote:
We're committed? I must have missed that bulletin.
For some value of committed, that I assume actually means "Brion said we'll do it". I wasn't at the workshop.
Tim Starling wrote:
Ivan Krstić wrote:
Simetrical wrote:
Anyway: why would we want to replace our insane and byzantine markup system, which tens of thousands of users have grown used to, with another insane and byzantine markup system that's completely incompatible with the markup used in probably over ten million pages on Wikimedia alone, and unfamiliar to our users to boot?
That's not what WikiCreole is trying to do. Creole is attempting to provide a small set of standardized markup that wiki engines can support in addition to their native markup; eight wiki engines, including MediaWiki, have committed to providing Creole support.
We're committed? I must have missed that bulletin.
I said I'd try a test implementation. Haven't had time to work on it yet.
-- brion vibber (brion @ pobox.com)
Simetrical wrote:
On 9/7/06, Peter ipbwiki.list@gmail.com wrote:
why not just use bbcode (=already widespread standard on fora) for your wikicreole standard and add the items for wiki-specific features which are not available yet in bbcode?
If you use BBcode, you may as well use HTML. The former is just a stripped-down version of the latter with a couple of minor tweaks. The advantages of wikitext are that it's more readable at a glance (the basic shape of '' is very different from that of [[ or {|, for instance) and quicker to type (many of the syntaxes rely on doubled or tripled characters, for instance). The disadvantage, of course, is that it's hell to parse.
Anyway: why would we want to replace our insane and byzantine markup system, which tens of thousands of users have grown used to, with another insane and byzantine markup system that's completely incompatible with the markup used in probably over ten million pages on Wikimedia alone, and unfamiliar to our users to boot? Reverse-incompatible markup changes, *maybe* (that's IMO: in Brion's, absolutely not, and he's in charge), but only if there's a really good reason for each and every change . . . which there isn't, here.
Hoi, There is a reason to change the Wikisyntax when the syntax itself is incompatible with content. The way we currently indicate italic and bold is at least incompatible with the Neapolitan languiage. I am convinced that as we localise more languages, more languages will bring us similar problems.
PS being able to create correct content in all languages is imho the best reason to modify the Wikisyntax. Thanks, GerardM
On 9/7/06, Chuck Smith chuckssmith@gmail.com wrote:
I posted a draft of WikiCreole 0.1 http://www.wikicreole.org/wiki/Creole0.1 to wikicreole.org and we believe all the rough edges have been smoothed out, but are still seeking comments and criticisms from the wiki community.
Please either reply on http://www.wikicreole.org/wiki/Talk.Creole0.1 or just email me. We plan to release a final spec on **Monday**, so last day to comment on Creole 0.1 is this Sunday.
Chuck _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
It looks like your homepage just got overwritten. You might want to apply clue-by-4 to someone's head and restrict write access a bit more...
seeking comments and criticisms from the wiki community.
Q: What's this supposed to do? ============= ---- test ============= A1: "<hr /><p>test</p>". A2: Treat it as a 4-deep unordered list element.
From the "Internal and External Links" section
( http://www.wikicreole.org/wiki/Creole0.1#section-Creole0.1-InternalAndExtern... ), you have both internal and external links using double square brackets, e.g.:
============= [[MyBigPage|Go to my page]] [[http://www.wikicreole.org/]] [[http://www.wikicreole.org/ | Visit the WikiCreole website]] =============
Doesn't that implicitly assume that articles don't start with "http://" ? And is the "http://" matching case-sensitive or not?
Certainly on the English Wikipedia, we have article names that look like URLs. E.g. these are all valid wiki articles or redirects: http://en.wikipedia.org/wiki/http://www.google.com/ http://en.wikipedia.org/wiki/http://www.ebay.com http://en.wikipedia.org/wiki/http://amazon.com And there's also these: http://en.wikipedia.org/wiki/ftp:// http://en.wikipedia.org/wiki/mailto:
How is the user to create a internal link to these pages? Currently "[[Http://www.google.com/]]" will give an internal link, although "[[http://www.google.com/]]" will not; hence the case-sensitivity question.
We plan to release a final spec on **Monday**, so last day to comment on Creole 0.1 is this Sunday.
Sorry, but I was away on leave last week, and so I didn't get around to reading this until today.
Creole is attempting to provide a small set of standardized markup that wiki engines can support in addition to their native markup; eight wiki engines, including MediaWiki, have committed to providing Creole support.
We're committed? I must have missed that bulletin.
I said I'd try a test implementation. Haven't had time to work on it yet.
Danger, Will Robinson! Syntax conflicts ahead.
Q: If "**" means start & stop bolding in Creole, and the creole spec says "Bold and italics should be able to cross lines", and we're wanting to support both native + Creole, then what's this going to render as? ========== ** test1 ** test2 ========== A1: Two list elements as per current. A2: "<strong>test1</strong>test2".
Q: If "{{" is used for image insertion in creole, what's this going to render as? ========== {{cleanup}} ========== A1: The cleanup template. A2: <img src="cleanup" />
Q: If "{{{" is used for preformatted text, what's a template that does this going to render as? ========== {{{1}}} ========== A1: Show the first passed param. A2: Show "<pre>1</pre>"
All the best, Nick.
-----Original Message----- From: wikitech-l-bounces@wikimedia.org [mailto:wikitech-l-bounces@wikimedia.org]On Behalf Of Chuck Smith Sent: Thursday, 7 September 2006 7:30 PM To: wiki-research@wikisym.org; wiki-standards@wikisym.org; Wikimedia developers Subject: [Wikitech-l] draft of WikiCreole 0.1 available for comment
I posted a draft of WikiCreole 0.1 http://www.wikicreole.org/wiki/Creole0.1 to wikicreole.org and we believe all the rough edges have been smoothed out, but are still seeking comments and criticisms from the wiki community.
Please either reply on http://www.wikicreole.org/wiki/Talk.Creole0.1 or just email me. We plan to release a final spec on **Monday**, so last day to comment on Creole 0.1 is this Sunday.
Chuck _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 9/11/06, Nick Jenkins nickpj@gmail.com wrote:
seeking comments and criticisms from the wiki community.
Q: What's this supposed to do?
---- test
A1: "<hr /><p>test</p>". A2: Treat it as a 4-deep unordered list element.
A1. After some convincing from the wiki community, we changed the hyphen for unordered lists to an asterisk, so this will no longer be a problem.
From the "Internal and External Links" section ( http://www.wikicreole.org/wiki/Creole0.1#section-Creole0.1-InternalAndExtern... ), you have both internal and external links using double square brackets, e.g.:
============= [[MyBigPage|Go to my page]] [[http://www.wikicreole.org/]] [[http://www.wikicreole.org/ | Visit the WikiCreole website]] =============
Doesn't that implicitly assume that articles don't start with "http://" ? And is the "http://" matching case-sensitive or not?
Yes.
Certainly on the English Wikipedia, we have article names that look like URLs. E.g. these are all valid wiki articles or redirects: http://en.wikipedia.org/wiki/http://www.google.com/ http://en.wikipedia.org/wiki/http://www.ebay.com http://en.wikipedia.org/wiki/http://amazon.com And there's also these: http://en.wikipedia.org/wiki/ftp:// http://en.wikipedia.org/wiki/mailto:
There are only redirects in Wikipedia that start with http:// or ftp://, so you should not be linking to those pages anyway. That's very bad style. I see no case where a wiki page should have http:// or ftp:// at the beginning.
How is the user to create a internal link to these pages? Currently "[[Http://www.google.com/]]" will give an internal link, although "[[http://www.google.com/]]" will not; hence the case-sensitivity question.
They can't and shouldn't. We might however consider an escape character (perhaps the ~ tilde) for a later version of Creole.
I said I'd try a test implementation. Haven't had time to work on it yet.
Danger, Will Robinson! Syntax conflicts ahead.
Whoa! MediaWiki will certainly implement Creole with placeholders and a separate button for editing Creole, so syntax conflicts are not important. The plan from how I understand it is that someone will click the Edit Creole or Easy Edit button on Wikipedia and then all the weird stuff (variables, templates, categories, tables, etc.) which aren't essential to the article will be represented by a placeholder like <<Category code block 1>> and then the wiki engine would convert its syntax to Creole and a user would edit it in Creole and then the server would convert it back to regular MediaWiki syntax. This way creole users will be able to move complicated things around, but not modify them and would not be intimidated by all that weird code. This "strange code intimidation factor" was even mentioned by Jimbo in his keynote speech at Wikimania in Boston this year.
I hope this helps clarify things.
Chuck
Q: What's this supposed to do?
---- test
A1. After some convincing from the wiki community, we changed the hyphen for unordered lists to an asterisk, so this will no longer be a problem.
Cool.
However, now asterisks have two behaviours (bolding & unordered lists). Just to clarify what I think the spec is saying about the precedence of these, and what happens when they intersect in weird and unbalanced ways, this test input: ============= A ** test** to ** see **what ** bold * and lists does ** *** ** ** test ** end ** ============= Should render as: "<p>A <strong> test</strong> to ** see</p><ul><li><ul><li>what ** bold *</li></ul></li></ul><p>and lists does <strong> </strong>* **</p><ul><li><ul><li>test <strong> end </strong></li></ul></li></ul>".
Is that correct? I don't personally mind what the correct answer is, but I do want to make sure that there is only one unambiguous and correct answer, and that it can be logically determined from the specs.
Certainly on the English Wikipedia, we have article names that look like URLs. E.g. these are all valid wiki articles
or redirects:
http://en.wikipedia.org/wiki/http://www.google.com/ http://en.wikipedia.org/wiki/http://www.ebay.com http://en.wikipedia.org/wiki/http://amazon.com And there's also these: http://en.wikipedia.org/wiki/ftp:// http://en.wikipedia.org/wiki/mailto:
There are only redirects in Wikipedia that start with http:// or ftp://, so you should not be linking to those pages anyway. That's very bad style.
It perhaps debatable whether linking to redirects is bad style, but it's certainly true that being able to link to redirects is very useful. If you don't believe me, just try turning it off on the Wikipedia, and listen to the howls of protest. :-)
However, there is exactly one link to the [[Http://www.google.com/]] redirect, and I don't think any to the others, so it's not a big deal if this changes.
Danger, Will Robinson! Syntax conflicts ahead.
Whoa! MediaWiki will certainly implement Creole with placeholders and a separate button for editing Creole, so syntax conflicts are not important.
Cool, two different edit modes (as opposed to one that's trying to support both native + Creole). Got it.
I hope this helps clarify things.
It does - Thank you.
All the best, Nick.
However, now asterisks have two behaviours (bolding & unordered lists). Just to clarify what I think the spec is saying about the precedence of these, and what happens when they intersect in weird and unbalanced ways, this test input: ============= A ** test** to ** see **what ** bold * and lists does ** *** **
** test ** end **
Should render as: "<p>A <strong> test</strong> to ** see</p><ul><li><ul><li>what ** bold *</li></ul></li></ul><p>and lists does <strong> </strong>* **</p><ul><li><ul><li>test <strong> end </strong></li></ul></li></ul>".
It is not necessary for a specification to specify the behaviour for absolutely every possible conceivable input. In fact, the HTML and CSS spec don't do that either. They first define that some inputs are "valid" and some are "invalid", and then proceed to prescribe the correct behaviour only for the "valid" ones.
Although a wiki engine must obviously produce some output for any given input, it does not follow that this output must be strictly prescribed. If you did that, then you could never introduce new wiki syntax features without breaking existing behaviour.
Thus, even in wiki syntax, a specification must define what constitutes "valid" markup, and then define the behaviour for that valid mark-up.
Your above example is invalid mark-up. :-)
Timwi
On 12/09/06, Timwi timwi@gmx.net wrote:
Thus, even in wiki syntax, a specification must define what constitutes "valid" markup, and then define the behaviour for that valid mark-up.
I think you are completely and utterly wrong on this. Every combination of wikitext has to be able to do something, because it is a *language*.
If people who can't work computers put a character out of place and the wiki engine just spits back "INVALID CONTENT", are they going to edit an article ever again? *Hell* no.
HTML was invented as a human-editable page language. However, the humans it was invented for were nuclear physicists, rather than the general public.
When the general public started writing web pages, they didn't write well-formed HTML - they would bash out something, preview it in Netscape 1.1 and put it up. The geeks derided this as "tag soup".
But I submit that the "tag soup" approach was the natural one for people to use, because that's how people learn a language: test, change, test again, repeat. That's how people learn wikitext on Wikipedia: if you just write plain text, it'll more or less work. If you want to do something fancier, you'll look and see what other people do and try something like that and see if it works.
People care much more about what they're putting on the page than constructing an immaculate piece of XML. If wikitext can't cope sensibly with *anything and everything* people throw at it, then we might as well just be requiring immaculate XML.
- d.
On Tue, Sep 12, 2006 at 05:44:29PM +0100, David Gerard wrote:
On 12/09/06, Timwi timwi@gmx.net wrote:
Thus, even in wiki syntax, a specification must define what constitutes "valid" markup, and then define the behaviour for that valid mark-up.
I think you are completely and utterly wrong on this. Every combination of wikitext has to be able to do something, because it is a *language*.
Well, *my* opinion is that you're in violent agreement, gents. :-)
If people who can't work computers put a character out of place and the wiki engine just spits back "INVALID CONTENT", are they going to edit an article ever again? *Hell* no.
Of course not.
But Timwi's assertion is, indirectly, at least, that it's necessary to define *how to behave when you *get* something ill-formed*, which as a subset, requires that you define well-formed clearly.
HTML was invented as a human-editable page language. However, the humans it was invented for were nuclear physicists, rather than the general public.
Hee.
Can I quote you on that, David? :-)
But I submit that the "tag soup" approach was the natural one for people to use, because that's how people learn a language: test, change, test again, repeat. That's how people learn wikitext on Wikipedia: if you just write plain text, it'll more or less work. If you want to do something fancier, you'll look and see what other people do and try something like that and see if it works.
Yep.
People care much more about what they're putting on the page than constructing an immaculate piece of XML. If wikitext can't cope sensibly with *anything and everything* people throw at it, then we might as well just be requiring immaculate XML.
*Users* care much more about that. That is *precisely why* implementers have to care about things such as Timwi suggests. IMHO.
Cheers, -- jra
On 12/09/06, Jay R. Ashworth jra@baylink.com wrote:
On Tue, Sep 12, 2006 at 05:44:29PM +0100, David Gerard wrote:
On 12/09/06, Timwi timwi@gmx.net wrote:
Thus, even in wiki syntax, a specification must define what constitutes "valid" markup, and then define the behaviour for that valid mark-up.
I think you are completely and utterly wrong on this. Every combination of wikitext has to be able to do something, because it is a *language*.
Well, *my* opinion is that you're in violent agreement, gents. :-)
I hope so :-)
If people who can't work computers put a character out of place and the wiki engine just spits back "INVALID CONTENT", are they going to edit an article ever again? *Hell* no.
Of course not. But Timwi's assertion is, indirectly, at least, that it's necessary to define *how to behave when you *get* something ill-formed*, which as a subset, requires that you define well-formed clearly.
mmmmmmmmm true. Mind you, you end up with a pile of special cases, but that may not actually be a bad thing.
Consider things like the ''' hack in Mediawiki - if you have [letters]'''[letters]'' it doesn't go bold then italic - it goes apostrophe, italic. This is for French and Italian, when you have "the aaaa" as l'aaaa and you want the "aaaa" italicised but not the article. Is that an annoying special case? Yep. Is it an excellent and useful idea if humans are going to use this thing? Arguably. Then you have to special-case some more with how to be sure it's not bolding as well. Etc.
Special case upon special case. This makes deep-thinking geeks go "eww", because they're used to seeing a mass of special cases and attempting to abstract out the simpler rule of what's actually happening. But there *isn't* one, because humans are annoying and their languages have structure but also way too many bolted-on irregular bits.
So, uh, cross-wiki syntax will be fun all the way down ;-)
(I'm currently heavily using Mediawiki on WMF projects and MoinMoin at work, and lightly using UseMod at work. Switching modes is not as confusing as it might be, because Mediawiki and MoinMoin syntax is different enough not to mix them up. Much.)
- d.
"David Gerard" dgerard@gmail.com wrote in message news:fbad4e140609120944j4ba1fa90xc002f99d56ad512f@mail.gmail.com...
On 12/09/06, Timwi timwi@gmx.net wrote:
Thus, even in wiki syntax, a specification must define what constitutes "valid" markup, and then define the behaviour for that valid mark-up.
I think you are completely and utterly wrong on this. Every combination of wikitext has to be able to do something, because it is a *language*.
As Timwi says, the language specification needs to specify what is valid and how those valid constructs should be interpreted.
The wiki engine needs to be able to handle all input that is given to it and interpret the defined constructs according to the language definition. It may handle undefined constructs in any way it likes (though it should be consistent within itself: same input = same output).
The same is true in English. The sentence "I FEELING HAPPY" is invalid English, according to the language, but would be understood by an English speaker (the interpreter):
The markup "<p><b>This is bold</p>" is invalid HTML, but would be understood by a web browser.
Note that in both of these examples there is some ambiguity in how the invalid phrase could be interpreted (am I feeling one of the seven dwarves?) but that the correct interpretation is also the most likely, so the interpreter is able to guess. This is why 'pigeon english' or 'tag soup', despite being technically incorrect, are usable in practice.
However, it is incorrect to assume that a language must be unambiguous. For example if I say 'I hate annoying people', do I dislike making people annoyed, or do I dislike people who irritate me?
- Mark Clements (HappyDog)
David Gerard wrote:
I think you are completely and utterly wrong on this.
I think you didn't really read my posting properly, and you only posted this for the sake of appearing cleverer or having the last word.
As Jay already mentioned, we are actually agreeing with each other. I never said absolutely anything that would suggest that the wiki engine would "just spit back "INVALID CONTENT"". If you had thought about what you wrote instead of just blasting it out into the mailing list, you would have realised that browsers also don't "just spit back "INVALID CONTENT"", but this doesn't mean any conceivable sequence of characters is valid HTML.
Timwi
On 14/09/06, Timwi timwi@gmx.net wrote:
David Gerard wrote:
I think you are completely and utterly wrong on this.
I think you didn't really read my posting properly, and you only posted this for the sake of appearing cleverer or having the last word. As Jay already mentioned, we are actually agreeing with each other. I never said absolutely anything that would suggest that the wiki engine would "just spit back "INVALID CONTENT"". If you had thought about what you wrote instead of just blasting it out into the mailing list, you would have realised that browsers also don't "just spit back "INVALID CONTENT"", but this doesn't mean any conceivable sequence of characters is valid HTML.
Evidently so, and my apologies if I offended.
- d.
On 9/12/06, Nick Jenkins nickpj@gmail.com wrote:
However, now asterisks have two behaviours (bolding & unordered lists). Just to clarify what I think the spec is saying about the precedence of these, and what happens when they intersect in weird and unbalanced ways, this test input: ============= A ** test** to ** see **what ** bold * and lists does ** *** **
** test ** end **
Should render as: "<p>A <strong> test</strong> to ** see</p><ul><li><ul><li>what ** bold *</li></ul></li></ul><p>and lists does <strong> </strong>* **</p><ul><li><ul><li>test <strong> end </strong></li></ul></li></ul>".
Is that correct? I don't personally mind what the correct answer is, but I do want to make sure that there is only one unambiguous and correct answer, and that it can be logically determined from the specs.
Another syntax cleanup proposal also suggested this dual use for *, and their solution was to evaluate bolding from right to left on a per-line basis, and any remaining asterisks on the left could become bulleted lists. So
A ** test** to ** see **what ** bold * and lists does ** *** ** ** test ** end **
Would probably become
A **test<b> to </b> see <b>what </b> bold * and lists does ** *<b> </b> <ul><li><ul><li> test <b> end </b></li></ul></li></ul>
That behavior might not be desirable, but the general idea of "interpret matched initial double asterisk as bold, unmatched as list" is a good one.
On 9/12/06, Timwi timwi@gmx.net wrote:
Your above example is invalid mark-up. :-)
**This** line is valid, yet ambiguous under what appear to be current specs. When is initial double asterisk bold, when is it list?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Tuesday 12 September 2006 23:27, Simetrical wrote: [snip]
Another syntax cleanup proposal also suggested this dual use for *, and their solution was to evaluate bolding from right to left on a per-line basis, and any remaining asterisks on the left could become bulleted lists. So
A ** test** to ** see **what ** bold * and lists does ** *** ** ** test ** end **
Would probably become
A **test<b> to </b> see <b>what </b> bold * and lists does ** *<b> </b>
<ul><li><ul><li> test <b> end </b></li></ul></li></ul>
That behavior might not be desirable, but the general idea of "interpret matched initial double asterisk as bold, unmatched as list" is a good one.
It violates the KISS principle. That means humans have now to match/balance * on a line to find out whether a leading * will make a list, or something bold etc. Ugh.
Best wishes,
Tels - -- Signed on Wed Sep 13 06:55:44 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"MY CAUSE IS JUST... MY WILL IS STRONG... AND MY GUN IS VERY VERY LARGE!" - The Doom Guy
On 9/13/06, Tels nospam-abuse@bloodgate.com wrote:
It violates the KISS principle. That means humans have now to match/balance
- on a line to find out whether a leading * will make a list, or something
bold etc. Ugh.
They would have to balance *double* asterisks only. The assumption is that these will virtually never occur except when intended to be markup. Since bolding markup is normally used in matched pairs, there's not really any problem except if someone habitually fails to close their bold markup, and unclosed bold markup probably shouldn't render as bold altogether (to force people to match asterisks *all* the time so they don't get confused when it doesn't work at the beginning of a line).
On 13/09/06, Simetrical Simetrical+wikitech@gmail.com wrote:
They would have to balance *double* asterisks only. The assumption is that these will virtually never occur except when intended to be markup. Since bolding markup is normally used in matched pairs, there's not really any problem except if someone habitually fails to close their bold markup, and unclosed bold markup probably shouldn't render as bold altogether (to force people to match asterisks *all* the time so they don't get confused when it doesn't work at the beginning of a line).
This brings to mind a co-worker's annoyance with MoinMoin's table syntax - where if you don't put everything all on one ridiculously long line, it doesn't work (or so he says). Will you be required to put everything on one ridiculously long line if you want to bold a paragraph?
- d.
On 9/13/06, David Gerard dgerard@gmail.com wrote:
This brings to mind a co-worker's annoyance with MoinMoin's table syntax - where if you don't put everything all on one ridiculously long line, it doesn't work (or so he says). Will you be required to put everything on one ridiculously long line if you want to bold a paragraph?
Er, you already are. Every paragraph is on one line. You can add line breaks without necessarily affecting output, but that's strongly discouraged because it screws up diffs.
On Wed, Sep 13, 2006 at 08:26:30PM -0400, Simetrical wrote:
On 9/13/06, David Gerard dgerard@gmail.com wrote:
This brings to mind a co-worker's annoyance with MoinMoin's table syntax - where if you don't put everything all on one ridiculously long line, it doesn't work (or so he says). Will you be required to put everything on one ridiculously long line if you want to bold a paragraph?
Er, you already are. Every paragraph is on one line. You can add line breaks without necessarily affecting output, but that's strongly discouraged because it screws up diffs.
Guys; you're making this one up. We have enough problems without having to invent extras.
Cheers, -- jra
On Tue, Sep 12, 2006 at 05:27:00PM -0400, Simetrical wrote:
Another syntax cleanup proposal also suggested this dual use for *, and their solution was to evaluate bolding from right to left on a per-line basis, and any remaining asterisks on the left could become bulleted lists. So
A ** test** to ** see **what ** bold * and lists does ** *** ** ** test ** end **
Would probably become
A **test<b> to </b> see <b>what </b> bold * and lists does ** *<b> </b>
<ul><li><ul><li> test <b> end </b></li></ul></li></ul>
That behavior might not be desirable, but the general idea of "interpret matched initial double asterisk as bold, unmatched as list" is a good one.
On 9/12/06, Timwi timwi@gmx.net wrote:
Your above example is invalid mark-up. :-)
**This** line is valid, yet ambiguous under what appear to be current specs. When is initial double asterisk bold, when is it list?
Oh, *c'mon* people; this one's *easy* to disambig:
if the asterisks are at BOL *and followed by a space*, they're bullets.
I'm *perfectly* happy to require a trailing space for bullets.
Cheers, -- jra
On 9/13/06, Jay R. Ashworth jra@baylink.com wrote:
if the asterisks are at BOL *and followed by a space*, they're bullets.
I'm *perfectly* happy to require a trailing space for bullets.
As long as it's required for any number of bullets, that would be quite a sensible solution, yes (keeping in mind that we're breaking reverse-compatibility anyway).
On Wed, Sep 13, 2006 at 09:57:01PM -0400, Simetrical wrote:
On 9/13/06, Jay R. Ashworth jra@baylink.com wrote:
if the asterisks are at BOL *and followed by a space*, they're bullets.
I'm *perfectly* happy to require a trailing space for bullets.
As long as it's required for any number of bullets, that would be quite a sensible solution, yes (keeping in mind that we're breaking reverse-compatibility anyway).
To be clear: I'm recommending the following
*bold* word * bulleted item ** Second level bullet * *bulleted bold phrase*
So the bullet tokens are required to be space-terminated.
Cheers, -- jra
On 9/13/06, Jay R. Ashworth jra@baylink.com wrote:
To be clear: I'm recommending the following
*bold* word
- bulleted item
** Second level bullet
- *bulleted bold phrase*
So the bullet tokens are required to be space-terminated.
Yes, exactly, except that bold is **double asterisks**, not single. That way you don't run into confusion when someone uses a lone random asterisk.
On Wed, Sep 13, 2006 at 11:10:40PM -0400, Simetrical wrote:
On 9/13/06, Jay R. Ashworth jra@baylink.com wrote:
To be clear: I'm recommending the following
*bold* word
- bulleted item
** Second level bullet
- *bulleted bold phrase*
So the bullet tokens are required to be space-terminated.
Yes, exactly, except that bold is **double asterisks**, not single. That way you don't run into confusion when someone uses a lone random asterisk.
Well, *here*, we run into "do we leverage the instincts people already have?"
Clearly, I have a different viewpoint on that than some other people do.
Cheers, -- jra
wikitech-l@lists.wikimedia.org