Discussion and Analysis of Dark Reader Chrome extension test post with Gemini assitance

My recent blog post: Testing Dark Reader Chrome extension addition of darkreader CSS styles to HTML of blog post edited in Compose mode is discussed and analyzed with help of Gemini in this post.

Related chat: Analyzing Blog Post Bloat and Content

Given below is an edited version of related exchange with Gemini (Gem).

I saved the contents of 'Edit HTML' view of above blog post in a file post-orig.html and uploaded it to Gemini.

Me: 4 Mar. 2026:

The uploaded file has a test blog post I created: Testing Dark Reader Chrome extension addition of darkreader CSS styles to HTML of blog post edited in Compose mode

Please study the HTML in this file which has the test procedure as well as the data. Then give me your analysis and views.

Gem: The HTML content in post-orig.html provides a clear technical demonstration of how the Dark Reader Chrome extension interacts with the Blogger Compose mode to inject permanent CSS bloat.

Analysis of the Test Procedure

The file documents a multi-step test to isolate the cause of the darkreader CSS injection:

1. Baseline Test (Enabled but 'Off'): Adding text and links while the extension was active but toggled "Off" resulted in clean HTML with no injected styles.

1. Active Test (Enabled and 'On'): Typing directly in Compose mode with Dark Reader "On" also did not initially inject styles.

1. The Trigger (Copy-Paste): The bloat occurred specifically when content was copy-pasted from another source while Dark Reader was "On". This operation brought in a massive amount of data-darkreader attributes and inline --darkreader CSS variables.

Key Findings from the Data

The HTML code in the file confirms several critical patterns regarding "Extension Bloat":

• Style "Contamination": Once the copy-pasted content was introduced, even new lines typed manually in Compose mode inside that same div inherited the Dark Reader styles (e.g., background-color: #181a1b; color: #d3cfca;).

• Signature Density: The snippet shows a high concentration of data-darkreader-inline-bgcolor and data-darkreader-inline-color attributes on nearly every element (<h2>, <a>, <span>, <div>).

• Inline Variable Injection: The code is flooded with custom CSS properties such as --darkreader-inline-bgcolor: var(--darkreader-background-181a1b, #131516);. These are temporary variables used by the extension that become "baked" into the Blogger post during the paste event.

Views and Implications

Based on this test, your conclusion that the enabled state of Dark Reader during composition is a primary source of bloat is technically accurate.

• Compose Mode as a Trap: The Blogger Compose window acts as a "Rich Text" receiver. It interprets the "visual" state created by Dark Reader as intended formatting and saves it into the post's source code.

• The "Clean Room" Solution: As demonstrated at the end of your file, creating a fresh div in HTML view and then typing in Compose mode successfully avoids the bloat, provided no external content is pasted into that container.

...

Me: Great! I think now I have a handle on which condition darkreader unwanted CSS gets introduced in the Blogger blog post. This gives me room to continue to use Dark Reader extension to keep Blogger Compose window dark but prevent darkreader unwanted CSS being introduced by not doing any direct copy-paste from any other HTML page including Gemini and ChatGPT pages. I can keep checking from time to time whether the HTML has --darkreader-- entries in it to ensure that this workflow is working properly. What do u say?

Gem: That is an excellent and highly practical strategy. You have successfully isolated the "event horizon" for the bloat: the act of pasting Rich Text while the extension is active. By identifying that the Blogger Compose window is a "passive receiver" of these injected styles, you can now enjoy a dark editing environment without paying the "size tax".

Validation of Your New Workflow

Your proposed workflow is technically sound for the following reasons:

• Isolation of the Paste Event: Your tests in post-orig.html proved that typing directly in the editor while Dark Reader is "On" does not bake in CSS; only the clipboard-to-editor transfer triggers the injection.
• Markdown as a Shield: By continuing to use your Markdown-to-HTML converter and pasting into the Edit HTML view, you bypass the layer of the browser where Dark Reader and Blogger's WYSIWYG editor "negotiate" formatting.
• Proactive Auditing: Using your checkPostBloat.ps1 script as a periodic "health check" allows you to catch any accidental slips before a post becomes part of your permanent blog history.

---

Refined "Safe Harbor" Checklist

To ensure this workflow remains "leak-proof" as you audit your 297 posts, keep these three checks in mind:

1. The "Div" Sandbox: If you must use Compose mode for formatting, always ensure you are typing inside a clean <div> or <p> tag that was created while the extension was off or via the HTML view.
2. The Keyboard Shortcut: Remember that Ctrl + Shift + V (Paste as Plain Text) is your best friend if you ever feel tempted to paste directly into the Compose window, as it strips the Rich Text flavor that contains the Dark Reader attributes. [Ravi: Problem is that headings, bold, italics etc. are all lost and so Markdown to HTML is the superior solution.]
3. Variable Watch: The specific signature --darkreader-inline is the most reliable indicator of bloat. Even a single hit in your script means the extension has "touched" the code.

...

Me: I think my Dark Reader tests are comprehensive enough for my current needs. I have already published that post. I will retain it as is for any future additional tests I may need. 

Gem: That is a sound decision. Retaining that test post as a living laboratory is an excellent way to maintain your "clean room" standards for future blog development. By documenting the exact moment the bloat is introduced—the clipboard-to-editor transition—you have turned a frustrating technical hurdle into a repeatable engineering benchmark.

Why Your Strategy is Solid

• The "Enabled vs. Active" Distinction: Your tests proved that you don't need to uninstall Dark Reader; you simply need to avoid using it as a bridge for copy-pasting rich text.
• Zero-Cost Dark Mode: You can now safely enjoy the eye-strain relief of Dark Reader while writing, knowing that your "Markdown-to-HTML" pipeline acts as an impenetrable firewall against unwanted CSS.
• Audit Trail: Having that post live means you can re-run your checkPostBloat.ps1 script against it anytime you update your browser or extension to see if the "injection signatures" have changed.

Moving Forward with the Audit

Since you’ve mastered the "Dark Reader" variable, you can move through your remaining 297 posts with much higher confidence. You now know exactly what to look for in your 300 KB+ targets:

• High Density (>0.1): Likely a "Dark Reader" victim that needs a Markdown-based rewrite.
• Low Density (<0.01): Likely just a content-heavy post that is safe to leave alone.