Document titles

Document title

I agree with kagan, that a run of spaces before a word as first or second line is probably a title, and should be auto recognised as such. And treated as <h1>. As for why? It’s because I would hate to have to keep typing ## throughout the entire document (As you would see in my metadata via | example below)

e.g.

lazy headers (only works if you add enough spaces)

                 Blogging Like a Hacker

| title: This is a title

... intro ...

# My First Chapter

## Level two header

Lorem ipsum (TBC)

or ( typical markdown Setext-style headers. Recall that ===... is h1 and ---... is h2 ). Not sure if this is a good idea, since it’s not immediately obvious that it is a document title, since it is typically used for subheadings.

Blogging Like a Hacker
=======================
| title: This is a title

... intro ...

# My First Chapter

## Level two header

Lorem ipsum (TBC)

or ( non-standard Setext-style headers, but specifically used to demarcate document titles). Babelmark2 shows that ###... is not supported anywhere, so is a good candadate for document title declaration babelmark2 :

#################################################
            Blogging Like a Hacker
#################################################
| title: This is a title

... intro ...

# My First Chapter

## Level two header

Lorem ipsum (TBC)

is rendered as (note: usage of header tag ):

<head>
    <title>This is a title</title>
</head>
<body>
   <header>
    <h1>Blogging Like a Hacker</h1>
    <p>... intro ...</p>
   </header>
   <main>
    <h1> My First Chapter </h1>
    <h2> Level two header </h2>
        <p>Lorem ipsum (TBC)</p>
   </main>
</body>

Metadata

Moved to

http://talk.commonmark.org/t/metadata-in-documents/721

While I agree it would cause no harm for an implemention to do this, I think that most implementations typically never generate any <head> tags at all, so it would complicate spec matters significantly to specify correct placement of a <meta> tag. .

The fenced (---) YAML approach is shared across jekyll, hyde, plume, nanoc actually.

And would be better to keep this kind of markup at the application level.IMHO.

1 Like

Are you suggesting that a single # should be changed to <h2> in the case that a title with a run of spaces is added to the top of the file? If so, I can see this being confusing for people copy/pasting text from different Markdown files that use a single # to mean <h1>.

I’d prefer to keep as much XML-like syntax out of Markdown as possible. Markdown isn’t primarily for parsers, but for human readers (as Gruber writes in the philosophy of Markdown, “Readability, however, is emphasized above all else.”). Just as YAML is more readable than XML because it is closer to something a writer might jot down in a text editor, Markdown should lean towards being less of programmers tool and more of a writer’s tool.

1 Like

Yea, I should change that post. Best to maintain consistency. Though how would you make the main document title be like <h0> or something.

Agreed on keeping out XML syntax, it’s why we switched to markdown in the first place. However I would like to say that for document declaration, we should consider if we need to go with <!CommonMark 0.1.23-github.username.projectname > to inform the parser which version to use. But would like to be convinced that placing the document declaration as a meta data would still work. (Since it’s much nicer to look at)

e.g.

                     My Title

| !CommonMark: 0.1.23-github.username.projectname
| title: Title for the top bar of any browser

vs

<!CommonMark 0.1.23-github.username.projectname >

                     My Title

| title: Title for the top bar of any browser

I would keep that as application-specific and possibly fit within the current target users of the markup.

Namely: hyde, jekyll, Flask-FlatPages, nanoc.

Anything that would make their life or the life of their users harder is counterproductive.

I’m not quite sure what you mean here. There is no <h0> HTML tag, so the main document heading would need to be <h1>.

What I meant is that subsequent headings would need to be ## which translates to <h2> for consistency when copy/pasting between Markdown documents. If we went with an overall heading it would need to be <h1> regardless of the Markdown syntax used.

1 Like

I see a problem with using spaces to represent a document heading; four spaces are already used to represent a code block. What if the writer wanted to put a code block on the first line?

Ah… that’s so true, and so annoying as well. There is two potential ways to tackle that.

  1. Heuristics. Does it look like a title? e.g. 8 or more spaces, and a newline. (I don’t like this idea)
  2. Only allow lazy document titles ‘before’ a document declaration like below. The code will be placed after the document declaration. As for why? In most cases where you declare a lazy title, it would most likely be for a dedicated document. (I prefer this idea)
  • Best thing about this approach, is you can declare multiple lines to be a header. E.g. like the front page of a report.

