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