krmckone
commented
3 years ago I've swapped out 1. for 2. and its parser extension 3. which implements block-level attributes. 1. Had Block level attributes as a first-class feature but I was having trouble getting it to render markdown within HTML. I believe this is due to lack of compatability with common mark spec. 2. seems to implement common mark spec as a requirement. 2. also appears to focus inherently on extensibility, which opens the ability for 3. to be easy to implement; 3. exists as common mark does not require support block-level custom attributes outside of headers. Thus with those two modules I'm back up and running and able to have something like
<div class="hero is-light">
<div class="hero-body">
<div class="container">
## Hero Title {.title}
### Hero Subtitle {.subtitle}
</div>
</div>
</div>
<section class="section">
<div class="container">
### Header0 {.title}
{.subtitle}
Let me know what you think.
This is simple container within a section
</div>
</section>render as I expect as
which is very nice. The only draw back is that this would require users to mix both HTML and markdown since markdown itself does not have a concept of HTML tags such as div/section/etc. What I am thinking then is that the process of building pages will need to essentially be "pipelined".
(a.) Markdown content -> (b.) render custom vars in markdown -> (c.) parse using goldmark -> (d.) render to HTML -> (e.) template the rendered markdown content with pre-defined HTML components for header/nav/sidebar/footer etc, rendered as well with custom vars (branding)
The last step then is where we actually stitch together the components of the page. Most of actual user-provided content of the page will likely be from the Markdown content from (a.). We will still allow plenty of customizing/branding of the footer and header, but side and topnav will likely be generated automatically based on the requirement of links to other pages the user wants to build in order to allow proper navigation.
With this order of the pipeline, I don't actually think it matters that we swap 1. for 2./3. since the header and footers will already be in the form of HTML and we will just template custom vars; the only Markdown content that will need to be rendered is the "main" content. However, I do think I will go forward with the change since I do like flexibility 2. offers with extensions.
Header, footer, consistent text areas, table of contents, nav, posts, etc. This may include the automation of adding block-level attributes. To start just explicitly add block-level attributes where needed.
I would like templates to be of the form
Where {{.Header}} is a template with the definition of the header, similarly followed by definitions for {{.PageContent}} (which may include a TOC, sidenav, and actual page content), and {{.Footer}}. Each definition would be located in a header.md, pagecontent.md, footer.md, etc.