Closed zoli closed 4 months ago
Can't believe how awesome you are for getting this to work :sunglasses: It seems to work perfectly. I'm merging it and adding the rules for Reading View.
I figured I commented earlier on the issue rather than in the PR. Better to have the follow-up discussion here I guess.
What do you think about this alternative approach, that instead of keeping the table wrapper LTR in an RTL table, adjust the direction of LTR cells? This leads to the following rules:
/* If table first header is RTL render table on the right side of page but dont make every cell RTL */
.cm-table-widget:has(thead tr:first-of-type th:first-of-type .table-cell-wrapper.esm-rtl),
.cm-table-widget:has(thead tr:first-of-type th:first-of-type .table-cell-wrapper .cm-line[dir="rtl"]) {
direction: rtl;
}
.cm-table-widget .table-cell-wrapper.esm-ltr {
direction: ltr;
}
(I replaced the 2nd rule)
I seem to get this way a more consistent result in several aspects:
So I pushed the above to master, plus Reading Mode rules, and a nice tweak that moves the "add column" Obsidian control to the left. If you have the time, I'd love another set of eyes giving it a test run :pray:
Your solution is better. Tested on the latest commit and everything seems OK. Thanks.
Fixes
Note that the last problem was due to my presupposition that the cell is not editable in post-processing (reading view) and direction would not change. But obsidian renders the table as we are in reading view so every time the table cell changes the reading view of the table updates and we have to check directions.
What it doesn't fix :(
related to #70