Product Code Database
Example Keywords: ipod -playbook $95
   » » Wiki: Lightweight Markup Language
Tag Wiki 'Lightweight Markup Language'.
Tag
A lightweight markup language ( LML), also termed a simple or humane markup language, is a with simple, unobtrusive syntax. It is designed to be easy to write using any generic and easy to read in its raw form. Lightweight markup languages are used in applications where it may be necessary to read the raw document as well as the final rendered output.

For instance, a person downloading a software library might prefer to read the documentation in a text editor rather than a web browser. Another application for such languages is to provide for data entry in , such as and , where the input interface is a simple . The server software then converts the input into a common document markup language like .


History
Lightweight markup languages were originally used on text-only displays which could not display characters in or , so informal methods to convey this information had to be developed. This formatting choice was naturally carried forth to plain-text email communications. Console browsers may also resort to similar display conventions.

In 1986 international standard provided facilities to define and parse lightweight markup languages using grammars and tag implication. The 1998 W3C is a profile of SGML that omits these facilities. However, no SGML DTD for any of the languages listed below is known.


Types
Lightweight markup languages can be categorized by their tag types. Like HTML (<b>'''bold'''</b>), some languages use named elements that share a common format for start and end tags (e.g. [b]'''bold'''[/b]), whereas proper lightweight markup languages are restricted to -only punctuation marks and other non-letter symbols for tags, but some also mix both styles (e.g. Textile bq. ) or allow embedded HTML (e.g. ), possibly extended with custom elements (e.g. MediaWiki <ref>'''source'''</ref>).

Most languages distinguish between markup for lines or blocks and for shorter spans of texts, but some only support inline markup.

Some markup languages are tailored for a specific purpose, such as documenting computer code (e.g. POD, RD) or being converted to a certain output format (usually HTML) and nothing else, others are more general in application. This includes whether they are oriented on textual presentation or on data serialization.

Presentation oriented languages include , atx, BBCode, Creole, Crossmark, , , , , Markdown, , POD, , RD, , , , , Texy!, Textile, txt2tags, UDO and .

Data serialization oriented languages include Curl (homoiconic, but also reads JSON; every object serializes), , , and .


Comparison of language features
+ Comparing language features

Markdown's own syntax does not support class attributes or id attributes; however, since Markdown supports the inclusion of native HTML code, these features can be implemented using direct HTML. (Some extensions may support these features.)

txt2tags' own syntax does not support class attributes or id attributes; however, since txt2tags supports inclusion of native HTML code in tagged areas, these features can be implemented using direct HTML when saving to an HTML target.


Comparison of implementation features
+ Comparing implementations, especially output formats ! Language !! Implementations ! (X) ! LMLsOther ! License
Java, pegdown: A Java library for Markdown processing , gfms: Github Flavored Markdown Server marked: A full-featured markdown parser and compiler, written in JavaScript. Built for speed. node-gfm: GitHub flavored markdown to HTML converter , Parsedown: Markdown parser written in PHP Ciconia: Markdown parser written in PHP Python, Grip: GitHub Readme Instant Preview Ruby github-markdown: Self-contained Markdown parser for GitHub Proprietary


Comparison of lightweight markup language syntax
Although usually documented as yielding italic and bold text, most lightweight markup processors output semantic HTML elements class and id instead. Monospaced text may either result in semantic em or presentational strong elements. Few languages make a distinction, e.g. Textile, or allow the user to configure the output easily, e.g. Texy.

LMLs sometimes differ for multi-word markup where some require the markup characters to replace the inter-word spaces ( infix). Some languages require a single character as prefix and suffix, other need doubled or even tripled ones or support both with slightly different meaning, e.g. different levels of emphasis.

+ Comparing text formatting syntax
codett<strong>strongly emphasized</strong>Can double operators to apply formatting where there is no word boundary (for example <em>emphasized text</em> yields bold t ext).
<code>code</code><b>bold text</b>
<i>italic text</i><tt>monospace text</tt>
<nowiki></nowiki>
<nowiki></nowiki><nowiki></nowiki>presentational HTML tags
<nowiki></nowiki>

+ Bold face or strong emphasis
Code ! AsciiDoc !! ATX !! Creole !! Markdown !! MediaWiki !! Org-mode !! PmWiki !! reST !! Setext !! Slack !! Textile !! Texy! !! txt2tags !! WhatsApp

+ Italic type or normal emphasis
Code ! AsciiDoc !! ATX !! Creole !! Markdown !! MediaWiki !! Org-mode !! PmWiki !! reST !! Setext !! Slack !! Textile !! Texy! !! txt2tags !! WhatsApp

+ Underlined text
Code ! AsciiDoc !! ATX !! Creole !! Markdown !! MediaWiki !! Org-mode !! PmWiki !! reST !! Setext !! Slack !! Textile !! Texy! !! txt2tags !! WhatsApp

+ Strike-through text
Code ! AsciiDoc !! ATX !! Creole !! Markdown !! MediaWiki !! Org-mode !! PmWiki !! reST !! Setext !! Slack !! Textile !! Texy! !! txt2tags !! WhatsApp

