DOM cleaning in long sessions: JS unset a lot of CSS? JS remove() "Browsers are smart enough"

[ImprovedTube]

We could inject our CSS only at need and unset a lot of Youtube's CSS.
But would that really help as long as the sessions aren't 100 hours long?
And we have many display:none features (CSS) for example. So we could also remove* some elements with JS(, which might helped if the page actually ran for very long... (#1211 #1967) )

Can/does uBlock do any of this? @gorhill @Deathamns @chrisaljoudi -

---

*(Which could be undone at times, when saving a reference to the element's parent or neighbors )

//remove: 
var X = document.getElementById('xyz');
var parentOfX = elementToRemove.parentNode;
var indexOfX= Array.prototype.indexOf.call(parentOfX.children, X);
var prevSiblingOfX = elementToRemove.previousSibling;
var nextSiblingOfX = elementToRemove.nextSibling;
parentOfX.appendChild(xyz);
X.remove();

//add again:
	if (prevSiblingOfX) {  parentOfX.insertAfter(X, prevSiblingOfX);
} else if (nextSibling) { parentOfX.insertBefore(X, nextSiblingOfX);
} else if (indexOfX) parentOfX.insertBefore(X, parentOfX.children[indexOfX]);
} else if (parentOfX) { parentOfX.appendChild(X);
} 

)

[ImprovedTube]

thank you @raingart! (and hope you like my edit)

---

...not?😅 @raingart
may i quote then?

different features lead to different end result

CSS:

css is simpler and less resource-intensive.
& runs always & some feature might
requires constant monitoring. Also the advantage is that, for example, you need to remove one single element and not
everything with #xyz. document.getElementById() does not return an array of html elements.

js deletion can also remove data that is bound to this element, which could theoretically harm other scripts

css allows you to return the element's display state back.

js used to make complex constructions before the advent of the :is and ':has' selectors. But chromium-likes support this feature since v105. But checking variables in an element is completely unavailable

vs. JS:

js remove allows you to monitor and notify that an element is found and then, for example, run a callback function. This is not possible with css.

---

---

Browsers are smart enough

The question display:none or hide() VS. remove() (#2193) is relevant, be it for performance in some cases (or just for re-assurance in other cases. Hidden objects in the DOM might consume equal resources as visible ones. So that we could optimize our many display:none-features (and several others too like unhook; code)

• just by how much?

Browsers are smart enough

Got a source? Else we could experiment / benchmark (comparing CPU & GPU over a long time):

• Have a video with blur effect removed vs hidden.
• Remove() vs hide all or most other ~6000 DOM elements besides the player.

( #1211; w3c/webextensions#506 )

---

---

Why do anything that is already in the player itself? Well, you can influence convas or imitate an api call, but why such crutches to do something that already exists

Just an example. Sorry. (Besides it is always good if we have multiple/all parallel solution in store, to fail-over once any changes)

overwrite css:blur

👍

Basic designs

document.body.querySelectorAll('a#thumbnail[href*="shorts/"]')
.forEach(el => el.closest('thumbsSelectorsList')?.remove());
basic functions for operation
https://developer.mozilla.org/en-US/docs/Web/API/Element/closest

https://developer.mozilla.org/en-US/docs/Web/CSS/:has

https://developer.mozilla.org/en-US/docs/Web/CSS/:is

---

How Ambient working
https://jsfiddle.net/up9b1qma/67/

thanks! the jsfiddle makes an ambient lightening test-case!

---

all file
https://github.com/code-charity/youtube/blob/9c4e5f66e44bbe14cef4d59ce6f5cb1ae5e9d4fc/js%26css/web->accessible/mutations.js

it might be better to replace all

document.addEventListener('play', ()=> document.dispatchEvent(new CustomEvent('it-play')), true);
because HTMLMediaElement.prototype.play is executed before the player plays. addEventListener has a parametercapture which allows you to execute the code in priority.

modification of the standard HTMLMediaElement.prototype is not recommended due to all sorts of pitfalls

thanks for caring!
what are side-effects?

( Also:

youtube/js&css/web-accessible/core.js

Lines 71 to 75 in 0a7acbe

	/*--------------------------------------------------------------
	CODEC || 30FPS
	----------------------------------------------------------------
	Do not move, needs to be on top of first injected content
	file to patch HTMLMediaElement before YT player uses it.

by @raszpl )

---

---

why is complex if used?

why not replace everything with switch-case?

youtube/js&css/web-accessible/functions.js

Line 6 in 9c4e5f6

if (node.nodeName === 'SCRIPT' || node.nodeName === 'iron-iconset-svg' || node.nodeName === 'svg' || node.nodeName === 'SPAN' || node.nodeName === '#text' || node.nodeName === '#comment' || node.nodeName === 'yt-icon-shape' || node.nodeName === 'DOM-IF' || node.nodeName === 'DOM-REPEAT') {

We can. (even if IF is faster than the DOM)

It’s better to replace the loop with for-of or foreach and remove the check. And why is it just checking children instead of children.length

youtube/js&css/web-accessible/functions.js

Lines 12 to 13 in 9c4e5f6

	if (children) {
	for (var i = 0, l = children.length; i < l; i++) {

why .5 String?

youtube/js&css/web-accessible/functions.js

Line 586 in 9c4e5f6

button.style.opacity = options.opacity || '.5';

Why check window.matchMedia which has been supported for 15 years by all browsers

youtube/js&css/web-accessible/init.js

Line 111 in 9c4e5f6

if (window.matchMedia) {

does it lead to imagine any simple Pull Requests, that one should/i could automate [with regex]?👍 @raingart
https://github.com/search?q=window.matchMedia&type=code

[raszpl]

display:none elements are practically free, engine treats them like code comments, manipulating DOM leads to costly repaint and will break when YT JS tries to do something depending on an element you removed.
Removing that Ambient mode div doesnt stop YT from calculating color framebuffer every single frame, no cpu savings there (in fact might be more costly if the code falls into some error trap after failing to paint into non existing div).