SYSTEM INFO:
Obsidian version: v1.6.7
Installer version: v1.6.5
Operating system: Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 23.5.0
Login status: logged in
Catalyst license: none
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none
I think he means bold has inconsistent visual appearance when you begin typing bolded text in source mode or live preview. I’m not sure if I agree this bug report because Test **** and - **** has similar visual appearance. Or should we include also Test **** to this bug report so they should fix it? What you think about this @harr ?
We could also inspect how typing **** or ⌘B looks like in table cells, external links and callouts. The visual appearance is inconsistent.
a) When we are not typing, four asterisks represent a <hr>. So formatting them in a bold font doesn’t make sense.
b) When we are typing, it becomes more complex.
When the cursor is positioned in the middle of the four asterisks (**|**), it marks the location of a potential text. Text surrounded by two asterisks on each side is rendered bold (<b>**|**</b>). So it would make sense to format the asterisks bold in that situation.
I’d apply the same logic to other cursor positions. How would Markdown be rendered, if there was actual text at the cursor position?
When the cursor moves one character to the right (***|*) it should be rendered as (**<i>*|*</i>).
When the cursor moves one more character the right (****|) the asterisk should not be formatted at all in Source Mode (****|), because four asterisks followed by any text wouldn’t be formatted either as bold or italic.
Live Preview is more complex. I don’t know if four asterisks followed by other characters are valid Markdown and how it would be rendered. If it is not valid Markdown, I’d expect to see only asterisks without any formatting.
Depending on the cursor position, we’re dealing with <i>, <b>, <hr> or invalid Markdown.
I think that Obsidian’s user interface should support users in writing standard compliant Markdown. So I’d like to see precise visual feedback.
I think this is not so straightforward if we are talking about what you see in source mode. Horizontal rule <hr> is mostly used in empty lines so we could apply no bold/italics only in this instance. Obviously this negatively affects the writing experience where user begins paragraphs with bolded text so we could format four asterisks consistently as bold in every possible situation in source mode.
Users who begin a line by pressing Cmd+B are editing the text, see b).
But when the cursor leaves that line, a sequence of four asterisks defines an <hr> according to the previously mentioned specs.
In the previously posted screenshot you can compare how Obsidian currently renders four asterisks within and without a list:
Outside a list (****) Obsidian handles those four asterisks just fine.
But inside a list (- ****) the rendering in Source Mode and Live Preview doeen’t make sense.
Live Preview is obviously not spec compliant, because the line is empty, where a horizontal line should appear (hence a bug).
Source Mode is inconsistent. I find the behavior in case 1. more intuitive.
Should the four asterisks be rendered bold, after pressing Cmb+B? I have no preference:
Yes, because by pressing this key the user explicitly asked for bold formatting for the text that is about to be written at the cursor postion.
No, because unless there is actual text at the cursor position, the sequence of four asterisks does not represent <b> but <hr>.
My preferred solution is that the editor behaves the same for (****) and (- ****), just as yen_le’s bug report suggests.
While making the following screen recording, I found another bug. Live Preview renders ****e as if it were ***<strong>*e</strong>. Source mode renders it also as if it were <strong>. This is unexpected, because in Markdown <strong> like <b> requires a text to be wrapped by double *'s. (See CommonMark Spec Section 6.2.)
Screen recording shows Source, Live, Reading view. I’m editing in Live. The same character sequence is created first by starting with CMD+B then by sequentially typing it.
Technically speaking, Obsidian uses <span> tags with the class cm-strong in Source Mode and Live Preview. Something is odd with the code that creates those spans in the way it groups the four asterisk. Why make two spans, one with three asterisks and one with one? (See also screenshot in original post.)
