Список стилей
Причина: Много нерабочей и не нужной информации, не отформатировано
Это страница со стилями которые вы можете использовать в тэгах нашей вики, сейчас она на английском, содержит огромное количество ненужной и не работающей информации и просто плохо выглядит. Но свою цель она выполняет уже сейчас, тут действительно есть некоторые рабочие стили которые нигде в другом месте не указаны, рекомендую зайти в режим редактирования кода и читать от туда.
Начинать изменения стоит с добавления тэга <pre> в столб "выдаёт", а после удалить все не рабочие шаблоны.
2.2. Text Formatting 2.2.1. Assorted Paragraphs Blank lines separate paragraphs. Strong emphasis [+example text+] Very strong emphasis [++example text++] Hilighted text
- example text##
Notes [example text] Reversed background color text [rev example text] Red text {r}example text{/r} or <r>example text</r> Green text {g}example text{/g} or <g>example text</g> Blue text {b}example text{/b} or example text Colored text {#FFFFFF}example text{/#} Justified text <>( example ) Argument against: it's should be more about content than about presentation and looks 2.2.2. Citations ??source?? "quote (source)" or 'quote (source)' "quote [source]" or 'quote [source]' 2.2.3. Emphasis (italics) Inline /emphasized words/ //emphasized words //emphasized words// Argument for: Intuitive. Looks like italics. emphasized words Argument for: A natural translation from print, where double-quote means italics. (I added a Gutenberg text to a wiki that uses this, and it naturally italicized where it should have because of this.) ^emphasized words^ _emphasized words_ Argument for: Established popular "markup" in text-only environments Argument against: Ambiguity with computer hostnames and URLs which use underscores These should be quoted anyways ~~emphasized words~~ {I}italicized text ///emphasized words/// Argument against: Too much mark-up. Block [/italicized text/] [i italicized text] 2.2.4. Bold Inline
- bold text*
- bold text**
Argument for: Established popular "markup" in text-only environments Argument against: Ambiguous with established bulleting method
- bold text##
||bold text|| __bold text__ {B}bold text bold text Argument against: Multiple single quotes can look like double quote characters in proportional fonts. Too much mark-up. Too similar to italic, and far too much markup when combining italic with bold. Block [*bold text*] [b bold text] 2.2.5. Inserted Text (underline) Inline _underline_ __underline__ ++underline++ Block [_underline_] 2.2.6. Deleted Text (strikethrough) Inline -strikethough- --strikethough-- Argument against: unacceptable because hyphens are far too common - both single hyphens representing minus signs and double hyphens representing em-dashes. Block [-strikethrough-] -/strikethrough/- 2.2.7. Monospaced Text Inline
technical term
Argument against: could conceivably cause some problem with mathematics. @technical term@ @@technical term@@
- technical term#
- technical term##
Argument for: `#` is often a comment character, and you don't put comments in inline code snippets. `technical term` Argument against: backticks are hard to read in many fonts and can be mangled by typesetting software. 'technical term' Argument against: unacceptable because single quotes are too common. Block [=technical term=] Шаблон:Technical term /*technical term*/ 2.2.8. Literal/Unprocessed Text Inline %%example text%% `example text` ``example text`` Argument against: backticks are hard to read in many fonts and can be mangled by typesetting software. ```example text``` Argument against: Backticks are hard to read in many fonts and can be mangled by typesetting software. Too much mark-up. Block {example text} {{{example text}}} Argument against: Too much mark-up. [%example text%] [\example text\] [=example text=] [esc]example text[/esc] [literal]example text[/esc] Argument against: No benefit over SGML/XML. SGML/XML Markup example text <verbatim>example text</verbatim> <ignore>example text</ignore> <literal>example text</literal> 2.2.9. Superscript Text Inline ^superscript text^ ^^superscript text^^ Block [^superscript text^] 2.2.10. Subscript Text Inline ,,subscript text,, ~subscript text~ vvsubscript textvv Argument against: the name of the wiki that has this syntax has been witheld to avoid humiliating the author. Block [,subscript text,] 2.2.11. Large Text Inline +large text+ Argument against: could conceivably cause problems with mathematics. Block [+large text+] ~+small text+~! 2.2.12. Small Text Inline -small text- Argument against: unacceptable because single hyphens are too common. Block [-small text-] !-small text-! ~-small text-~ 2.2.13. Centered Text Inline {c}example text <:>example text Block >>example text<< ><( example text ) 2.2.14. Left Aligned Text {l}example text <(>example text Block <-( example text ) 2.2.15. Right Aligned Text {r}example text <)>example text Block ->( example text ) 2.3. Line Breaks %%%% >>> \\ BR Argument against: No benefit over HTML. Locale-specific. Obsfuscated abbreviation. 2.4. Headings Method 1 A sequence of heading characters at the beginning of a line indicates heading level. = Heading 1 == Heading 2 === Heading 3 Argument against Less important titles stand out more. ! Heading 1 !! Heading 2 !!! Heading 3 Argument for Intuitive. Exclamation point says: here's something important. Argument against Less important titles stand out more. - Heading 1 -- Heading 2 --- Heading 3 Argument against Less important titles stand out more. Argument against Double hyphens at the beginning of a line may also introduce a signature. Method 2 A sequence of heading characters at the beginning and end of a line indicates heading level.
Heading 1
Heading 2
Heading 3
Argument for Intuitive. Looks like a banner. Argument against Less important titles stand out more. -= Heading 1 =- -== Heading 2 ==- -=== Heading 3 ===- Argument against Forces user to count the correct number of characters twice. Argument against Less important titles stand out more. Method 3 Rule: a sequence of heading characters at the beginning of a line indicates heading level, and any heading characters after the title are ignored.
Heading 1 ======================================
Heading 2 =================
Heading 3
Basically the number of heading characters at the end is ignored, as long as there is at least one.
Argument against While more important titles may stand out, they don't have to. It would be nice if this rule was enforced. Method 4 Rule: a line of text with all-capitalized words. Any Line Of All Capitalized Words Becomes A Heading Argument for Clever. Argument against Actual titles don't have all capitalized words. Argument against Not feasible for most non-English languages. Method 5 Rule: headings are underlined (or over-and underlined) with a printing nonalphanumeric character. The underline/overline must be at least as long as the title text.
=
First Heading
=
Second Heading 21:26, 6 июня 2022 (MSK)21:26, 6 июня 2022 (MSK)Noobiant 69 (обсуждение) 21:26, 6 июня 2022 (MSK) Third Heading
Argument pro Important titles stand out more. Argument against Hard to use with proportional fonts. A possible fix is to just require a minimum amount of underlining (eg. four characters). Method 6 Rule: heading characters plus a number indicate heading level. ---+1 Heading 1 ---+2 Heading 2 ---+3 Heading 3 Method 7 Rule: heading characters plus additional sequence of characters to indicate heading level.
---+ Heading 1 ---++ Heading 2 ---+++ Heading 3 Argument against
- Too much markup.
Argument pro Less important titles stand out more. Method 8 Rule: Change of bullet character indicates change of level
- Heading 1 *
+ Heading 2 +
- Heading 1 *
- Heading 2 - + Heading 3 + Method 9 Rule: Number of heading characters indicates level importance. The highest number of heading characters is heading 1, the second highest is heading 2, etc.
==== Heading 1 === Heading 2 == Heading 3 = Heading 4 Argument pro Important titles stand out more. Argument against There must be a maximum number of levels. Miscellaneous
# enumerated heading text
2.5. Lists and Indentations 2.5.1. Known Bullet Characters
- @ + ! ? > %
o Argument against: The letter 'o' is a word in many languages. x 2.5.2. Unordered Lists Method 1 Rule: a sequence of bullet characters indicate level.
- level 1
- level 2
- level 3
- level 2
000 also aligned with third level, but no bullet ... also aligned with third level, but no bullet Argument for easier to parse. Argument against less intuitive. Method 2 Rule: a sequence of spaces followed by a bullet character indicate level.
- level 1
* level 2 * level 3 * level 5
Argument against Counting spaces, like other invisible characters, is not user friendly. Method 2 Rule: an indent followed by a bullet character indicate level.
- level 1
* level 2 * level 3 * level 4
Method 3 Rule: A change of bullet character indicates level change. Indetation optional.
- level 1
- level 2 + level 3 - level 2 again @ level 3 + level 4 2.5.3. Ordered Lists Method 1 Rule: a sequence of ordered list characters indicate level.
- level 1
- level 2
- level 3
- level 2
- 3 restart numbering from 3
> level 1 >> level 2 >>> level 3 0 level 1 00 level 2 000 level 3 Method 2 Rule: a sequence of spaces followed by an enumerator indicate level. 1. level 1
1. level 2 1. level 3
1.#3 restart numbering from 3 1) level 1
2) level 2 3) level 3
Method 3 Rule: Each level has it's own numeration. 1. level 1 1.1 level 2 1.1.1 level 3 1.2 level 2 2.5.4. Indentations / Block Quotes Method 1 Rule: a sequence of spaces indicates indentation level.
outer
indent 1 indent 2
Method 2 Rule: a sequence of indentation characters indicates indentation level. outer
- indent 1
- indent 2
outer > indent 1 >> indent 2 Argument for: commonly used when pretty-printing e-mails and news posts. 2.5.5. Definition Lists Method 1
- Term
- Definition
$ Term: Definition
Method 2 Term:: Definition Method 3 Term:
Definition
2.6. Tables Method 1: Sequence of Rows | col1 | col2 | col3 | || col1 || col2 || col3 || Method 2 [| col 1, row 1 || col 2, row 1 || || col 1, row 2 || col 2, row 2 |] Method 3: Drawing Boxes +------------+------------+-----------+ | Header 1 | Header 2 | Header 3 | +============+============+===========+ | body row 1 | column 2 | column 3 | +------------+------------+-----------+ | body row 2 | Cells may span columns.| +------------+------------+-----------+ | body row 3 | Cells may | - Cells | +------------+ span rows. | - contain | | body row 4 | | - blocks. | +------------+------------+-----------+ Argument against Very hard to parse and takes a lot of effort to type. |---------------------| | Header 1 | Header 2 | |=====================| | Column 1 | Column 2 | |---------------------| Method 4
===== =
Inputs Output
------
A B A or B
===== =
False False False True False True False True True True True True
===== =
Method 5: Definition Tables Term 1 |
Definition 1 begins here. Term 1.1 | Definition 1.1 Term 1.2 | Definition 1.2 This is part of definition 1.
Term 2 |
Here's definition 2.
Method 6: Wiki-pipe Syntax
heading 1 | heading2 | heading 3 |
---|---|---|
text 1a | text 2a | text 3a |
text 1b | text 2b | text 3b |
Method 7: Relational [[Table][Seperator=;] [Columns=Person,Height,Weight] Person=Person; Height=Height; Weight=Weight Person=Peter; Height=180; Weight=84 Person=Martha; Weight=52; Height=167 ] 2.6.1. Cell Attributes Cell Attribute Specification |abc ||<abc> ||{a,b=c} Cell Attributes in Use Top alignment {t} or <^> Bottom alignment {b} or <v> Column spanning {w=number} or <-number> Row spanning <|number> Border width {Tb=number} Cell class {C=string} Cell style {s=string} Cell width <100%> Background color <#XXXXXX> Miscellaneous |<<END|<<END| col1 text is here END col2 text is here END 2.7. Horizontal Rules/Separators ---
(4 dashes at beginning of line--extra dashes are ignored.)
____ (4 underscores at beginning of line)
(4 dashes at beginning of line--more than 4 gets thicker.)
Argument against: This seems like a petty stylistic feature which I can't imagine someone actually caring about. Discussion Having four as a minimum is totally arbitrary. Parsing is not ambiguous as a separator should begin and end with a newline. Thus the only possible ambiguity is for the reader in that a small separator could get "lost" in the document. -- IanBollinger? One and two could not be the minimum for obvious reasons. Three cannot for I've seen at least one Wiki that uses --- for an em dash, and some word processors do as well. So four hyphens is the minimum number that can safely be chosen. 2.8. Meta-Wiki 2.8.1. Macros, Variables, Plugins and Extensions MacroName(arguments) <MacroName> <MacroName(arguments)> @MacroName@ Шаблон:MacroName(arguments) %MacroName{"parameter" key="named parameter"}% <?plugin MacroName arg1=val1 arg2=val2 ?> [[MacroName][parameter=value]...body...] $MacroName 2.8.2. Comments
- comment
- comment
SGML/XML Markup <hide>comment</hide> 2.8.3. Processing Instructions and Meta Data
- TYPE value
@type:name:value %META:type{arg1="val1" arg2="val2"}% 2.9. Character Replacement -- becomes an em-dash. (—) 1-1 becomes an en-dash. (1–1) "text becomes a double left quote. (“text) text" becomes a double right quote. (text”) 'text becomes a single left quote. (‘text)
** Argument against: some English abbreviations begin with single right quotes ("I said 'e would").
don't becomes a single right quote. (don’t) text' becomes a single right quote. (text’) ' becomes ' in XML. > becomes > in SGML/XML. < becomes < in SGML/XML. & becomes & in SGML/XML. ff, fi, fl, ffi, ffl and st become their appropriate ligatures.