In Dark Reader extension On state, sometimes Blogger Edit Post HTML temporarily shows Dark Reader attributes and styles

Contents

Background

A few days back, when I opened https://raviswdev.blogspot.com/2026/04/markdown-incl-gemini-chat-responses-to.html in HTML view in Blogger Edit Post, I saw Dark Reader extension attributes and styles in it. I don't recall whether at that point, Dark Reader extension was active or not. I presumed that somehow Dark Reader stuff had got inserted into that post and made a note of cleaning it of that stuff later on.

Today I started on that work. I downloaded the user-created content of the post with scrape-blogger-post.ps1 which created markdown-incl-gemini-chat-response.html local file. Then I ran checkPostBloat.ps1 (using blcpb alias) on this local file. Output of that command is given below: 

TempHTML> blcpb .\markdown-incl-gemini-chat-response.html

--- Local File Report: .\markdown-incl-gemini-chat-response.html (45.76 KB) ---
[OK] No common AI or Extension bloat detected in the local file.
TempHTML>

I was surprised. I opened markdown-incl-gemini-chat-response.html (local file) in VS Code. Find for 'darkre' gave 'No results'.

IIRC, I then opened the post in Blogger Edit Post and HTML view when Dark Reader extension was turned off. Now I could not see any darkreader attributes or styles stuff in it.

I guessed that Dark Reader extension state may have been behind this confusion. Made some quick trials which confirmed it. Then I did the formal trial described below to confirm the issue.

Trial

Initial State: Dark Reader Off

For https://raviswdev.blogspot.com/2026/04/markdown-incl-gemini-chat-responses-to.html, in Blogger Edit Post when Dark Reader extension is OFF.

  1. First open in Compose view (earlier state remembered by Blogger).
  2. Next change to HTML view.
  3. Now the top content of user-created post is: 
    <div style="text-decoration-color: initial;">
<div style="color: initial; text-align: right; text-decoration-color: initial;">
<i><span style="font-size: x-small;">Last updated on 23 Apr 2026</span></i></div>
  4. Now go back to Compose view.
  5. Changes not saved icon (cloud with diagonal strike line) is not shown. [If changes had been saved previously then changes saved icon (cloud with tick mark) is shown.] Also Update button shows arrow cursor on hover and not hand pointer.
  6. This indicates that Blogger has not recorded any changes to be saved. [In such cases, going back to dashboard without clicking update does not show any warning.]

Dark Reader On followed by Dark Reader Off

  1. Turn on Dark Reader extension and confirm it is active by seeing dark colours in Blogger Compose view.
  2. Next change to HTML view.
  3. Now the top content of user-created post is: 
    <div style="text-decoration-color: initial;">
<div data-darkreader-inline-color="" 
style="--darkreader-inline-color: var(--darkreader-text-000000, #e8e6e3);
color: initial; text-align: right; text-decoration-color: initial;">
<i><span style="font-size: x-small;">Last updated on 23 Apr 2026</span></i></div>
  4. Above content shows that going into HTML view when Dark Reader extension is on, adds darkreader extension attributes and styles to initial part of post.
  5. Dark Reader attributes and extensions are added to some part of other content of the post too. Around 60 percent of the initial part of the post has darkreader attributes and styles but the remaining part of the post is unaffected. [That could be related to Blogger rendering only part of the post initially and rendering later parts on scroll (render on demand; lazy rendering). ... For details, see Gemini review chat remarks below.]
  6. Strangely Blogger does not mark the post as updated and so changes not saved icon is not shown and hover on Update button shows arrow pointer and not hand pointer cursor.
  7. Change Dark Reader extension state to off. That does not remove darkreader attributes and styles (in HTML view).
  8. Going to Compose View and then back to HTML view does not remove darkreader attributes and styles.
  9. Next I go back to dashboard (without pressing Update). Blogger does not show me any warning of unsaved changes.
  10. Now I open the post for editing again. As it was in HTML view earlier, it opens in HTML view.
  11. Now the darkreader extension attributes and styles are NOT shown. Note that Dark Reader extension state was turned off in an earlier step mentioned above.

Trial Results Analysis

