Ability To Prevent DOM Element Removal In Active Note, Nav Tree, etc

[Graywaren]

Use case or problem

Custom css that relies on nth child/of type etc. doesn’t work correctly due to obsidian removing elements from the dom when they go off screen from scrolling, whether or not they’re still in the active note or nav tree, making it impossible to iterate through the entire nav tree/section/note and have a specific element consistently stay the name nth number.

I spent a while setting up my nav tree folders to have iterative rainbow colors, but to my dismay my folders change colors, which was extremely confusing and disruptive, as I expand and scroll and the elements not currently showing get removed. I’ve previously tried to have headers in a file have styles that were based on nth child as well, and it was impossible to achieve for the same reason.

Proposed solution

I would really appreciate at least a toggle to disable the removal of these elements from the nav tree entirely, the currently active note being viewed, etc. or something else, some sort of numbered hook, that would allow for iterative styling and any other custom css requiring the use of nth over a long enough area that it’s scrolled to remain consistent for all elements in it, not just the ones that are currently on screen.

[Graywaren]

Other Similar Feature Requests:

Prevent Removing Elements with position: sticky or position: fixed from the DOM

Use case or problem I have a note that includes a dataview query, which embeds all notes from a specific folder and displays them as a set of cards. This results in a very lengthy note. Since each card-note is color-coded, I created a color legend using a callout. I set this legend to always remain visible in the corner of the screen using the CSS property position: fixed;. However, here’s the issue: After scrolling down, the legend-callout is removed from the DOM. As explained in this forum th…

[untitled]

I support this request.

I had a need to make table column headers dynamically attached at the top when scrolling, but it didn’t work. If it wasn’t for holroy’s reply (below), I wouldn’t have realized what was wrong.

1rst row of tables always visible when scrolling?

I’m not sure this is the case for you, but I do know that Obsidian is actively only loading parts of longer documents related to what is visible or not. This mean that if you table header is a portion of your document Obsidian believes is not visible, it’s removed from memory. This also means that it can as sticky as it likes, but if it’s not loaded it’ll not show. One possible workaround could possibly be to insert your table headers into the table every now and then. How is you table defined?…

In my case, compatibility of unloading of non-visible file elements from memory with CSS’s position: sticky will be enough.

related plugin request: Plugin which permanently renders div elements even if outside the viewport

---

Addition:

I’m not sure if this is the reason, but it seems that the ability to use the:

… {
  visibility: hidden;
}

…:hover {
  visibility: visible;
}

… is also impossible because of this feature of Obsidian’s work.

As a workaround, I have to use opacity instead of visibility.

---

One more addition:

It seems that this feature of Obsidian’s behavior also prevents CSS created for a specific combination of selectors from working correctly:

.selector00 + .selector01 + .selector02 {
	...;
}

… because as soon as one of the selectors leaves the viewport while scrolling the file, it is unloaded from memory, and what was .selector00 + .selector01 + .selector02 now becomes simply, for example, .selector01 + .selector02, and thus the CSS created no longer has any effect on the remaining .selector01 + .selector02 in the viewport.

[ob_user]

I think this is useful and should remain users in an obvious places.

[Graywaren]

More reasons not having any control of this causes issues and has been a constant battle of buggy behavior. Please give us any ability to control this.

• Long code blocks that render an object, such as Dataview etc. no longer work until you’ve scrolled far enough up or down the page for it to render the first/last lines and then it suddenly pops into rendering. This doesn’t happen with long callouts that I’ve been able to tell, so I don’t understand why it happens with plugin blocks.

• The DOM removal seems like it’s based on source view and not live preview so plug in blocks that should be visible on screen in the editor in live preview when they’ve rendered are removed from the DOM leaving large gaps of blank space at the top or bottom, especially if using css for any layout manipulation. I’d report as a bug in an instant if I could, I might try to replicate it with plain html. It’s pretty awful to have a couple of pixels of scroll mean I can’t see half my page and have chunks popping in and out of existence and therefore can never smoothly scroll down the page with everything rendering properly

• Can’t have something like js-engine run a small bit of javascript at the top or bottom of the note that should affect the whole page because as soon as it is removed from the DOM it stops working and doesn’t start working when it’s re-added because the note wasn’t re-loaded. I used to have javascript to make certain html elements with horizontal scrollbars scroll horizontally automatically without the use of the shift key, but that’s no longer possible.

• Can’t have meta bind (or other plugins with similar features) hidden buttons to enable an inline button at the top/bottom of the note or anywhere that isn’t within a paragraph or so of the inline button because if it’s removed your button no longer works… this leads to much easier accidental deletion of the button

• Other various things relating to whether something happens on load and so doesn’t happen if something is deferred or listens for major dom changes therefore running more frequently… Also, I can’t be sure, but it sure seems that the DOM removal causes more lag in my vault than it attempts to prevent from how often it causes things to need to be rerendered, have css reapplied, etc.

When users have to rely on plugins for many basic features, especially for accessibility, like keyboard navigation or file coloring in the navigation pane, it’s really aggravating to have a feature added that makes those things even more difficult. Desperately need a length before removal setting, removal overrides for certain areas/css settings, maybe an ignore plugins only do it for plain text or something… Even a similar “this may affect performance if turned off” off switch like is offered for hardware acceleration would be nice.