I do love the simplicity of write.as and the markdown support. However, I find markdown support a little bit inconsistent and limited.
There are some inconsistencies in hos write.as interprets newlines in markdown, as can be seen in my markdown test post. Write.as treats both literal newlines and double spaces at end of line as newlines.
There are no support for description lists, nor footnotes. I have seen mentions of this on the forum that this belongs to extended markdown, but there are different flavours of “extended markdown”, for example:
Pandoc’s Markdown (my preferred choice),
Github Flavoured Markdown,
CommonMark.
There are differences between them so when (if?) implementing “extended markdown” I guess a choice has to be made as to avoid a “Write.As Flavoured Markdown”.
I agree we should try to make things as consistent as possible. Our specific flavor of Markdown is meant to strike a balance between plain text and rich formatting via basic Markdown syntax, which is why things are this way (respecting whitespace and literal newlines, etc.). Overall, we want to be as intuitive as possible for the average user, and be flexible enough for more creative writing, like poetry.
We’re thinking about how we might support a Markdown standard in addition to our current middle-of-the-road support now. This forum thread would be a great place for everyone to weigh in on what they’d like to see most.
Currently, markdown tables have no border lines in write.as. I’d like to see a thin (e.g., 1 px) border. Borders could be added through custom CSS, but shouldn’t borders be the default? What is the use case for borders without lines?
Another tables feature that might be nice is to lightly gray-scale shade alternate lines.
I’ll probably think of a few other things later on, but offhand this one seems most significant to me.
@bugbuster Sorry I didn’t reply earlier – I think we could definitely add a border to tables by default. There isn’t really a case for doing otherwise.
On another note, just wanted to link GitHub issue #193 which brings up the problem of unexpected Markdown rendering.
As I mentioned there (and previously discussed in this fediverse thread), I’m thinking we could potentially support multiple Markdown standards, and let the WriteFreely instance admin configure which one they want to use.
Another option would be to let users pick this at the blog-level. But that risks making the platform more complicated for the everyday user, who may or may not be affected by this.
Those are just my current thoughts; I’m open to any other input you might have.
@Matt I think the optional idea of supporting multiple Markdown standards, giving the admin or individual user the option of which to choose, has merit if it does not require major development effort. With setting a default, the everyday user wouldn’t be impacted, the choice of Markdown could be in an Advanced configuration section with a warning message about not changing any advanced option unless user is fully aware of the consequences.
If offering a choice requires much development effort to implement, I would see it as a low priority (or even a no-go) since I’m not sure what percentage of users really want a markdown flavor choice. The main priority is to offer a fuller set of Markdown capabilities than currently exist, e.g., table borders being a prime example. I’d be happy with having more extended Markdown syntax without necessarily having optional choices
The use of markdown is a key feature of the platform.
I am happy for one flavour of extended markdown to be decided that has the majority of features - lists, footnotes, tables, etc. Users will adapt - following the documentation of the canonical flavour.
I’ve been exploring different Markdown variations recently and had a thought on this very vein.
Would you consider publishing WriteFreely’s default combination of Markdown support as a new Markdown Syntax? (How about WriteDown? lol)
It doesn’t seem to require all that much documentation - just a spec sheet, which I think (could be wrong) would function as a solution to what we’re talking about here.
I know personally I would much rather work around your implementation than try to modify WriteFreely myself - I just need to see that spec sheet.
Could you give the option to WriteFreely instance owners on what markdown flavor to use? I’m running a blog and would like to make use of AcademicMarkdown.
This’d still preserve the experience for Write.as users while giving others flexibility.
I’m open to documenting it in the future! I’m just not sure if it makes sense right now, while there are still issues we need to fix (e.g. accessibility-wise) with our current system. But I think we’ll eventually settle on something stable, and then I think it’d make sense to formalize what we have.
I think this is a great idea! All it would really take is for us to drop in other Markdown-to-HTML renderers, maybe extend the CSS a bit, and then add a configuration option. I’m not sure if there are AcademicMarkdown rendering libraries for Go, but if anyone wants to take up this work, we’d be happy to test and merge it into WriteFreely.
FWIW… as its Markdown parser, Hugo switched from BlackFriday (all but dead) to github.com/yuin/goldmark . It is actively developed, and targets CommonMark (currently 0.30). Another good feature is that it creates an AST.
Just noting for those interested in this topic: I took a stab at implementing some initial Goldmark CommonMark/GFM support for WriteFreely as a configurable option, and submitted a PR.
I’ve used Goldmark at work and extended it with new syntax, and it’s pretty easy to do. It would open up a lot of possibilities for adding WriteFreely-specific Markdown syntax extensions.
