Props for the simplicity in getting something published. That's really cool.
Along similar lines, I went back to LibreOffice recently and made a few web pages with it, just to try it out. It worked better than I expected.
After adding a simple PHP controller to the mix, injecting some CSS for responsiveness and other tags as needed, I have been impressed with how easy it makes publishing. If a single-pager is what's needed (or multi-pagers perhaps; I just haven't tried it yet), if what matters most is getting links and information public, it's a useful tool.
Why would you want to constantly recompile documents every time you make an edit to them? Why would you want to juggle two files for every document you produce?
For what it's worth, this is the problem GitLab Pages solves. A simple "git push" to a properly to figured repo will rebuild and redeploy your static site, the actual html output doesnt go into the repo.
Thanks everyone for taking the time to look, and give some feedback. Most definitely better options out there, but I was really aiming for simple, and low tech knowledge to get a md page on the internet.
I added a wiki page https://github.com/oscarmorrison/md-page/wiki explaining a couple of use cases, and some more details. Feel free to leave more feedback / open issues. Thanks
Oscar!
There has been Strapdownjs[1] around for quite a while now. It's simple, supports some theming as well. Anyway, good luck with this. Always fun to build something from scratch.
Noted! Then again, super nitpicking, if that script tag in the beginning is part of the markdown document, then it should also be displayed in the final document.
Throwing in to the list of alternatives to this: http://mdwiki.info which actually does not even require you to create a .html file, but just plain .md files and a standard/template version of mdwiki as index.html.
Disclaimer: I am the author of it, and it is nowadays unmaintained.
Back in 2013 I did a similar thing for a client with a popular code library.
Their documentation was written in markdown and the site was hosted on static hosting, so no server-side conversion.
Although the web page chrome (navigation, etc) was in HTML, they wanted the documentation to be in markdown under the hood after upload. They didn’t want to use any kind of conversion prior to uploading because they needed to make on-the-fly changes to the documentation after upload without writing in HTML.
So we opted to go with client-side markdown to html conversion on pageload. complete with a clickable legend and tabs to switch between language implementations for code examples.
Putting the markdown inside regular page formatting tags wasn’t reliable, as different browsers did different things to the content (for example some browsers converted “&” to “&” and the indentations for code was not respected). So we had to store the markdown in some sort of preformatted tag block.
However <pre> required special escaping of code characters ( <, >, &, etc).
So we opted to go with using a little-known <xmp> tag to store the markdown as search-engine indexable code. Since content inside <xmp> will be read as plaintext instead of being formatted by the browser, it was also great for being the input of a client-side markdown-to-html converter.
Sometimes I just want to get some information out there on the internet, and rather than sharing a Evernote page or having to create a webpage I can just write markdown.
Very cool. Thanks for sharing. Btw, I got an SSL certificate error when I went to check out your site. I know there's a few different ways to account for this when serving up a website from github, but I'd welcome guidance on what the best practice is for fixing this.
I really like this, thank you for writing and sharing it!
I take notes and write personal documentation in Markdown for tickets and projects. Nowadays I usually write in Visual Studio Code or Vim. I can see myself using this to share pages with people. Although I wonder how my syntax highlighting will work - I guess I'll have to write a shell script to copy the .md file to .html and insert the call to the md-page.js at the top.
Markdown doesn't require tag closure, and eliminates the <p> tag entirely. This makes for a cleaner and faster composing experience.
I did little but wruite in HTML from the late 1990s to mid 2010s. Markdown is my preferred route now.
Also conversant in LaTeX, formerly; nroff, DocBook, WP4.2, Wordstar (both with 'reveal codes' capabilities), and probably more. Pandoc is a game-changer.
Well-formed HTML5 needs closure though, no? Hrm ... ok, looks like specs are far looser than I'd thought.
h[1-6], li, blockquote, pre, can all be specified via an opening-only syntax.
p, ul, ol, and dl can be omitted entirely.
Arguably anchors require closure, but the syntax is still briefer than HTML. Images likewise.
Header, footer, and aside don't exist (they can be supplied in a template). article, div, and span are also ignored.
Italic, bold, strikeout, code, subscript, and superscript require a lightweight closure, and are actually the main cause of grief in my Markup writing.
Tables are hugely more sane.
And footnotes automajickally exist. Swoon!
It's not that HTML is foreign or annoying to me. It's just .... more frictional.
And I have all kinds of nice words to say for HTML5. The base spec is quite good.
Is there a WYSIWYG simple editor for creating documents in HTML5? Something that's basically wordpad and produces pages that actually look the same on different browsers? Documentation for my projects is currently in raw ASCII because I couldn't find a satisfactory solution.
If you edit html inside a modern editor it colorizes the output in a useful way. You see the headings, and the basic formatting in a rather clear way. For simple html (as the one you would expect from markdown conversion) this is more than enough.
WYSIWYG editors are evil as they mostly produce crap code, good news are you don't need a WYSIWYG editor with markdown as it's very easy for [almost] everybody to write by hand.
The flicker when loading the page sucks. I guess displaying Markdown in case of failure is not the worst thing, but it would be nice if there was a possible way to allow getting rid of the flicker at the cost of not having a graceful fallback.
One way you could accomplish this is by supporting script tags for this, like wrapping the page in:
<script type="text/markdown">...</script>
...as an optional way to use the library. Browsers won't (shouldn't?) try to render the contents of the script tag before you get to it, so it would act like a typical SPA.
Yesss, finally a use-case for the `<noframes>`-hack! This is actually even better than the approach of OP since we're guaranteed to get a plain text representation of the text (instead of the browser parsing it as HTML).
example.html:
<script src="mdpage.js"></script><noframes>
# Header
Welcome to my simplest site
- A
- awesome
- list
mdpage.js:
document.write("<div id=main></div>");
document.addEventListener("DOMContentLoaded", function() {
var script = document.createElement('script');
script.src = "https://unpkg.com/showdown";
document.head.appendChild(script);
var noframes = document.querySelector('noframes');
script.onload = function() {
var converter = new showdown.Converter({
emoji: true,
underline: true,
})
converter.setFlavor('github')
main.innerHTML = converter.makeHtml(noframes.textContent)
};
});
Thanks @judofyr + @matt-tingen. I just updated it to use the 'noscript' opening tag. Good idea, and solved my normal html not working problem! Thanks a bunch!
I wonder what effect having a page solely in markdown has on SEO? Without markup for headers, links, etc, how will search engines prioritize content? Will they use the raw content or the parsed HTML?
Sure we can add JavaScript and make the web work the way we want, like this example, but many more... but what about SEO?
For example, I had a page for my app, it was very minimalistic and pretty, I targeted the 400 msec cold loading time, instead of a screenshot, I had a very well encoded h.265 screen recording (it's okay, people who can run the app, can certainly see the video), that video didn't cost more than a well optimized JPEG.
But I had to drop the video, and only load it after the JPEG loaded because of SEO reasons. Google isn't smart enough to recognize the video unless it's a YouTube video.
It looks like you wrote a script.js file, which calls showdown.js library (converting markdown to html). A uglified version called `md-page` is made pulling both resources
Basically, the script does following
1) wait for page to load
2) add css-styles via javascript
3) shove all the markdown in a variable "markdown", passing it as one giant string
4) Add settings for showdown.js
5) Rewrite entire markdown on page to HTML via showdown.js
6) Append to body and render
I could fork it and add breakpoints / run debugger but this is what I got from looking at source code
I wrote a web server that converts markdown to HTML dynamically. Not sure if it's what you're looking for but it works decently well. I host my personal site on it.
the mechanism for using both the projects is the same -- include a JS file. If the effort to use both is the same, why would I not use the one that has more features?
I've thought before that it would be neat to have the ability to specify an alternative markup inside any element. A kind of:
<div markup="markdown">Browser now _interprets_ content as markdown until end of div.</div>
It would make user-submitted content so much better since you could just directly embed bbcode, markdown, etc. without needing to parse it to html or validate that their submission is valid html/only using approved tags, etc.
I really wish they would. With just a small number of elements added to the Markdown standard (e.g. for plots, videos and audios and, perhaps, a standard way include referenced files in the markdown file itself) this would make the web (and e-mail!) I want.
Along similar lines, I went back to LibreOffice recently and made a few web pages with it, just to try it out. It worked better than I expected.
After adding a simple PHP controller to the mix, injecting some CSS for responsiveness and other tags as needed, I have been impressed with how easy it makes publishing. If a single-pager is what's needed (or multi-pagers perhaps; I just haven't tried it yet), if what matters most is getting links and information public, it's a useful tool.