|
|
Re: [cowiki-dev] Extension to coWiki text formatting: msg#00038
|
Subject: |
Re: [cowiki-dev] Extension to coWiki text formatting |
Thanks for your comments, Sy...
Sy wrote:
* Numbered lists: One day I'd like to be able to customise the list
for, say, all numbers instead of having mixed numbering/lettering.
I understand and I'd like that too, but I'm not sure how to implement
it. There are a number of issues over formatting and controlling lists
that we should think about. In this case the 1.a. style is a vestige
of my using Word to create the HTML document.
* Mention the alias for [[link]] style links as well as ((link)) style.
Actually, I prefer [[]] style as that is consistent with other wikis.
I have found that Rubyists use (()) in there documentation tool, and
Kai and dtg seem to strongly prefer it. I'd like to choose one or the
other. When there are too many ways of accomplishing the same thing, a
user will start to ask "What is the difference? When should I use one
over the other?"
DocuWiki uses (()) to indicate images to be included inline.
There is also the issue of polluting the command space... Internally,
the original token has to be retained so that the text can be presented
back to the user as they entered it.
* Is it really diffitcult to allow nesting of quote <q> tags?
It shouldn't be, but what you're really thinking about then is an
<indent> operator, right? I would also like a <box>
function where I could display text to be formatted in what looks like
today's <code> box.
It also seems to me that we have a lot (too many?) of ways of
displaying preformatted text.
* <fixed>fixed</fixed> -- Should that be <tt>TrueType</tt> ?
I think you are right.
* Tables: I really like the new style of table that was being coded.
I think I understand your proposal, but I need an example.
I didn't understand it and I couldn't *read* it at all! :-)
^ Heading 1 ^ Heading 2 ^ <left>Heading 3</left> ^
| cell A1 | cell A2 | cell A3 |
| <left>cell B1</left> | <left>cell B2</left>|
<left>cell B3</left>|
| cell C1 | cell C2 | cell C3 |
Produces a table like this:
| Heading 1 |
Heading 2 |
Heading 3 |
| cell A1 |
cell A2 |
cell A3 |
| cell B1 |
cell B2 |
cell B3 |
| cell C1 |
cell C2 |
cell C3 |
"Eventually, the ability to save text with a particular language
construct can be associated with membership in a security group. A
user not assigned to the language's security group will not be able to
modify a page containing that language, nor will they be able to save
a page that invokes the language."
All I can say is that I would never use this functionality, as it
introduces a new layer of complexity.. I have to worry about
permissions and the language being used in a page.
Sy, I understand that you wouldn't. This is a feature an individual
user, or a group of trusted users, would never use. But it becomes
important when you trust some people and not others, what ever the
reason. ;-)
* Language processing instructions: Shorten to <html>, <php>, etc? or
if not, also allow "lang-html" etc..
NACK. In the internal XML it could be represented this way,
but the <? ?> syntax is a community standard that will be
recognized for what it is doing, and it draws a clear distinction
between data and instruction. Novice users will not be exposed to it,
so I don't think their reaction to it is significant.
Overall, I agree. In particular, I'm curious about the proposed
page-inclusion functionality, the table markup syntax and the
administrator-managed languages.
So am I. :-) I wanted to get a concrete proposal out there to
discuss, before we self-destructed over wiki-text issues!
Paul
|
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| |
