At line 506 changed one line |
If we will not solve the [[BoldAndListsAmbiguity]] I will have to agree on this proposal, because I see the problems implementers have (we ourselfs are using regex in the creole filter and in WikiWizard), and in that case it is a valid solution. But this would make it more difficult to use Creole than necessary. This proposals is a sign that something in the design is wrong and accepting this probosal would only cure a symptom. I would like to ask you to reject this proposal and istead consider the [[HypenListMarkupProposal]] to solve the problem. |
If we will not solve the [[BoldAndListsAmbiguity]] I will have to agree on this proposal, because I see the problems implementers have (we ourselves are using regex in the creole filter and in WikiWizard), and in that case it is a valid solution. But this would make it more difficult to use Creole than necessary. This proposal is a sign that something in the design is wrong and accepting this proposal would only cure a symptom. I would like to ask you to reject this proposal and instead consider the [[HyphenListMarkupProposal]] to solve the problem. |
At line 509 added 124 lines |
|
Creole does not like whitespace as markup. Isn't that sort of fundamental in Creole? Forcing a space after dot seems to me breake this principle. Secondly, using a space in the ambigous case is very intyuitive I would say. It doesn't have to be seen as a space -- it is just a separator between adjacent markup. The content of the list item is then space trimmed, right? |
|
{{{ |
* one |
** two |
*** three |
* **very intuitive one** |
** **very intuitive too** |
}}} |
|
--ViktorSoderqvist 2007-02-27 |
|
Creole "doesn't mind spaces" as long as it is visible and doesn't have to be counted. See [[InvisibleMarkup]]. |
|
-- [[Radomir Dopieralski]], 2007-02-27 |
|
{{{ |
*list item1 |
*list item2 |
**sublist item1 |
}}} |
|
This should be interpreted as |
{{{ |
<li>list item1</li> |
<li>list item2 |
<ul> |
<li>sublist item1</li> |
</ul></li> |
}}} |
|
However, the following |
{{{ |
blat blaa |
**this I think is bold** |
}}} |
|
should be interpreted as bold. |
|
So, I don't see an issue here. The list parser needs to keep track of the context anyway to know when to add/remove from the indent anyway. If the user wants to start a line with a bold, they're not likely to terminate a bullet list with a line which starts with bold, because visually, the bullet markup is stronger. Yes, I know this means that you have to work a bit more on your parser, but who cares? |
|
Whitespace is irrelevant here. |
|
-- JanneJalkanen |
|
Yes, Janne. Your examples can be sorted out quite easily. |
But what about this case? |
|
{{{ |
*blat blaa |
**this I think is bold** |
**going to second level |
***this is first level**, again |
}}} |
|
Moreover, even if ambiguous cases could be all decided, the text would easily get unreadable, anyway. |
|
-- [[Michele Tomaiuolo]], 2007-02-28 |
|
Nope. That will render as (whitespace added for clarity) |
{{{ |
* blat blaa |
** this I think is bold<b></b> |
** going to the second level |
*** this is actually third level<b>, again</b> |
}}} |
|
The reason people are not putting spaces in Wikipedia is because they can get away with it. TWiki users use happily bullet lists with mandatory indentation, because of that is mandated by the engine. But you can't use those as arguments - if following Wikipedia is a goal of WikiCreole, then we should just simply adopt Mediawiki markup and be done with it... |
|
-- JanneJalkanen |
|
After all those discussions I can see now that I made a mistake when proposing this. The space after bullet just **felt** right to me, but I was unable to tell exactly **why** -- so I just picked up a few most obnoxious things it solves and listed it as advantages. This was not right, because it suggested that I want to introduce this rule just merely to solve these problems. So, in response, alternative solutions started to pop up. But that's not how it is. |
|
It took me a long time to understand why the space after bullet felt right. It's so simple that it's really hard to notice. All the other advantages are just a side effect of the one single advantage: //it adds clarity//. |
|
The easier parsing, resolved ambiguities, simple explanation, better looks, easier learning, less interdependency with other markup -- even the fact that it is traditionally accepted -- are all just a **result** of added clarity. |
|
I have before mentioned it, but my wording was wrong. I was saying that "it looks better", "is more beautiful", etc. -- but beauty is (allegedly) in the eye of the beholder (isn't it funny that so many people agree on what is beautiful and what is not then?). So my arguments were easily dismissed as "touchy-feely", relative and personal. But one cannot argue the same way about clarity -- all human beings have roughly the same algorithms for pattern recognition -- and all computer users have roughly similar training in it. Space after the asterisk (or whatever else list markup we decide on) **does** add clarity, no matter what are your feelings about it. |
|
Now, I can see one reason for resistance (apart from political/social reasons): |
* we think that we don't need additional clarity for lists, |
* this added clarity comes at a cost of user work. |
Am I guessing right here, or are there other reasons behind this? |
|
-- [[Radomir Dopieralski]], 2007-Mar-01 |
|
I tried to extend Creole syntax and implement also [[Email-style emphasis]]. |
In this case, emphasis begins and ends on a single character: "/", "*" or "_". |
|
I've not found a way to solve the conflict with bullets at line start. A space would solve the problem completely. |
Otherwise, all engines using this style (which is very handy!) would face the same problem. |
|
Btw, I don't think Creole should drop bullet lists, even if it adopts hyphen lists. |
They're simply too widespread and natural. |
|
-- [[Michele Tomaiuolo]], 2007-03-02 |
|
May I know what is exactly the problem with this proposal? Incompatibility with MediaWiki? Requirement to convert the wikipedia page database if this is accepted and wikipedia adopts Creole? |
|
-- [[Radomir Dopieralski]], 2007-Mar-22 |
|
No real problem. Converting the wikipedia database will be required anyway! |
But if we accept spaces //before// bullets, for the sake of consistency, we should |
accept them before leading pipe in tables and before leading equal in titles, |
not mentionning other kinds of lists and indenting. Forbidding spaces after |
single bullets seems gratuitous, but I don't mind much. |
|
But please don't choose both hyphens and stars for unnumbered lists. |
|
-- [[YvesPiguet]], 2007-Mar-22 |
|
---- |
|
I believe this discussion went astray, focussing on ambiguity, parser, etc. issues. I agree that machines should work harder, but this leads me to the opposite conclusion. The important issue to me are intuitiveness to writers and readability in plain text mode! |
|
The only argument relevant to this is Chucks wikipedia study. I looked myself (and have no issues with numbers). but I personally feel that the no-blank style looks like computer programming done by wikipedia experts, and the bullet+blank style nicely sticks out and is readable and intuitive. Please try yourself! I read Radomir's [[Require Space After Bullet Proposal|original proposal]] as this being a major argument in favor or requiring the blank, not just the question of solving ambiguity issues. |
|
I consider the proposal to be very valid and would like to see it accepted or discussion reopened. |
|
Here a quote from what I wrote on [[Talk.Creole 0.6]]: "I personally find bullet-plus-blank much more intuitive and readable markup sequence. It would make the Creole specs simpler, not requiring us to explain two alternative ways of list markup! [...] To me giving both options is two different rules, perhaps because unlike most whitespace rules in Creole and in fact all Wikis I know, this **does not**, correspond to html/xml whitespace normalization. (I consider this an argument for being "intuitive" to a lot of readers, not a technical argument). The difference between "- X" and "-X", or "# X" and "#X" seems to be intuitively significant. Do we really have to support both alternative markup styles?" |
|
-- [[Gregor Hagedorn]], 2007-04-04 |
|