title. Ideas for my lightweight hypertext language.

Ideas for spans:

*Strong*, _emphasised_, **bold**, __italic__. (Textile)

*Emphasised*, _emphasised_, **strong**, __strong__. (Markdown)

*Emphasised*, _citation_, /italic/, **bold**. I like this.

%I can steal this from Textile% for spans. Look, even:

%<customtag>{color:red;}(class #id) This is what is in my span.%

Some more fancy. A superscript^like this^. What about subscripts? Hrmm:
Like\/this\/? No, that's silly. Don't include superscript or subscript.

For code blocks, something like this (this shows off how the above will
render):

```
<customtag style="color:red;" class="class" id="id">This is what is in
my span.</customtag>
```

I like `backticks` for code spans, though -- see below.

You can make headers using tag prefixes:

h1. This is a level 1 header

or using setext-style headers:

This is a level 1 header
==========
This is a level 2 header
----------

Or using atx-style headers:

# This is a level 1 header

## This is a level 2 header

Headings should automatically get id tags, to allow anchors to jump to
them. There should be syntax on setext and atx headers to specify your
own ids instead of being autogenerated.

Tag prefixes also work for anything else you want to appear at block
level, and can have their own attributes:

div{background-color: #fff;}(my-class #my-id). This is a div.

Thought: How do you include more lw-formatted text inside such a div?
How does its content get to span multiple lines?

Perhaps these rules, partly Textile-inspired:

```
div. Only the stuff on this line (and, depending on what line-break
convention I decide on, subsequent non-blank lines) will be inside the
block, and it will get *span-level* formatting.

div ->
  This will all appear inside the div as block formatting. It must be
  indented at least two spaces or one tab.
  
  This is a second paragraph inside the div.
```

{{{
<p>You can also insert raw HTML like this.</p>
}}}

HTML entities are supported, but not required, everywhere. <span
class="test">This should not auto-transform to HTML,</span> but instead
appear raw -- but things like &copy; and &#8984; should work.

You can make blockquotes using indentation:

    This is a blockquote. It should be indented by at least four spaces
    or one tab.
    
        This is a blockquote inside a blockquote.
    
    Now back to the original blockquote level.

Or using email-style quotes:

> This is a blockquote.
>
> > And this is another one inside it.
> 
> Now back to the original blockquote level.

Linebreak rules:

Textile transforms all line breaks to <br>s. Advantage: intuitive
(unlike the rest of Textile!) and indeed many Markdown variants follow
suit.

Plain Markdown, though, only transforms paragraph breaks. It adds a <br>
if there are two spaces at the end of a line. Advantage: allows you to
hard wrap your source without affecting the result. Disadvantage:
unintuitive, and depends on trailing whitespace, an invisible marker.

Markdown has the right idea, imho: you should be able to hard-wrap
source. But trailing whitespace is the wrong way to make a br. Idea:
steal from TeX: Use \\ trailing a line to indicate a break. Here's a
poem:

    Whose woods these are I think I know. \\
    His house is in the village, though; \\
    He will not see me stopping here \\
    To watch his woods fill up with snow. \\
    My little horse must think it queer \\
    To stop without a farmhouse near \\
    Between the woods and frozen lake \\
    The darkest evening of the year. \\
    He gives his harness bells a shake \\
    To ask if there is some mistake. \\
    The only other sound's the sweep \\
    Of easy wind and downy flake. \\
    The woods are lovely, dark, and deep, \\
    But I have promises to keep, \\
    And miles to go before I sleep, \\
    And miles to go before I sleep.

Works quite well, even though it's a little visually noisy. Ideally
though, this should be an option: There's a good use case for auto-br on
some sites. Should I cater to that use case? GFM etc. seem quite popular
there anyway.

Links:

A perennial conundrum, and tricky. Rules: auto-transform URLs (determine
a good pattern for this -- Gruber's is probably best) to links, and
email addresses with no spaces. (Hum!)

Markdown has the right idea with square brackets, but doubling up is
quite noisy. How about:

```
I just heard about this great new [search engine|se] called [Google.|g]
You don't need the abbreviation if it's the same as the link text, and
they're all case-insensitive and have punctuation stripped: [WordPress,]
for instance, is a blogging platform.

There could also be inline links. [Here's an example.|http://bit.ly/]
(Rule: shortcuts can't contain colons, slashes or dots, otherwise
they're interpreted as inline.)

A useful feature would be a standard internal-link syntax, for wikis and
the like. Maybe just double-up the square brackets and change the alias
for a page name, MediaWiki style?

[se] http://en.wikipedia.org/wiki/Web_search_engine
[g] http://google.com/
[wordpress] http://wordpress.org/
```

Quote symbols:

``Double quoted" and ``Double quoted again'', now `single quoted'.
Should leave this to something like SmartyPants?

"I like this type," too. 'Backticks' are nice and TeX-y -- and don't
allow confusion in the case of ``'Twas the night before Christmas'' --
but distracting to think about, and can in most cases be done
automatically. The "’Twas" case can be fixed by using Unicode if you
really want.

Conclusion: leave this stuff to something like SmartyPants.

Lists:

* This is a list.
+ You can also use pluses ...
- ... or dashes ...
* ... and mix them all together in a single list!
• For completeness, U+2022 BULLET is also a valid bullet.

Semantic: in applications that require it, + items in lists can be said
to be "checked", - items can be said to be "unchecked". Example uses of
this semantic are todo-lists and quizzes.

Nesting:

* This is a list
  
  This is a second paragraph of the list item.
* * This is a sublist of the list above.
* * This is a second item in the sublist.

1. You can also make an ordered list.
2. Like this, see.

I. ... with Roman numerals, too ...
II. Like this!

i. Or lower case roman numerals.
ii. See below for potential problems with this.

a. Or with letters.
b. Like this.

Potential problems with this: we could misinterpret i., a., b. etc. as
tags. Hopefully we can safely special-case these, as they're all inline
tags anyway. If you really want a block-level i tag, you could do this:

i<i>. Example.

Images, Figures:

Images are like links, in that they refer to an external document.

Markdown uses an exclamation mark before its normal link syntax. Textile
uses exclamation marks around the URL of the image. Mnemonic: ! is an
upside-down 'i' for 'image'.

Broadly, I agree with Markdown's approach. Here's an image, three times,
showing off the alt tag syntax, too:

![http://dpk.io/lena.jpg]

![Lena, the standard test image.|http://dpk.io/lena.jpg]

![Lena, the standard test image.|lena]

[lena] http://dpk.io/lena.jpg

HTML5 introduces a <figure> element, as well as <figcaption>. One possible
markup for this is just the normal block syntax:

figure ->
  ![Lena, the standard test image.|lena]
  
  figcaption. In November 1972, Lena Söderberg posed as the Playboy
  magazine's Playmate of the month. Her photo was scanned by Alexander
  Sawchuk and used in an image processing experiment, and has been the
  standard test image for such experiments since.

This is kind of verbose, but it'll do for now.

Footnotes:

Markdown's semi-standard syntax is nice. We make one small change: no
colon after the square bracket in the definition.[^afn] One, two, three,
fowr.[^2fn]

[^afn] This is a footnote.
  
  As long as you indent by two spaces or one tab, they can contain
  multiple paragraphs too!.
[^2fn] Mind your business, mind your business.

Footnote output syntax should be customisable.