I’m using Obsidian to write dairy, and today when I’m trying to create a folded part (<details>), I came across the problem where
Markdown syntax isn’t being properly parsed & previewed; and
Direct empty lines put everything below that line outside the <details>, even if </details> is after that.
This empty line problem also exists in a lot of other tags, such as <font>, <center>, etc.
I’ve also tried the same text on a lot of other markdown editors (randomly grabbe, all of these worked exactly as expected.
Proposed solution
After asking around in the official Discord server, I was told that it could be a parser problem, that a part of the parser is missing. (Correct me if I’m wrong here!) So the thing is, it would be pretty awesome if we can have these features back in the preview mode.
Current workaround (optional)
HTML tags still work inside these tags; still works for an empty line, but these kinda hurt the readability of the raw .md file.
Also, the empty line problem is also gone when included in a <pre> tag.
I’d add that it would be neat to have markdown be parsed on some other tags for which we don’t have a markdown equivalent and where we might be interested in using links to notes. Off the top of my head: <aside>, <caption> and <mark>.
There’s a post in an old Commonmark thread which described this type of use as “too programmish”.
I think I’d agree with that. Obsidian already has something of a reputation as a note taking app for programmers. Many new users already struggle with markdown and with switching between edit and preview modes - hopefully WYSIWG will help with that.
There’s a fine line between programmers/non-programmers to be chosen in the way the program adds features. Programmer friendly has facilitated all the extensions. At the same time, it has put off an unknown (unknown because they peek and go another way) number of non-programmers looking for PKM note-taking.
Another factor is the unpredictable changes that come and go in the irregular episodes of HTML sanitization. For lifelong plaintext stability, the less HTML in notes the better.
How does me choosing to use html in my notes (<cite> is very important to me) hurt other people who don’t? I don’t see how this change would hurt non programmers at all.
The non-programmer looks at complexity they don’t understand and makes a decision about engaging or not. You will have picked up on posts on discord or here that essentially come from this perspective. People scanning the discord or forum already see a preponderance of posts relating to programming details. That wasn’t the case in the early days. It seems to me that the intense enthusiasm from programmers and those interested in tech has shifted the Obsidian centre of gravity in that direction. Early Roam users all pointed to its intuitive ease of use (more recently tarnished by lack of development and not working very well); Obsidian never quite hit that ease, but it was within reach. Not as apparent now as complexity has risen exponentially. The community may be friendly and supportive but it is very tech. Potential new users will look at it and decide if it feels right for them. Maybe WYSIWYG will save the day, maybe it’s already too late.
Essentially many of these things are feature and design choices. But those choices have consequences, usually minor, sometimes major and generally cumulative.
None of it affects me personally. I can switch into HTML if I choose to. 90% of my Obsidian usage already disappeared when I realised that txt would never have parity (most markdown editors switch quite happily). But I think it would be sad to see Obsidian retreat into a silo when it could have been so much more. Just as I think it is sad to see the problems in Roam despite never using it and believing its design choices wrong. Though that would just leave the market open for a different approach.
And yet, using HTML tags is considered basic markdown syntax. HTML is structure, not programming.
What attracts me to Obsidian is the freedom within it. It is, at best, presumptive to declare that adding optional features that allow more freedom of expression will somehow limit Obsidian’s usefulness to those trying to express themselves.
Markdown has grown in popularity from its inception. As sites and applications expand their markdown implementations to allow more and more useful HTML has brought the increase of Markdown’s popularity rather than relegate it to a silo.
I’m going to clarify that I’m not advocating for full HTML support. I limited my request to the few tags that (in my opinion) make sense to use when writing complex notes.
How this is implemented is up to the devs! As you said it can be taken care of by the wysiwyg mode or hidden away under a toggle to avoid scaring those that don’t want/need this features. One of the many things I love about obsidian is its flexibility, and that it becomes a personal choice how much complexity you’re willing to handle.
Many Markdown applications allow you to use HTML tags in Markdown-formatted text. This is helpful if you prefer certain HTML tags to Markdown syntax.
For security reasons, not all Markdown applications support HTML in Markdown documents. When in doubt, check your Markdown application’s documentation. Some applications support only a subset of HTML tags.
HTML, tags or other, is not markdown. Just as YAML isn’t markdown.
My bigger point is about the accessibility of Obsidian. The discussion on the Discord started talking about tags, when to most non-programmers tags in Obsidian start with a #. Much of the discussion on the Discord might as well be in Martian from their point of view. (Not quite the same issue on the forum where most will use threads and search.) I suggest that it might be useful to some non-programmers, they have a look and say no, not for me. Simple markdown is a big step for them, PKM difficult (but they have the need). For all its faults, Roam seemed approachable: just sit down and start writing. The public windows for Obsidian are the Discord, the Forum and the Help files. Only users look at the help files - and many don’t. The more HTML is added, the more discussion there will be about HTML; it’s a discussion about the technology, not the use. Discussions about technology proliferate, because that’s the actual user group now and they talk the language they share. Which is a pity becaue most people with a use for PKM notes aren’t techies at all.
Keeping users like me (I’m won’t dispute that I’m more technical than the average bear, but I’m not a professional developer by any stretch of the imagination, I stay well away from the truly advanced stuff ilke Templater and Dataview and MetaEdit) from using <cite> and <aside> which are at least human readable and not much more complex than _ or * or ## because discussion about complex topics like bash scripts and javascript and and cron jobs are off-putting to non-techies seems a bit like closing the barn door after the horses have escaped, but I’ll leave the discussion here for the devs to decide on
I fear you may be right.
I’d hope a closer analogy would be with gut bacteria and food. Eating the wrong food for long enough (ie typical western diet) creates an unhealthy bacterial community with consequences for health long term. But changing diet can help to shift towards a healthier balance. Though even with that there’s a point of no return.
I hadn’t noticed it happening; it crept up slowly. I understand the tech stuff and I discounted the occasional commentors on discord. But momentum accelerated, I can see the non-tech point of view and, as a business owner, I’d be concerned to look attractive to the very large departing market again.
An example of an app that does this perfectly is Jotterpad. I’ve used # heading syntax inside <center> tags, so it’s certainly NOT impossible and you have no excuse to not implement this
The whole issue is this. Obsidian is a PLAIN TEXT application that USES Markdown to format the PLAIN TEXT. The developers use the Markdown syntaxes, they do not control them. If you want to change the standard Markdown, talk to the people who publish the Markdown standards, the group that published the HTML Standard, and the CSS Standard.
Hello, as i was looking around the forum for see if the question about the contents proper visualization was already been asked i stumbled across this topic, after reading all i feel like to express my point of view.
I will never really get this kind of philosophy.
Trying to paraphrase: ‘This feature should not be added, as this optional thing add more complexity, and then people will talk about it, it is too complex for newcomers who looks for something intuitive and easy to use and it goes out of the early scope of Obsidian’
Writing html and viewing it in live preview is already supported, making it work correctly will bring Obsidian to destruction?
Is it really that bad to shift and expand the scope of Obsidian?
What stuns me is that we are talking about something that is partially already in the program and that will remain always optional to use, what’s the point of moving against something like that?
There are no short-term plans to support parsing markdown within html blocks. This isn’t part of the commonmark spec that we follow nor it is handled by the parser we use (most parsers don’t handle this actually).
The specific use case in this thread can be handled with folded callouts.
As I understand it, this is part of the CommonMark Spec, under HTML blocks (e.g. Example 148 demonstrates how parts within a table are processed as Markdown). Moreover, VS Code’s parser handles this correctly. On the other hand, Obsidian’s callouts are neither part of the CommonMark Spec nor recognized by VS Code’s parser. So I’d much rather be able to use the details/summary syntax than having to rely on foldable callouts. Thanks in advance for reconsidering this.
Let me be more specific. The markdown spec defines different types of HTML blocks. Some are fully contained, where the html logically begins and ends in the same block (a block is separated by others by empty lines) and some that are allowed to begin, have other blocks in between, and then end.
In the html part, the markdown is not parsed.
The markdown blocks in between the html blocks should be parsed, however we have intentionally decided not to do it as an optimization to handle very large documents. This was an explicit deviation made on our end and we are gonna to stick to it.
Specifically:
This should not work and it doesn’t.
