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.
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.
But then the same formatting on the write.as blogs should extend to the RSS feeds as well. Because right now poems written on write.as only appear fine on the blog but not in the feeds.
Wow, didn’t know that. In that case, I’d much prefer if write.as just used standard Markdown, which when using the Rich/Classic Editor adds a WYSIWYG line break. If we’re talking about average users at large, then they’re much more likely to use the Classic Editor than even know Markdown.
I am in favor of this approach also: giving the user an option, if the development is not severely hampered. The current default Markdown is limited with respect to offering “extras”. Personally, I like to use footnotes in some of my posts and while there is a way that exist to do so, if it is built into the Markdown backend/language, it would be a much easier and nicer approach to users.
I updated my PR to make it configurable which CommonMark extensions are enabled – e.g. GFM, typography smartening, etc. It wouldn’t be too hard to move the option selection to be a per-user thing, though I’m not totally convinced that would be a good idea.
There are a ton of add-ons that could be made available as options if Goldmark was made available as an option — syntax highlighting, LaTeX rendering, diagrams, and so on. I didn’t add any of them yet because (a) I didn’t want to bloat the dependencies too much and (b) I didn’t want to put in a lot more time if the PR might not get accepted. My concern was wanting standard Markdown support via a parser project that hasn’t ceased development and maintenance. I figured add-ons could come later.
I’m actually wondering what the current Blackfriday implementation does that’s non-standard but considered desirable, other than turning linebreaks into <br>. Goldmark could also be configured to treat linebreaks that way as an option, in which case, why not replace Blackfriday entirely?
WriteFreely’s flavour of markdown is different enough from what I’m used to that it’s slowing me down a lot. (specific example: for the life of me I can’t get paragraph code formatting to work, inline is fine.)
@meta’s pr is closed and the head repo deleted. Was that because of lack of upstream interest or did development move somewhere else? Is there some other way to use different markdown parsers?
