Markup spec/BNF/Inline text

"Inline text" is the guts of Wikitext formatting. It covers every situation where "normal" text is allowed, such as image captions, table data, and to an extent (yet to work out how to enforce this restriction...), headings and link text.

            ::=  []          ::= |                             |  |                             |  |                             |  |  |  |  |  |  |                             | (more missing)... ::= ( - ) [ ]

Detail:
 * noparse-block: ../Noparse-block
 * link: ../Links/
 * magic-link: ../Magic links/

The parser should try the options in order, with text matching if all else fails.

Formatting
Bold/italics is the biggest problem with switching to a consume-parse-render parser. It will not be possible to describe the current, extremely esoteric rules in simple (E)BNF. The best we can hope for is to store tokens representing the apostrophe clumps and do a second pass to make more sense of them. It would be very useful to define a second, unambiguous set of formatting syntax (most likely // and **), and encourage people to use those wherever apostrophes and bold/italics meet.

It is currently possible to do this: Some text in bold-italics followed by just italics followed by normal text.

The grammar and parser will be simpler if we disallow this.

     ::= "'"             ::= "'''" <italic-toggle>          ::= "''"

Rendering

 * Once the parser has decided which way the toggles go:
 * bold-toggle-on -> &lt;b>
 * bold-toggle-off -> &lt;/b>
 * italic-toggle-on -> &lt;i>
 * italic-toggle-off -> &lt;/i>
 * bold-italic-toggle-on -> &lt;b> &lt;i>
 * bold-italic-toggle-off-> &lt;/i> &lt;/b>

Inline HTML
The parser recognises and cleans a large number of HTML tags, as defined in Sanitizer.php.

A decision has to be made here on whether to attempt to parse these things as a matched set, or whether to leave that to a later pass.

A loose definition assuming they are treated individually: <InlineHTML>             ::=  <InlineHTML-Open> | <InlineHTML-Close> | <InlineHTML-OpenClose> | <HTMLComment> <InlineHTML-Open>        ::=  "<" <InlineHTMLtagname> [<extra-characters>] ">" <InlineHTML-Close>       ::=  "</" <InlineHTMLtagname> [<extra-characters>] ">" <InlineHTML-OpenClose>   ::=  "<" <InlineHTMLtagname> [<extra-characters>] "/>" <extra-characters>     ::= <word-boundary-char> {characters - ">"} <word-boundary-char>     ::= " " | "-" | ":" | " " | "\"" | "/" | "*" | "#" | "!" | "$" | "%" | ...

<HTMLComment>            ::= ""
 * Remarks:
 * The range of "word-boundary-char" seems to be an artefact of the regular expression:


 * The list of "tags that must be closed" :
 * b, del, i, ins, u, font, big, small, sub, sup, h1 h2, h3, h4, h5, h6, cite, code, em, s,
 * strike, strong, tt, var, div, center, blockquote, ol, ul, dl, table, caption, pre,
 * ruby, rt, rb , rp, p, span, u


 * Tags that can appear singly or paired
 * br, hr, li, dt, dd


 * Tags that must not be paired:br, hr


 * Tags that can be nested (source code is dubious on this)
 * table, tr, td, th, div, blockquote, ol, ul, dl, font, big, small, sub, sup, span


 * Tags that can only appear inside a table:
 * td, th, tr,


 * Tags that make lists:ul,ol,


 * And tags that can appear inside lists:li

The significance of these groupings is shown as follows: A "B C" D E Here, blockquote and span are both "nesting" tags. When the close-blockquote tag is found inside the span block, it is escaped.

This doesn't work: Some text But this does: '''Some text

Rendering

 * Tags that have to be paired are forced closed according to some sort of logic.
 * <extra-characters> are "sanitized", strip all but pre-approved attributes and styles on a whitelist.
 * Tags are then written out literally:  etc.
 * HTML comments are completely discarded, with some whitespace massaging: (sanitizer.php)
 * To avoid leaving blank lines, when a comment is both preceded and followed by a newline (ignoring spaces), trim leading and trailing spaces and one of the newlines.

Open/close guillemet
This is pretty trivial and used to improve the appearance of quotations in European languages, notably French. Performed directly in the parse method. <open-guillemet>         ::= "&laquo;" " " <close-guillemet>        ::= <non-space-character> "&raquo;" " "

Rendering

 * In both cases, the space is converted to a "&amp;nbsp;" string.
 * In the second, the non-space character is presumably rendered literally. This is probably not a good way to express the original regular expression:

Magic words
Not to be confused with magic links. These seem to be able to be used virtually anywhere: a table of contents in an image caption even works. See m:Help:Magic words. <magic-word>              ::= <magicword-toc> | <magicword-forcetoc> | <magicword-notoc> | <magicword-noeditsection> | <magicword-nogallery> <magicword-toc>           ::= "" <magicword-forcetoc>      ::= "" <magicword-notoc>         ::= "" <magicword-noeditsection> ::= "" <magicword-nogallery>     ::= "__NOGALLERY__"

Notes:
 * These are the "default" strings to be matched. They can be modified in  where Xx is the language.
 * Each magicword can have more than one string associated with it.
 * The magic words are by default case insensitive but this can be changed in the file.
 * Plenty of other "magic words" exist, including "magic variables" (eg August ) which will be handled by the preprocessor. However it looks like all sorts of other "magic words" exist and are processed in different places.

Semantics

 * magicword-toc: a miniature contents page will be rendered and inserted at the first instance of this token.
 * magicword-forcetoc: a contents box will be rendered even if the normal criteria (typically, 4 sections) have not been met. Irrelevant if magicword-toc is present.
 * magicword-notoc: no miniature contents pages will be rendered. Only takes effect if neither magicword-toc nor magicword-forcetoc are present.
 * magicword-noeditsection: no edit links are to be displayed for any sections.
 * magicword-nogallery: unclear. According to the code (parser::stripNoGallery): if the string __NOGALLERY__ (not case-sensitive) occurs in the HTML, do not add TOC. Perhaps it only has an effect in certain namespaces.

Images, media, gallery
Links to images and media should be handled as normal links. It's inline images and media that are being dealt with here. From meta...minor reformatting

Images
ImageInline               ::= "" ; ImageExtension            ::= "jpg" | "jpeg" | "png" | "svg" | "gif" | "bmp" ; ImageOption               ::= ThumbImageParameter | SizeImageParameter | AlignImageParameter | Caption ThumbImageParameter       ::= "thumb" | "frame" | "enframed" | "thumbnail" ; SizeImageParameter        ::= PositiveNumber "px" ; AlignImageParameter       ::=  "left" | "center" | "centre" | "right" ; Caption                   ::= <inline-text>

Semantics

 * Renders an image inline using the  tag.
 * It is not an error to specify multiple alignment parameters; the first specified is the one used.
 * It is not an error to specify multiple captions; the last specified is the one used.
 * The caption has no effect if ThumbImageParameter is not given.

Media
MediaInline              ::=  "", "Media:" , PageName "." MediaExtension "" ; MediaExtension = "ogg" | "wav" ;

Gallery
GalleryBlock              ::=   "" ; GalleryImage              ::=   (to be defined: essentially   foo.jpg[|caption] )

Remarks:
 * The gallery block can technically be used in the middle of a sentence so is not a "special block". It doesn't render particularly nicely when you do that though.