Continuation of the previous topic:
I found what was the bug and highlighted it.
The html tag hr was found on note pages.
It stood for many pages (above the list and the head of the list).
Now the mistake can be repeated.
The steps are the same, just rename the file.
<hr> is unclosed in your notes. Does the issue persist if you close it: <hr />?
In HTML, the hr tag does not have an end tag.
The closing tag doesnāt work here.
The Obsidian command āāā works like hr. Here I do not use it only because it spoils the size of the top line. I need to do extra line breaks.
Replacing it with an html block wonāt work either.
Your screenshots are quite tough to follow. Just post your raw text examples wrapped in ```
You need a blank line after HTML blocks, else the processor does not pick up the following lines as markdown.
Fine. The div tag has zero height. If you insert it before the hr tagā¦ No, both lines are combined into one common html code.
I will consider that it is impossible to do this, that this is a feature of Obsidian.
Thank you. Close the topic.
Itās just that your continuous lines are recognized as one block.
Add a blank line after your hr or div tags and itāll work.
Extra blank lines interfere.
Especially if itās almost at the very top of the page.
There is some strangeness occurring, adding whitespace does fix to some extent, but here is an example of the strangeness:
[[2019-02-26]]
----
[[2019-02-26]]
[[2019-02-26]]
<span><hr /></span>
[[2019-02-26]]
[[2019-02-26]]
<hr />
[[2019-02-26]]
[[2019-02-26]]
[[2019-02-26]]
Which in 1.1.9, displays in reading view as:
So the --- causes the previous line to be considered a heading, as per markdown syntax.
The <span><hr /></span> does produce the line (and some extra space), and is a closed html structure, so that the next line is shown as a proper link. (The same doesnāt happen with <hr></hr>, which is wrong html, but could possibly have worked)
Even the self-closing <hr /> doesnāt work in reading view, as it then triggers the strangeness of causing the next few lines to be treated as something elseā¦
Iām not sure youād want to call that a bug or a feature, but there is also a difference in reading view vs live preview on the above example, where the links are all showing in live preview, but then <hr /> doesnāt work, and it does a better job with <hr>.
So strangeness occurs, but Iām not sure how to classify this. When doing the actual renaming of 2019-02-26, it doesnāt rename the last three versions, as theyāre clearly not considered links, but rather some simple text (of sorts).
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.