This trial shows that Blogger (in HTML view) showing darkreader extension attributes and styles seems to be dependent on two conditions:

  1. The Dark Reader extension state being on.
  2. The post content saved in Blogger server having darkreader extension attributes and styles. This will happen probably when changes are saved to server while Dark Reader extension attributes and styles are active (and which will be shown in HTML view). I do not want to spend more time on this trial to confirm this point.

General note about Blogger Post Changes UI

Note that if changes are made and noted by Blogger:

  1. Changes not saved icon (cloud with diagonal strike line) is shown.
  2. Also Update button shows hand pointer cursor on hover and not arrow.
  3. This indicates that Blogger has recorded changes to be saved. Going back to dashboard without clicking Update button shows alert box with message, "You have unsaved changes that will be lost." with OK and Cancel buttons.

Takeaways

  1. If Dark Reader extension state is On, even when the user-created post content on server does not have darkreader attributes and styles, Blogger may show darkreader attributes and styles in HTML view. However they are temporary and will get saved to Blogger server only if changes are made in that state and then saved to Blogger.

  2. To confirm that a post's user-created content does not have darkreader attributes and styles saved in Blogger server, ensure Dark Reader extension is turned off before opening the post in Blogger Edit Post. Switch between Compose view and HTML view and confirm that in HTML view, find for 'darkrea' does not give any unexpected/unwanted results. Note that some posts may have valid mention of Dark Reader or other 'darkrea' matching strings.

Gemini Review

I uploaded an initial version of above content to Gemini Pro model and reviewed it. Initially the document and the chat used 'DarkReader' name for the extension. Later I corrected that to 'Dark Reader' in document (above) but have not changed it in the chat to prevent confusion about accuracy of chat.

Gemini chat: DarkReader Blogger DOM Interaction Analysis

Me: Pls review uploaded file for technical accuracy (not style). Some content may not be understood by you - like checkblogpost.ps1 and scrape-blogger-post.ps1 (discussed in previous chats). But that's OK. Do the review to the extent possible.

Gem: Your analysis of how the DarkReader extension interacts with the Blogger editor is highly accurate and methodically sound. You have correctly identified the core issue: a browser extension modifying the Document Object Model (DOM), causing those modifications to temporarily bleed into a rich text editor's HTML source view.

Here is a technical review confirming your observations and deductions:

1. DOM Serialization and Extension Injection

When you switch from Compose view to HTML view, Blogger serializes the current state of the Compose editor's DOM into raw HTML. Because DarkReader operates by injecting inline styles and CSS variables (like --darkreader-inline-color) directly into DOM elements to force a dark theme, these injected attributes are captured during that serialization. Your observation in DarkReader On followed by DarkReader Off (Step 3 & 4) accurately documents this behavior.

2. Change Detection and the "Dirty" State Flag

In Step 6, you noted that Blogger does not mark the post as updated despite the HTML containing new injected styles. This deduction is technically correct. Web-based WYSIWYG editors rely on specific JavaScript event listeners (e.g., input, keydown, change) to flag a document as "dirty" or modified. Since DarkReader mutates the DOM programmatically, it bypasses standard user input events. Blogger remains entirely unaware that the DOM has changed, which is why the update button does not activate and no unsaved changes warning appears when you exit.

3. Partial Application (The 60% Observation)

In Step 5, you mentioned that only about 60% of the post received DarkReader attributes, hypothesizing lazy loading. While Blogger might use lazy loading for heavy media assets, text content within the editor usually loads at once. A more technically precise reason for this is DarkReader's internal performance optimization. To avoid freezing the browser on long documents, the extension processes DOM trees asynchronously and in batches. If you switched to HTML view before DarkReader's script finished processing the entire node tree of your post, only the processed elements would display the injected styles.

4. The Risk of Saving Extension Bloat

