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)
<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>
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. .
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.
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’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.
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.
Heuristics. Does it look like a title? e.g. 8 or more spaces, and a newline. (I don’t like this idea)
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:
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: