Document titles


#26

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

#27

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.


#28

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.


#29

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?


#30

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.


#31

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).


#32

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.


#33

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.


#34

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 >>

#35

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.


#36

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


#37

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


#38

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

#39

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


#41

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.


#42

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


#43

I see. Just noticed that thread about it Description List

Well lets just stick to only this form then, for lazy meta data description. I have not seen many objection to this form. Just don’t stack it. It’s in YAML.

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

#44

I would probably still use the Jekyll style front matter as it does not require the writer to add | at the start of every line. It’s also consistent with how code blocks are written. No strong objection to including both though.


#45

Actually, there is an objection. Pandoc uses a pipe at the start of a line to represent a line block. I think this is the equivalent of the <pre> tag in HTML. It looks like a useful extension to have.

Perhaps something similar to Pandoc metadata blocks could be supported instead, e.g.

% title: Title for the top bar of any browser
% layout: report

#46

% seems not used for other purposes in the usual suspects so might be good together with the Jekyll/Hyde/Flask-FlatPages/nanoc syntax.