e.g.

                 The Report
              By Robert Smithly
                    2042

| !CommonMark: 0.1.23-github.username.projectname
| title: Title for the top bar of any browser
| layout: report

    Function(2+2);

The above function is rendered as a code block, while the title is treated as h1 since it is before the document declaration. This is a simulated paragraph.

the document declaration is metadata located on top of document (via compact metadata syntax):

| !CommonMark: 0.1.23-github.username.projectname
| title: Title for the top bar of any browser
| layout: report

Which if user is lazy enough, can just simply be |

                               The Report
                            By Robert Smithly
                                  2042
|

The above function is rendered as a code block, while the title is treated as h1 since it is before the document declaration. This is a simulated paragraph.

The reason why I really really would like some lazy document title, at least for stand alone documents, is that it looks much prettier.

If you resize the editor window it’s not going to remain centred which could make the heading look a bit odd. At least with an underlined heading (or a heading prefixed by #) it will look consistent. IMO, Markdown doesn’t need to aim to look so close to the actual output, especially if the same document’s presentation differs when reused across different sites (some site headings might be centred, others left aligned).

I guess, but at least it would still be a choice for users. I mean, it could probbly mean the same thing to type. ( multiple spaces doesn’t matter, since it is unlikely people want to type code for the title page. But can have bold or italic) (Usually implicitly # in document title, but can be overrid by ##)

The Report
##   By: **Robert Smithly**
## Year: 2042

| !CommonMark: 0.1.23-github.username.projectname
| title: Title for the top bar of any browser
| layout: report

The above function is rendered as a code block, while the title is treated as h1 since it is before the document declaration. This is a simulated paragraph.

This way it is left up to the user how they want to lay out the document title in text form.

The writer might not intend for the first line to be heading though. For example, the document may just be some causal notes with no need for a heading.

Then you place it under the document declaration. (If document declaration is not done, then there is no cover page, but the first header will be auto detected as the page title.)

<< This area is for the 'Cover Page' and title >>

| !CommonMark: 0.1.23-github.username.projectname
| title: Title for the top bar of any browser
| layout: report

<< This area is for everything else like casual notes >>

Markdown doesn’t traditionally support the concept of “pages”; it’s more fluid than that. A piece of Markdown is usually pastable between different parts of different documents. Markdown typically represents a section of an HTML document, rather than the entire document.

That’s not to say that supporting cover page use cases is a bad idea, but I do think any syntax should be defined in more abstract terms that correspond to particular HTML elements. You would typically use a “print” stylesheet in CSS for print documents and apply page break rules to particular HTML elements.

It is common to reuse a document heading in multiple places. For example, the following HTML is common:

<html>
  <head>
    <title>Site Name - Article Name</title>
  </head>
  <body>
    <img src="site-name-logo.png" alt="Site Name's Logo" />
    <h1>Article Name</h1>
  </body>
</html>

As you can see, the article name is reused in two places. This is essentially our “document heading”.

In my view, it does not make sense to require the writer to define the document heading in two places - that’s tedious and violates the DRY principle. It should be the content management system’s job to reuse the contents of the <h1> tag inside the <title> tag. The same approach could apply to a cover page.

I have been playing with a new static web page generator that reads Markdown. It also reads three different kinds of Document Metadata or Front Matter:

YAML, JSON, or the new TOML

1 Like

--- seems to be quite common for defining YAML frontmatter. Middleman uses this as well, but ;;; for defining JSON frontmatter.

How hard would it be to recognise something like below for Front Matter, in terms of implementation complexity

| !CommonMark: 0.1.23-github.username.projectname
| title: Title for the top bar of any browser
| layout: report

or

| !CommonMark: 0.1.23-github.username.projectname | title: Title for the top bar of any browser | layout: report

given that the second example looks like a table, a lot.

Well if we excude the second example, then | could work well.

Else the other option is to use : as first character of each line to indicate that it is a metadata.

: !CommonMark: 0.1.23-github.username.projectname
: title: Title for the top bar of any browser
: layout: report

It’s not to replace the block YAML or json. But rather to allow for a lazy typing of quick meta data.

Using : at the start of a line might conflict with the data definition list syntax.