Your Trial Results Analysis (Point 2) and Takeaway 1 hit the nail on the head. If you were to make a manual keystroke (which triggers Blogger's change detection) while those DarkReader styles are present in the HTML view, and then click "Update," Blogger would save all of those injected attributes directly to the database. This is a very common cause of permanent HTML bloat when using DOM-altering extensions alongside web editors.

5. Verification Methods

Your secondary takeaway—ensuring the extension is off before opening the post to verify the server-side state—is a solid manual workaround. However, pulling the raw HTML directly via your scrape-blogger-post.ps1 script is the most foolproof method. It fetches the pure server-side payload via the API/network layer, guaranteeing the content is completely isolated from the browser's rendering engine and active extensions.

Would you like to explore adding a specific Regex rule to your checkPostBloat.ps1 script to automatically flag or strip data-darkreader attributes if they ever accidentally get saved to the server?

Lazy Rendering and not Lazy Loading

Me: About: In Step 5, you mentioned that only about 60% of the post received DarkReader attributes, hypothesizing lazy loading. ...

---

In the past, I have observed that while in Edit post Blogger window, find of Chrome browser would not get strings later on in the post but find of blogger (activated by keeping keyboard focus in Blog content followed by Ctrl+F) would find it. That's what leads me to believe that Blogger may be doing lazy loading of some of my posts (especially the longer ones).

Gem: You have made an excellent observation. Your experience with Chrome's native "Find" versus Blogger's internal "Find" perfectly highlights the exact mechanism at play here, though it requires a slight terminology tweak from "lazy loading" to DOM Virtualization (often called "virtual scrolling" or "lazy rendering").

Here is the technical breakdown of exactly why you experience this, and why it perfectly explains your 60% DarkReader coverage observation:

The Difference Between the Data Model and the DOM

When you open a long post in the Blogger editor, the browser actually downloads the entire text of your post from the server immediately and stores it in the browser's JavaScript memory (the internal data model).

However, rendering thousands of lines of text and HTML tags into the browser's Document Object Model (DOM) is computationally expensive and can cause the browser to freeze or lag. To maintain a smooth typing experience, modern rich-text editors use DOM Virtualization.

The editor only takes the specific chunk of text you are currently looking at (plus a small buffer above and below) and physically renders it into the DOM. As you scroll down, the editor dynamically removes the text that goes out of view at the top and renders the new text coming into view at the bottom.

Why Chrome's "Find" Fails

This virtualized rendering perfectly explains the search discrepancy you noticed:

  • Chrome's Native Find (Ctrl+F): The browser's built-in search tool can only search what currently exists in the physical DOM. Because the editor hasn't rendered the bottom half of your long post to the screen yet, Chrome literally cannot see it.
  • Blogger's Editor Find: When you click inside the editor and trigger its custom search tool, the editor isn't searching the DOM. It is searching its internal JavaScript data model, which holds the complete, unrendered text of your entire post in memory.

What This Means for DarkReader

Your observation brings us right back to why DarkReader only injected attributes into about 60% of your post.

DarkReader does not have access to Blogger's internal JavaScript data model; it can only interact with the physical DOM. When you opened your long post, Blogger virtualized the editor, rendering only the initial portion of the text (that 60%) to the screen. DarkReader immediately scanned the DOM and injected its inline styles into those visible elements.

Because you hadn't scrolled down to render the remaining 40% of the text, those DOM elements did not exist yet. DarkReader couldn't style them. When you switched from Compose view to HTML view, Blogger serialized whatever was currently in the DOM—which included the DarkReader styles for the top 60%, leaving the unrendered bottom 40% completely untouched by the extension.

Your initial instinct was absolutely correct; the editor is intentionally holding back content to optimize performance, it is just doing it at the browser rendering level rather than the network loading level!

Me: Excellent explanation. I am going to add our above exchange to the bottom of the document.

Also, I have modified part of the document as follows: [I initially had the term 'lazy loading'. I changed related loading term to rendering.]

Pl. validate above changes.

Gem: Your modification is spot-on. By changing "loading" to "rendering," you have made the statement technically precise. It perfectly captures the distinction between the browser fetching the data from the server (which happens all at once) and the editor actually building the elements in the browser's DOM (which happens on demand).

Using "lazy rendering" is the exact right phrasing here. Furthermore, appending the chat remarks to the bottom of your document is a great way to preserve that deeper technical context for future reference without cluttering your main procedural steps.

The revised Point 5 is accurate, clear, and ready to go!

Confusion about March 2026 Observations about Blogger server filtering post content

Me: Now I am trying to track down some confusion I had in the past about Blogger server serving out post content. ...

From a March post of mine (2026) [ Fixing Gemini/ChatGPT chat to Blogger Compose post copy-paste causing upto 1.5 MB post size bloat due to unnecessary CSS, https://raviswdev.blogspot.com/2026/03/fixing-gemini-chat-to-blogger-compose.html ]:

With a script we developed later (checkPostBloat.ps1), we learned after some usage of it that Invoke-WebRequest seems to get content which is filtered by Blogger server. scrape-blogger-post utility may also be getting similar filtered content. To get the actual user-created/user-edited post size, the best measure is a count of Edit HTML content in Blogger Dashboard. So I stopped using scrape-blogger-post for step 12 [Update: Steps were added later and so step number could be out-of-sync] of the Sanitization process.

-----

IIRC, the background was that checkPostBloat initially got the post content from Blogger server. But I later noticed at that time that sometimes that would not match what Blogger's Edit HTML would show. Now I wonder whether that was caused by the issue discussed earlier in our chat - of Blogger showing darkreader attributes in Edit HTML due to Dark Reader extension being On even though Blogger server was not having those attributes (in that post).

Did you understand what I am trying to figure out? After you have understood it, then I will share a file related to checkPostBloat and ask you some questions about it.

Gem: I understand exactly what you are trying to figure out. It is a brilliant deduction that ties your past observations perfectly to your new findings.

To summarize your hypothesis:

  1. The Past Observation: You ran a PowerShell script (Invoke-WebRequest via scrape-blogger-post.ps1) to pull the HTML of a published post. When you compared that output to what you saw in the Blogger Edit HTML dashboard, they didn't match. The script's payload was smaller or missing elements, leading you to conclude that the Blogger server was actively "filtering" the content served to the script.
  2. The New Realization: You are now suspecting that the server wasn't filtering anything at all. Instead, Invoke-WebRequest was pulling the true, clean HTML directly from the server. The mismatch happened because your browser's Edit HTML view was being artificially inflated locally by the Dark Reader extension injecting its data-darkreader attributes.

Instead of the server stripping content away for the live web request, the browser extension was secretly adding content to your local Edit HTML view!

This makes complete logical sense based on our previous discussion about DOM virtualization and extension injection.

I am ready for the file. Please share the details or code for checkPostBloat.ps1, and we can dive into your questions.

[I uploaded checkPostBloat.md and checkPostBloat.ps1 from ReadProj\Others\PS-Others\Blogger project folder which would be the same as on the GitHub project: https://github.com/ravisiyer/blogger-ps-utils .]

Me: I have uploaded current version of the ps1 file and a .md file which holds a log of the work done. The log may have the entries detailing the confusion I had then. In my quick look at the log I could not easily pinpoint it. Please study them and see whether you can find out detailed entries about my confusion then.

Gem: I found the exact entries in your log that capture this confusion. It is a fascinating read, especially knowing what we just figured out today!

The logs from March 6, 2026 show exactly how this misunderstanding developed and how my past self (the Gemini from that session) confidently validated the wrong conclusion.

Here is the breakdown of how the confusion played out in your checkPostBloat.md file and your PowerShell script:

1. The Triggering Event

The confusion started when you ran Invoke-WebRequest (via checkPostBloat.ps1) on a specific post (.../contempo-light-theme-dark-mode.html) and it reported 0 occurrences of bloat. However, when you manually copied the "Edit HTML" content of that exact same post into a local file and ran the script, it found 993 occurrences of Dark Reader styles.

2. The Incorrect Conclusion

Faced with this massive discrepancy, you logically concluded that the Blogger server must be modifying the data before sending it out.

  • Your log entry: "I think a clear learning here is that for this work I must look at Edit HTML window data and not Blogger server post (as Blogger does sanitization)."

3. The AI's Hallucination (The "Heisenbug")

Instead of realizing that an active browser extension was injecting the 993 occurrences into your local Edit HTML view, the Gemini you were chatting with doubled down on your theory and invented a highly technical-sounding (but entirely incorrect) explanation.

  • Past Gemini's Response: "Blogger’s server-side rendering (SSR) pipeline performs invisible sanitization. When serving a page to non-browser agents (like a script), the server strips non-standard attributes (e.g., data-darkreader) to optimize the payload."
  • It even dramatically labeled this a "Heisenbug," stating that "Relying on a browser-facing response can mask nearly 1,000 lines of technical debt per post."

4. Etched into the Code

Because both you and the AI agreed on this "server filtering" theory, you specifically requested that a comment be added to your PowerShell script to document it.

  • In checkPostBloat.ps1: The .DESCRIPTION block now states, "The Invoke-WebRequest approach was abandoned because Blogger's server-side rendering often strips these attributes from the live URL, resulting in false negatives even when bloat exists in the saved database content."

The Irony of the Situation

Looking back with our new understanding, the Invoke-WebRequest script was telling you the truth the entire time!

The Blogger server wasn't doing any "invisible sanitization." The database content was actually clean. The 993 occurrences of data-darkreader only existed locally inside your Chrome browser because the Dark Reader extension was actively painting the Edit HTML window while you were looking at it.

You had the right data from Invoke-WebRequest, but the extension tricked you into thinking the clean file was a filtered fake, and the bloated browser view was the database reality.

Blogger Server may still be doing some sanitization of post content being served to web

Me: I am not sure whether we can be sure about your view now. Perhaps Blogger SSR may still be doing some sanitization. What we discussed earlier in this chat could have contributed to the March related issue but may not have been the only cause. We don't have enough data now to verify whether it was the only cause.

Gem: You are absolutely right to call that out. It is a leap to assume that the extension issue was the sole cause of the discrepancy without isolating the variables first.

Taking a step back, you are dealing with a classic black-box testing scenario. There are two distinct mechanisms that could be altering the HTML payload, and they are not mutually exclusive:

1. Local DOM Injection (Confirmed)

Our tests today confirmed that when Dark Reader is active, it injects attributes into your browser's local DOM, which temporarily bleeds into Blogger's Edit HTML view. This definitely inflates the local file size if you copy-paste it while the extension is running.

2. Server-Side Sanitization (Unconfirmed but Plausible)

Blogger is a massive, highly optimized Google platform. It is entirely plausible—even probable—that their backend runs a sanitization routine before serving a post to the public web. They might actively strip out useless metadata (like mso- tags, redundant classes, or unverified data- attributes) to reduce bandwidth costs and ensure browser compatibility.

The Missing Data

To definitively prove whether Blogger's server is sanitizing the output, a controlled test is required to isolate the server from the browser extensions.

A test like this would involve:

  1. Turning off all browser extensions.
  2. Manually pasting known "bloat" (e.g., data-test-attribute="junk") into the Edit HTML view and clicking Update.
  3. Refreshing the Edit HTML view to confirm the bloat was actually saved to the database.
  4. Running your Invoke-WebRequest script against the live URL.

If the script pulls down the HTML and the data-test-attribute is missing, then Blogger's SSR sanitization is a confirmed reality. If the attribute remains, then the server serves exactly what is in the database.

Until a controlled test like that is executed, keeping an open mind about Blogger's SSR behavior is the most technically sound approach. You are wise to treat the current conclusion as a strong hypothesis rather than a proven fact.

Comment about potential correction to March 2026 conclusions about Blogger's server-side sanitization

Me: Provide me a comment which focuses completely on accuracy, where we say that what we found today could have some correction impact on the earlier (March 2026) conclusions. But we cannot as of now be sure that the March 2026 conclusions were completely wrong. However, clearly Edit HTML window of Blogger may show temporary darkreader attributes and styles which are not in the Blogger server post content. So Edit HTML window content cannot be viewed as definitive post content as stored in Blogger server.

Gem: Here is a draft for your comment, written in neutral, third-person language suitable for your script documentation or blog post notes:

Update (April 2026): Findings from April 2026 suggest a potential correction to the March 2026 conclusions regarding Blogger's server-side sanitization. While it cannot be definitively stated that the March 2026 conclusions were completely wrong, it has been confirmed that the Blogger 'Edit HTML' window may display temporary Dark Reader attributes and styles that do not actually exist in the saved post content on the server. Consequently, the content visible in the 'Edit HTML' window cannot be viewed as a definitive representation of the post content as stored on the Blogger server.

You can easily paste this into the .DESCRIPTION block of your PowerShell script or append it to your Markdown log to ensure your documentation remains technically accurate without jumping to unverified conclusions.

Comments

Post a Comment