[semi] protect system pages (about, help)

[cben]

http://mathdown.net/?doc=help now shows random content someone put there.
Should recover old content, and find way to make it read-only (or ideally read-write but somehow moderated?). The obvious way is store it in a file and adding a "view file" (or better view any url) mode.

[cben]

While at it, it'd be nice for Help to appear in side pane.

[cben]

Of course, I also need to protect the front page (?doc=about) at some point.
There everybody wants to edit ("sandbox" mode), so I was thinking of allowing local edits with a banner warning that they're not saved on this page.
But then people won't see other's experiments, which is half the fun of a sandbox.
Perhaps it's best to have a dedicated front page with some read-only content + an embedded part-page shared sandbox + strong call to action to create a new doc.

[cben]

• make clearer that what people write in the sandbox is public

[cben]

Turns out "view any URL" is hard because of cross-origin security.
StackEdit pulled it off by running a proxy on Heroku.

Even rendering help.md from current directory seems problematic on file:// scheme.
I could stuff the fixed help in JS (or data: but that really begs for a build step).
Or I could stuff it in help.html or help/index.html!
Code duplication with index.html will be annoying — all these options are really asking for a build step.
Or I could live with requiring a local server...

[cben]

Yes, digging some more into file:// XHR or iframes shows that even if it would ever work, it'll be a can of cross-browser worms.
I could probably strip down the html boilerplate to

<script src="view.js">
# Regular markdown from here...

It's tempting to just call such files foo.md for better viewing/editing in github (and everywhere else),
but I suspect that would mess up Conent-Type headers (e.g. from GH Pages).

=> Going with requiring a local server (with some kind of fallback for file:// to at least explain why Help didn't work).