Typing html tags into table breaks the table at the </

Steps to reproduce

Create table like this:


|             |     |     |
| ----------- | --- | --- |
| Hello world |     |     |
|             |     |     |

Then start writing a tag like: <kbd></kbd>

You have to write a non-last row. Last row doesn’t break formatting, others do.

Also take notice, if you copy-paste the tag, it does not break the table. But if you write manually, the table breaks.

Did you follow the troubleshooting guide? [Y/N]

Yes, I did also try it in sandbox vault (thankfully it’s very easy to open sandbox).

Expected result

I did expect to write <kbd></kbd> without errors. Or use any tags, to be honest.

Particularly, I want kbd tag to have some chips element as «tag-like» component inside the table. To display some data in a prettier way.

Actual result

You can see on gif:
gif

Environment

Obsidian version: v1.8.9
Installer version: v1.8.4
Operating system: Windows 10 Pro 10.0.19045

The workaround I’ve found is to type <kbd><kbd> and add in the / last. You can recover the table with Ctrl+Z, sometimes you need to use it multiple times.

The same also happens typing in <></ and text in the first tag. It doesn’t happen when typing <></> and then filling the first tag. Anything in the second tag has no effect it seems.

This also happens typing <a</ and adding the > after a. It doesn’t happen if the closing tag is complete.

This sometimes happens typing a></ and then completing with the < at the front. It didn’t seem to happen in the header row (also containing some of these tests…), but it happened in rows below.

Overall it seems to rely on the closing tag </ lacking a closing angle bracket, and then forming an opening tag or there being an opening tag and forming the </ of a closing tag. Contents of the closing tag other than the ending > have no effect.

Yeah I can recover with Ctrl+Z that’s not the problem. Workaround is fine but doesn’t help me much, because by simply plaicing a tag with Ctrl+V the table still breaks. I use other software like AutoHotkey to place the tag whenever I need it, which works quite similarly to Ctrl+V and it also breaks the table. So I have to manually edit it every single time with this workaround or simply forget about tags inside a table. Currently I prefer the last, otherwise it’s just too much hassle otherwise. But ideally I would like if tags didn’t break the table, then I could use them conveniently. Thanks for feedback maybe it will be useful for someone fixing it.

Steps to reproduce

  1. insert a table in live preview (command Insert table)
  2. navigate to a header cell
  3. paste this text: <ol><li>test</

Did you follow the troubleshooting guide? [Y/N] yes

Expected result

Text <ol><li>test</ should appear inside the header cell so that html lists could be written manually i.e.

<ol><li>Coffee</li><li>Tea</li><li>Milk</li></ol>

The above code works inside header cells if directly copied and pasted. Also non-header cells doesn’t cause the issue.

Actual result

The original table becomes unrecognised in live preview

Environment

SYSTEM INFO:
Obsidian version: v1.6.5
Installer version: v1.6.5
Operating system: Darwin Kernel Version 23.5.0: Wed May 1 20:19:05 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T8112 23.5.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 0
Plugins enabled: 0

RECOMMENDATIONS:
none


Additional information

I use the CSS code below to disable emphasis in header row so that in my Obsidian markdown tables don’t have headers by default. However my issue is not only restricted to writing html lists inside table headers: for example typing <u>test</u produces the issue as well.

/* table header weigth in reading mode */
.markdown-preview-view {
  --table-header-weight: normal; /* bold/normal */
}

/* table header weigth in live preview */
.markdown-source-view {
  --table-header-weight: normal; /* bold/normal */
}

thanks for the report.

will be fixed v1.9. No ETAs.