+ Monospaced font, teletype text or code
Code ! AsciiDoc !! ATX !! Creole !! Markdown !! MediaWiki !! Org-mode !! PmWiki !! reST !! Setext !! Slack !! Textile !! Texy! !! txt2tags !! WhatsApp


Heading syntax
Headings are usually available in up to six levels, but the top one is often reserved to contain the same as the document title, which may be set externally. Some documentation may associate levels with divisional types, e.g. part, chapter, section, article or paragraph.

Most LMLs follow one of two styles for headings, either -like underlines or atx-like "atx, the true structured text format" by Aaron Swartz (2002) line markers, or they support both.


Underlined headings
Level 1 Heading
 

===
Level 2 Heading ---------------

Level 3 Heading ~~~~~~~~~~~~~~~

The first style uses underlines, i.e. repeated characters (e.g. equals <nowiki></nowiki>, hyphen <nowiki></nowiki> or tilde <nowiki></nowiki>, usually at least two or four times) in the line below the heading text.
+ Underlined heading levels ! Chars: ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> !title=“Minimum of characters”min

RST and Texy determine heading levels dynamically, which makes authoring more individual on the one hand, but complicates merges from external sources on the other hand.


Prefixed headings
# Level 1 Heading
 
    1. Level 2 Heading ##
      1. Level 3 Heading ###
The second style is based on repeated markers (e.g. hash <nowiki></nowiki>, equals <nowiki></nowiki> or asterisk <nowiki></nowiki>) at the start of the heading itself, where the number of repetitions indicates the (sometimes inverse) heading level. Most languages also support the reduplication of the markers at the end of the line, but whereas some make them mandatory, others do not even expect their numbers to match.
+ Line prefix (and suffix) headings ! Character: ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! Suffix ! Levels ! Indentation

POD and Textile choose the HTML convention of numbered heading levels instead. Org-mode supports indentation as a means of indicating the level. does not support section headings at all.

+ Other heading formats


Link syntax
Hyperlinks can either be added inline, which may clutter the code because of long URLs, or with named <nowiki></nowiki> or numbered <nowiki></nowiki> references to lines containing nothing but the address and related attributes and often may be located anywhere in the document. Most languages allow the author to specify text <nowiki></nowiki> to be displayed instead of the plain address <nowiki></nowiki> and some also provide methods to set a different link title <nowiki></nowiki> which may contain more information about the destination.

LMLs that are tailored for special setups, e.g. wikis or code documentation, may automatically generate named anchors (for headings, functions etc.) inside the document, link to related pages (possibly in a different namespace) or provide a textual search for linked keywords.

Most languages employ (double) square or angular brackets to surround links, but hardly any two languages are completely compatible. Many can automatically recognize and parse absolute URLs inside the text without further markup.

+ Inline hyperlink syntax ! Languages ! Basic syntax !! Text syntax !! Title syntax

+ Reference syntax ! Languages ! Text syntax !! Title syntax

... anchor:id ... xref:id... anchor:id ... xref:idText

!rowspan=3

Markdown... Textid ... id: http://example.com... Textid ... id: http://example.com "Title"
... Text ... Text: http://example.com... Text ... Text: http://example.com "Title"
... Text ... Text: http://example.com... Text ... Text: http://example.com "Title"


List syntax
HTML requires an explicit element for the list, specifying its type, and one for each list item, but most lightweight markup languages need only different line prefixes for the bullet points or enumerated items. Some languages rely on indentation for nested lists, others use repeated parent list markers.

+ Unordered, bullet list items ! Characters: ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> !title="middle dot"<nowiki></nowiki> !title="bullet"<nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> !title="en-dash"<nowiki></nowiki> !title="em-dash"<nowiki></nowiki> !title=“number of whitespace characters before the line prefix”indent !title=“number of whitespace characters after the line prefix”skip ! nest

Languages differ on whether they support optional or mandatory digits in numbered list items, which kinds of enumerators they understand (e.g. decimal digit 1, roman numerals i or I, alphabetic letters a or A) and whether they support to keep explicit values in the output format. Some Markdown dialects, for instance, will honor a start value other than 1, but ignore any other explicit value.

+ Ordered, enumerated list items ! Chars: ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> ! <nowiki></nowiki> !title=“number of whitespace characters before the line prefix”indent !title=“number of whitespace characters after the line prefix”skip ! nest

Slack assists the user in entering enumerated and bullet lists, but does not actually format them as such, i.e. it just includes a leading digit followed by a period and a space or a bullet character <nowiki></nowiki> in front of a line.


See also
  • Lightweight programming language
  • Comparison of document markup languages
  • Comparison of documentation generators


External links

Page 1 of 1
1
Page 1 of 1
1

Account

Social:
Pages:  ..   .. 
Items:  .. 

Navigation

General: Atom Feed Atom Feed  .. 
Help:  ..   .. 
Category:  ..   .. 
Media:  ..   .. 
Posts:  ..   ..   .. 

Statistics

Page:  .. 
Summary:  .. 
1 Tags
10/10 Page Rank
5 Page Refs
1s Time