| At line 52 changed one line |
| Can't really argue with the majority at the WikiSym, especially when I wasn't even there. In the end, I think either way can work. I know I'm biased myself, so I can't really suggest a good decission. I've written [wiki more about minimal markup|http://wiki.sheep.art.pl/2006-09-07_wiki] (fixed the link now, sorry). |
| Can't really argue with the majority at the WikiSym, especially when I wasn't even there. In the end, I think either way can work. I know I'm biased myself, so I can't really suggest a good decission. I've written [wiki more about minimal markup|http://wiki.sheep.art.pl/2006-09-07]. |
| At line 58 changed 62 lines |
| Some comments: |
|
| You are specifying "bold" and "italic" markup. This is somewhat against w3c, as they prefer "emphasized" and "strong (emphasized)" meanwhile, without fixing to some specific presentation of that. If you look at it from that perspective, double and triple quotes (semantic markup, as already implemented by many engines) make much more sense than asterisks and slashes for directly addressing "bold" and "italic" presentation. |
|
| Lists should work with more natural indentation, not with repeating list markup characters (nobody would do that on paper!). |
|
| Unordered lists with "-" are no good, easily confused with negative numbers. |
|
| Ordered lists just with "#" are too weak as you maybe want to have more control over enumeration and style. There is a W3C standards problem with that, though. |
|
| And OF COURSE we need nested lists. |
|
| Headings: not requiring closing ==== is asymmetric, ugly and in some cases ambigue (false positives). It is also irregular compared to other wiki markup principle of using same markup for opening and closing something (like e.g. bold). |
|
| A consequence of not requiring the closing === is btw. that you have to use at least two leading equal signs to not get too many false positives (see MediaWiki). If you want to have a clean headline structure, you have to map == to h1. This is bad. Why not just require ^=+ bla bla =+$ (with same amount leading and ending = signs). This is strict enough to not cause false positives and it even looks nicer. |
|
| h1 should be = h1h1h1 =, h2 should be == h2h2h2 == of course. |
|
| Line breaks: that could be a troublemaker. Backslash at line end for continuations might be natural for some programmers, but not for users. |
| Some people like to have 1 sentence per source line, but result as flowed text. |
|
| -- ThomasWaldmann, 2006-09-07 |
|
| When people write, they think about bold and italic. Their mental model doesn't use strong and em. I don't think it is a problem that we say bold and suggest the use of the strong tag. |
| Unordered lists with "-" are no problem if we require a space after the dash. |
| We might "need" nested lists, but do we need it in Creole 0.1? Of COURSE we don't! Not right here, not right now, not recommended for all wiki engines. We can make leave it out. But I said I didn't want to argue for it anymore. I'm just irritated because of how you phrased it. |
| Asymetric markup is no problem; many other wikis use it (eg. exclamation marks for headings, asterisk for list items). I don't understand "symmetry" as an argument. |
| Some people prefer to use only one H1 per page: The title name of the page. This is not mandated by the HTML standard, but many people (me included) think it is good style. |
| Some people like to have 1 sentence per line, and sometimes I do, but to be honest, I haven't seen any of my users do it. On the contrary, people used to blogging have come used to the idea that a single newline creates a linebreak in the output. That's how the most common word processors work, too. Why alienate them? (Of course, I won't be installing this rule on Emacs Wiki, since Emacs users have different ideas about word wrap, but you get the point. |
| -- AlexSchroeder |
|
| ---------- |
|
| I just noticed that this wiki uses [CC BY-SA|http://creativecommons.org/licenses/by-sa/1.0/] |
| licence. Woudn't this be a lot of problems when we want to publish this spec? I mean tracking down all the contributors to list them is going to be a pita... |
| -- [RadomirDopieralski], 2006-09-08 |
|
| Dirk Riehle suggested this. What would you suggest? |
| -- [Christoph] 8-Sep-2006 |
| |
| ----------- |
|
| Sorry, my English is not so good. Eble mia remarko ne gravas mondskale, sed mi menciu gxin. Se vi tajpas vikian tekston en cirila skripto por vi estas tre maloportune tajpi krampojn []. Cxar en, ekzemple, rusa arangxo de literoj cxe klavaro ne eblas tajpi []. Do, vi skribas ruse, sxangxas klavararangxo al la angla, tajpas [[, sxangxas klavararangxo al la rusa, tajpas titolon de ligilo, sxangxas klavararangxo al la angla, tajpas ]], sxangxas klavararangxo al la rusa kaj dauxras skribi artikolon. Pro tio en vikimotoroj kiuj estis kreitaj de rusparolantoj eblas krei ligilojn sen [[]], sed per (()). --Aleksandr Sigachov |
|
| Translation of above by [Chuck Smith]: Maybe my remark doesn't matter worldwide, but let me mention it. If you type wiki text in cyrillic script it's very inconvenient to type square brackets []. Because, for example, it's not possible to type [] on a Russian keyboard. So, you write in Russian, you have to change the keyboard layout to English, type [[, change back to Russian, type a link title, change back to English, type ]], change back to Russian and continue writing an article. That's why wiki engines which were made for Russian speakers can make links using (()) instead of [[]]. --[Aleksandr Sigachov] |
|
| ''Cheers for T. Waldmann'' |
|
| ---- |
| I agree with much of what ThomasWaldmann said above. Using "-" and "#" as single-character ways to start a list is generally troublesome, especially allowing for arbitrary whitespace in front of them. |
|
| And interpreting linebreaks in wikitext as "br" tags would make much of my cutting and pasting from word processors into a wiki fail. |
|
| ---- |
| Maybe there should be a "fall back" mechanism, optionally using more characters, but easier to type on any keayboard, like with [C digraphs and trigraphs|http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V50_HTML/ARH9NATE/DOCU_001.HTM]. |
| You think that {{{<:<:this:>:>}}} looks ok for a link? |
|
| As for the license, I think that the final specification should be public domain to be useful. |
|
| By the way, [this page|http://www.communitywiki.org/en/HowStandardsForm] might prove a little useful for us maybe? |
|
| -- [RadomirDopieralski], 2006-09-08 |
| Should // be ignored from parsing only if following "http:" or "ftp:"? The range of TCP/IP schemes is much larger and you can never know what's going to appear in the future. That's why I would prefer generaly to ignore any sequence of "://". --Blahma |
.