![[Home]](/tavi.png)
The idea is simply to create a standard for giving options to TaviMacros and to certain elements. Examples on how to use this, if implemented, is given below. The basic thought is to be able to write options within curly braces which either is the first option within a TaviMacros-setting, or connected to the starting element marker. Within the curly braces different options are separated by comma, and each option (which are to be in lowercase) could be given a value by using option=value-pairs (or simply an option without a value attached (the option is the value)).
Here is two examples on the syntax, one with macros and one with headings:
[[TaviMacro {display=oneline,class=classname} Some thing else ]]
=={style=background:yellow} A yellow heading ==
I like the TaviCategories idea and the use of RecentChanges, but I would love to be able to have different display options. I.e. without (history) link, sorted alphabetically, grouped by date.
In addition I've often use CSS to do styling of certain elements. Changing list appearances, placing of images, colouring stuff, and so on. By adhering to a standard option scheme we might incorporate that every option recognize the following:
This gives the user the option to apply some given CSS-stylesheet, where corresponding classes/ids are presented. Or if so wanted the user could give the style directly using the styles.
An example of actual use is given in TaviPatches/TableFormatting. In TaviPatches/TitleSearch I do use options, but they are not yet within curly braces and there the options are WikiNames. (I will change this patch shortly to be coherent with this suggestion.
Q: Why use curly braces ?
A: They seem to be a logical choice, since they are not in use elsewhere, and not commonly in use in ordinary text.
Q: Why place them in front, instead of at the end?
A: By placing them in front one has the option of macros having several arguments without making the matching of option too hard. It's rather easy to match an optional set of TaviSuggestions/CurlyOptions at the start.
Q: Will this break existing implementations somehow?
A: No, since options are optional they don't need to be there, but they could be here to enhance aspects of the given macro or element.
Q: Is it needed to use full-length option names?
A: It could be easily be implemented such that only the shortest unique prefix is used to name the option.
Q: Why lowercase option-names?
A: Simply to avoid option-name wrongly be reported as WikiNames.
Q: What about multiword option-names?
A: These could either be implemented as multi_word or multi-word.
Q: While this is neat for "power users" and a simple, elegant and general way of giving options to macros and markup, it's less attractive/intuitive to non-programmers, which I believe is a significant "target group" for Wiki systems (since Wiki syntax is so much simpler than HTML).
A: In order for CSS-styling to work, the styles need to be defined. That is the administrator has to present a certain stylesheet. Therefore I think that it's acceptable to raise the limit a little on how to do this, because there need to be a page describing which options are available.
Q: Could we come up with some more intuitive notation which handles "standard" cases and is still general/extensible, while not colliding with this? Maybe boolean options like {left}, {center} etc, or {<}, {><} etc?
A: Do also note that options do not need to take on a value, they could easily be boolean options as you say like {center}
Q: Could we find a way to give options to paragraphs, e.g. centered text, using this basic syntax?
A: Just now 'Tavi has a problem recognising paragraphs (one of it's biggest flaws in my opinion), but when that is sorted out I don't see why a paragraph simply could start with TaviSuggestions/CurlyOptions. (That is use start-of-line as the start element to link the options to)
Q: What would the syntax be to give more than one style parameter, e.g., "background:yellow,color:green"?
A: Use {style=background:yellow;color:green}. The only one giving me a bit of a headache is if one needs to use a comma in such a style declaration.
