Blogger Contempo Light Theme: Challenges involved in providing light/dark mode support
Quick Info
Summary
Details
- Adding CSS (put this in Theme → Customize → Advanced → Page Text → Add CSS or directly in HTML header)
- Toggle Button (place somewhere visible in your blog, e.g., header gadget, top post area)
- JavaScript to switch modes (put right before </body> in Theme HTML or via gadget)
In Contempo Light, the .post-body container has its own background and text color, which is why targeting just body didn’t work. By applying the CSS directly to .post-body with !important, you successfully overrode the theme styles.
-
Now your post content switches to dark mode correctly when the system prefers dark mode.
-
Later, you can extend this to links, blockquotes, headers, sidebar widgets, etc., to make a complete dark mode experience.
...
Me: Within each comment form there is an iframe which has a document with html and body. So whatever we have tried with #comment * does not apply to body elements within iframe.
CG: CSS from your main page cannot affect content inside an iframe, because each iframe runs in its own isolated document (different DOM and often a different origin for security reasons — the “same-origin policy”).
That means:
-
Your dark mode CSS (even with
!important) won’t apply to the comment form fields that are loaded via the iframe (like Blogger’s embedded comment form). -
You can confirm this by inspecting the iframe — you’ll see its own
<html>and<body>inside a separate document.
...
Me: I think I have now understood why we do not have a Contempo theme with light/dark mode download or good article. It is too difficult to get a complete solution. You have to target individual items in the blog HTML and even then due to iframe kind of issues, you cannot fix everything. So whatever solution one may get, it will not be a profesisonal looking solution.
I think I will now drop the idea of having dark/light mode for my Blogger blogs as I don't want to risk an amateurish dark mode blog which may put off some readers.
So yes, even though partial fixes (like custom CSS for .post-body, .sidebar, etc.) can make large parts of the blog look dark, you’ll always hit limitations such as:
-
The comment iframe (uncontrollable white patch)
-
Some widgets and theme-generated elements that inject inline styles
-
Images or text colors that don’t invert well
In short — a full, clean dark/light toggle needs theme-wide coordination, which Blogger simply doesn’t expose.
...
Me: I currrently use Windows High Contrast to see my blog posts in a sort-of dark mode which also works for most of Blogger post edit Compose mode (does not work so well in HTML mode for editing posts). I will stick with that.
But with these efforts that I put in, I now have a clearer picture of why it is difficult to have a professional looking dark/light mode support for blogger blogs.
...
Me: I was thinking whether we could experiment with a different UI/UX. We could have a button that shows an alert/dialog which informs user about limitations of dark mode on the blog and then give him option to use system dark/light mode setting for the blog. By default the value will be off (don't use system dark/light mode setting). And, at least, initially we won't provide a button to directly switch between light/dark modes.
[CG provided some code for the above. ... Some iterations ...]
The Blogger Layout UI is convenient for simple placement, but it has limited control over horizontal alignment inside complex theme sections like the Contempo header. That’s why your inline-block approach didn’t work:
-
The
Search (Top)group is structured so that each widget (BlogSearch,HTML) is a block-level div inside a parent container. -
Block-level elements naturally stack vertically, and the Layout editor doesn’t let you inject CSS that changes the parent container’s layout or wraps widgets inline.
openModal() (the one that opens your dark-mode dialog).1️⃣ Identify the menu you want to add the item to
-
Go to Blogger → Layout → Pages / Menu (depending on how you’ve set up your top navigation).
-
Usually, menu items are static pages or custom links.
2️⃣ Add a Custom Link menu item
-
In the Pages / Menu widget, choose Add external link (or “Add Link”).
-
Set:
-
Name: e.g.,
Dark Mode -
URL:
javascript:openModal()
-
<h3> element does not automatically get the darkmode-optin class — only the <body> has it.So if you want to apply a style to that <h3> element only when its ancestor <body> has the darkmode-optin class,
you use a descendant selector in CSS.
✅ Correct CSS syntax
Explanation:
-
body.darkmode-optin→ targets the<body>only when it has that class. -
.post-title→ any descendant element (in your case,<h3 class="post-title">). -
Together: this rule only applies when the dark-mode class is active.
When I said “your .post-title elements will automatically pick the dark color”, I meant:
All elements inside the
<body>that has thedarkmode-optinclass,
and that themselves have the class.post-title,
will use the dark color style.
...
Me: Add CSS:
@media (prefers-color-scheme: dark) {
body.darkmode-optin .post-title {
background-color: black !important;
color: white !important;
}
----
Works for post title element (h3 element).
If darkmode-optin class is present in body (added by JS when darkModeEnabled local storage variable is true), then
CSS styles below are applied to post title if Chrome setting is dark mode.
CSS styles below are NOT applied to post title if Chrome setting is light mode.
If darkmode-optin class is absent in body (removed by JS when darkModeEnabled local storage variable is false), then
CSS styles below are NOT applied to post title irrespective of Chrome setting being light or dark mode.
Let’s restate what’s happening — and why it’s working exactly as intended:
🧠 CSS Logic Recap
This means:
-
The outer condition —
@media (prefers-color-scheme: dark)— activates only when Chrome (or the system) is in dark mode. -
The inner selector —
body.darkmode-optin .post-title— applies only when the<body>element has the classdarkmode-optin.
⚙️ So the combined effect is:
| Chrome/System Mode | darkmode-optin class present on <body>? | CSS applied? | Explanation |
|---|---|---|---|
| Light mode | ❌ No | ❌ No | Media query inactive |
| Dark mode | ❌ No | ❌ No | Media query active, but selector doesn’t match |
| Light mode | ✅ Yes | ❌ No | Media query inactive |
| Dark mode | ✅ Yes | ✅ Yes | Media query active and selector matches |
✅ Result
You’ve now got a two-condition control:
-
User’s system preference (via
prefers-color-scheme) -
Your own dark mode toggle (
darkmode-optinclass set via JS + localStorage)
That’s a robust design — gives full control both ways. 👏
Would you like me to show how you can extend this same logic to entire post area, not just .post-title (e.g., .post-body, .post-footer, etc.) — while keeping the same “both conditions must match” rule?
Me: yes ... I guess this has to be repeated for all those elements.
[... CG repeated the error it had made in previous version which I had to figure out.]
Me: I think it should be only this: ...
[CG validated the corrected code and said:]
✅ Yes — that’s a perfectly clean, minimal version for your use case.
This version does exactly what you want:
-
Keeps light mode completely untouched.
-
Only applies dark styling when:
-
The user explicitly enables dark mode (
darkmode-optinadded to<body>by JS), and -
The system/browser prefers dark mode (
prefers-color-scheme: dark).
-
That’s the safest, most predictable combination — no side effects, no flickering.
You can go ahead and replace your CSS block with exactly what you posted:
💡 Tip:
If later you want to darken sidebars or other areas, just add similar selectors under the same media query using the same variables — it’ll remain consistent and easy to adjust in one place.
...
- Title: Dark Mode Settings
- Page URL: javascript:openModal()
Me: --dark- has no matches in source
CG: ... Your chosen variable names (--dark-bg, --dark-text, etc.) are unique to your gadget CSS and do not clash with any Contempo Light theme definitions.
So you can confidently keep this structure as-is — it’s clean, isolated, and future-proof.
...
--------------------
Works for many but not all elements in blog post page.
If darkmode-optin class is present in body (added by JS when darkModeEnabled local storage variable is true), then
CSS styles above are applied to many elements but not all if Chrome setting is dark mode.
CSS styles above are NOT applied to any elements if Chrome setting is light mode.
If darkmode-optin class is absent in body (removed by JS when darkModeEnabled local storage variable is false), then
CSS styles above are NOT applied to any elements irrespective of Chrome setting being light or dark mode.
So the elements to which the above styles are not getting added (in Chrome dark mode and darkModeEnabled in JS) have to be identified and then added to above CSS. I will do that a little later.
But now the basic approach seems to have got validated. Some issues remain including icon-button not showing for most window widths except close to max. width on PC (at which time menu bar is shown on left). But those are relatively smaller issues.
Let’s confirm what’s happening:
✅ Main dark-mode mechanism works correctly
-
darkmode-optinadded → allows dark styling. -
@media (prefers-color-scheme: dark)ensures those styles only apply if system (Chrome) is in dark mode. -
If either condition fails, you get clean light mode.
✅ Next debugging steps are clear
-
Identify remaining elements whose colors stay light even in dark mode (e.g., header, sidebar, post-footer, gadgets).
-
Add rules for them using the same variable set, under the same media query — keeping things modular.
✅ The floating icon-button visibility issue
That’s indeed smaller and JS-related. The likely cause is this part: [CG did not get the problem code.] ....
So yes — you’ve now validated the core dark-mode framework 🎯
Next step (when ready): list or highlight a few elements that didn’t switch to dark mode, and I’ll help you write the corresponding CSS additions using your existing variable set.
[Later I explored the experimental chrome://flags/#enable-force-dark feature on my PC desktop. I was already using it on my mobile Chrome where it was aligned with device light/dark mode. Unfortunately on PC, it was ignoring Chrome and Windows (Colors) light mode. Also the colors in dark mode were bright white for key elements but it seemed to handle all elements. But I also had the Windows High Contrast mode feature as an alternative dark mode.... As this Contempo Light customization would involve lot more detective/debugging work to identify Blogger elements to have dark mode colors and for various webpages like post details, post snippets/overview etc., I decided to stop this activity here but record key parts of it for any future needs I may have.]
- How To Add Dark Mode For Your Blogger Website (Part I), https://www.youtube.com/watch?v=5f2IS-kztmw , 13 min. 23 secs., Sep. 2020
- How To Add Dark Mode For Your Blogger Website (Part II), https://www.youtube.com/watch?v=bY2RDnnOd90 , 15 min. 11 secs., Sep. 2020
1️⃣ What * does
-
The universal selector
*matches all elements, regardless of type, ID, or class. -
It does not care whether the element has a class or not — it just selects every single element.
<a> selector more specific than the * rule.1️⃣ Why it happens
-
Your JS gadget checks
localStorageand addsdarkmode-optinonly afterwindow.load:
-
Until this runs, the
<body>does not havedarkmode-optin, so the browser applies default light-mode CSS. -
Then after JS executes (a few hundred milliseconds to seconds, depending on network/JS execution),
darkmode-optinis added → CSS for dark mode applies → you see the flash from light to dark.
✅ Recommended solution
-
Add tiny inline JS in
<head>, before your dark-mode CSS:
-
Keep your current CSS as-is (with
body.darkmode-optin ...).
-
Now the page renders in dark mode immediately if the user has dark mode enabled.
-
No more flash of light mode.
With a Blogger gadget, the HTML/JS runs after the page body has already started rendering, so you’ll always see a small delay (the “flash of light mode”) if you rely solely on the gadget.
...
Me: Got the issue and HTML head solution. But how about the JS and CSS code we added. Will that slow things down
CG: Not really — your JS and CSS are very lightweight, so they won’t noticeably slow down page rendering. Here’s why:
1️⃣ CSS
body.darkmode-optin .page,
body.darkmode-optin .page *,
body.darkmode-optin .sidebar-container,
body.darkmode-optin .sidebar-container * { ... }
-
Modern browsers are extremely fast at applying CSS, even with universal selectors (
*). -
The only minor cost is that using
*for every descendant forces the browser to calculate styles for all child elements. -
On a typical blog post page, this is imperceptible — your page won’t be slower for readers.
2️⃣ JS gadget
-
It only does a few things:
-
Reads
localStorage -
Adds/removes a class (
darkmode-optin) -
Controls a floating button’s
display -
Handles modal open/close
-
-
No heavy computations, no loops over many elements, no network requests.
-
Running this after page load is instant on modern devices.
3️⃣ What causes the visible delay
-
The “flash of light mode” is not due to JS or CSS being slow.
-
It’s because the darkmode-optin class is added only after the page has already painted.
-
Moving JS into
<head>(or top of body, before main content) avoids the flash — that’s the main speed fix.
✅ Conclusion
-
Your existing JS and CSS do not slow down page load in any noticeable way.
-
The only improvement needed is applying the darkmode class as early as possible (pre-head or early inline JS), not optimizing JS execution.
...
Me: Got it. Even local storage access would be cached by chrome i guess
CG: Exactly ✅ — accessing localStorage is extremely fast and practically instantaneous.
-
Chrome (and all modern browsers) caches
localStoragein memory, so reading or writing a small key likedarkModeEnabledtakes microseconds. -
For your gadget:
let darkModeEnabled = localStorage.getItem('darkModeEnabled') === 'true';
-
This is not a performance bottleneck at all, even on slow devices.
The only reason you notice a delay is CSS not applying until the class exists, not the localStorage read itself.
If you combine early <head> JS with your current CSS, the dark mode will appear immediately, and the localStorage access won’t be perceptible at all.
Me: But our js code will run for every blog post load. .... This is where something like React does it more efficiently
CG: Exactly — you’re thinking along the right lines. 😄
1️⃣ Current approach
-
Your JS gadget runs on every page load, yes.
-
It:
-
Reads
localStorage -
Adds/removes a class (
darkmode-optin) -
Updates the floating button
-
Hooks modal button events
-
-
Cost: very tiny — a few DOM reads/writes and event bindings. For a normal blog page, this is imperceptible.
-
The only “visual cost” is the flash of light mode, not CPU/memory usage.
2️⃣ How React (or frameworks like it) handle this
-
React is component-based and uses a virtual DOM.
-
Instead of running raw DOM queries and class toggles on page load, React:
-
Computes the DOM diff first
-
Only updates what actually changed
-
Can conditionally render parts of the page immediately
-
-
In a React app, your “dark mode enabled?” check could happen before the component mounts, so the page renders in the correct mode instantly, without flashes.
-
Also, React encapsulates logic per component, so repeated event binding across multiple components is avoided.
3️⃣ Key difference for your Blogger blog
-
You’re using plain JS in a gadget, which is lightweight, but:
-
It runs once per page load
-
No virtual DOM diffing → browser applies CSS to all descendants
-
-
On small pages, this is fine. On very large pages with lots of elements, the
*selector and DOM reads/writes might take a few milliseconds, but still tiny compared to network load.
4️⃣ Conclusion
-
For your blog: current JS + CSS is fast enough.
-
The main issue is timing, not efficiency.
-
If you wanted React-like efficiency: you’d need to rebuild the blog UI in a SPA framework, which is overkill for Blogger.
...
Me: I think (I) will try the head option u gave. Now i understand why it is necessary in our case to fiddle with theme HTML....about chrome dark mode extensions for this task vs our approach what r the pros and cons
CG: Exactly — using the <head> inline JS is the only way to eliminate the flash, because you can add the darkmode-optin class before the browser paints the page. Now let’s compare that approach with using Chrome dark-mode extensions.
1️⃣ Your approach (JS + CSS gadget + optional <head> tweak)
Pros:
-
Works for all visitors, not just you.
-
Fully customizable — you control exact colors, backgrounds, and link styles via CSS variables.
-
No dependency on external tools; works on any browser that supports CSS variables and prefers-color-scheme.
-
Can integrate a floating toggle button for users.
-
Supports system dark mode detection (
prefers-color-scheme) plus manual override.
Cons:
-
Needs editing the theme
<head>to remove flash completely. -
Some extra JS running per page load (tiny, but still per visit).
-
Slightly more complex to maintain than using a pre-built extension.
2️⃣ Chrome dark-mode extensions
Pros:
-
Quick to install; no code changes to your blog.
-
Applies dark mode instantly for the user who installed it, even on sites that don’t have dark mode.
-
Often includes additional tweaks like invert images, tables, etc.
Cons:
-
Only works for the user who installed the extension. Your visitors will not see dark mode unless they also have it.
-
Extensions may override your blog’s styles unpredictably.
-
Harder to achieve precise control over colors (links, blockquotes, sidebar).
-
Sometimes adds performance overhead or visual glitches.
-
Not integrated with system dark mode preferences in a consistent way.
✅ Summary
| Feature | JS + CSS Gadget | Chrome Extension |
|---|---|---|
| Works for all visitors | ✅ | ❌ |
| Custom colors & theme control | ✅ | ❌ / limited |
| Automatic system dark-mode support | ✅ | Depends on extension |
| Needs editing theme HTML | ✅ (for head tweak) | ❌ |
| Flash-free dark mode | ✅ (with head tweak) | Depends on extension |
| Quick setup | ❌ (requires code) | ✅ |
| Maintenance overhead | Medium | Low (per user) |
Bottom line:
-
If your goal is consistent dark mode for all blog readers, your gadget + CSS is the right approach.
-
If your goal is just for yourself or a few users, a Chrome extension is simpler but limited.
...
Me: Interesting comparison.... I use a chrome dark mode extension [Dark Mode]. One issue is that it applies to all sites by default. Though it may have configuration to include or exclude sites - (I) hv not checked.. . With this JS CSS approach we upgrade our blog to hv dark mode feature like say Whatsapp on web has. That makes the blog more user friendly
CG: Exactly — that’s the key difference. 😄
-
A Chrome dark-mode extension is generic, applying a “one-size-fits-all” dark theme to every site you visit. Even if it allows site-specific exceptions, it’s still per-user and per-browser. Your blog readers mostly won’t have it installed.
-
With your JS + CSS gadget approach, you’re giving native dark mode support for all visitors:
-
They can opt in via the floating toggle.
-
System dark mode (
prefers-color-scheme) is respected. -
Colors, background, and links are precisely controlled, just like WhatsApp Web or other modern web apps.
-
Works on any modern browser, not just Chrome.
-
So your approach upgrades your blog’s UX in a way that browser extensions can’t: it’s built-in, configurable, and consistent for every reader.
The only trade-off is a tiny initial JS execution and possibly adding a small snippet to <head> to eliminate the flash, which is well worth it for a professional-looking dark mode experience.
It essentially turns your Blogger site into a mini web app with dark mode support, which is a modern, user-friendly feature.
Me: Btw the icon button visibility problem seems to be due to me adding the JS gadget in a menu sidebar. So the icon shows only when menu sidebar is open.
CG: Ah — that explains it perfectly. 😄
-
In Blogger, when a gadget is placed inside the menu sidebar, any elements it creates (like your floating
#themePromptBtn) are technically children of the sidebar container. -
If the sidebar is hidden (collapsed), its children are also hidden, so your floating button doesn’t appear.
-
That’s why you only see the icon when the sidebar is expanded.
Here’s the breakdown:
🧩 Why debugging must be done directly in Blogger
-
Blogger themes are server-rendered XML/HTML templates.
You can’t easily reproduce that environment (the<b:...>tags, widget includes, and template structure) in VSCode. -
Even if you copy-paste the HTML into VSCode and open it locally,
many things — likeb:skin,b:section, andb:widget— won’t render properly outside Blogger. -
The only true-to-reality way to test your
<script>and<style>in contextis to edit the live Blogger theme (or a test blog) and check the results in Chrome DevTools.
You’re combining the strengths of VSCode (developer tooling) with the strengths of Blogger (hosted runtime).
Here’s why and how your setup works beautifully, plus a few fine-tuning tips:
✅ Why your approach is solid
-
Syntax safety:
Blogger’s editor doesn’t validate CSS or HTML syntax — VSCode does (real-time linting + highlighting).
You’ll catch missing braces, stray semicolons, or unclosed tags before Blogger swallows them silently. -
Version safety:
Keeping snippets likeThemeAdd.css,Gadget.html,InHead.cssin VSCode gives you a mini-version history.
You can diff changes, backtrack, or experiment freely without risking the live blog. -
Focused debugging:
You only need to switch to Blogger/DevTools when logic (not syntax) fails — e.g. when localStorage or CSS specificity behave unexpectedly.
requestAnimationFrame() (often shortened as rAF) is a browser API that asks the browser to call your function again just before the next screen repaint — typically about 60 times per second (≈ every 16 ms).🔍 In our context
We use it here:
Here’s what happens step-by-step:
-
The code runs immediately while the
<head>is being processed. -
If
<body>doesn’t exist yet (document.bodyisnull),
→ it asks the browser: “Hey, runcheckBody()again before you repaint the next frame.” -
The browser does that after it parses more of the HTML, usually within a few milliseconds.
-
As soon as the
<body>element appears, the condition succeeds, and the.darkmode-optinclass is added instantly. -
The loop stops automatically (because it no longer calls
requestAnimationFrame()oncedocument.bodyexists).
⚡ Why it’s nice for this use
-
It’s non-blocking — doesn’t freeze the page.
-
It’s efficient — the browser only runs it at the best possible time to update the display.
-
It lets your script apply dark mode almost instantly — before the user sees the light-mode flash.
🧠 In short
requestAnimationFrame()lets you re-run a function right before the next screen draw — a smooth, efficient way to wait for something (like<body>) to exist.
...
-
Blogger Theme → Customize → Add CSS UI is convenient, but it’s not always fully reliable:
-
It can duplicate CSS if you add the same rules multiple times.
-
It may not show all existing CSS in the editor, especially older blocks.
-
It can lead to conflicting or overwritten rules, which is what probably caused your menu icon to disappear earlier.
-
-
Direct Theme HTML editing is the most predictable approach:
Here’s why:
-
In Blogger Layout, when you place a gadget in the Footer, the generated HTML for that gadget is nested inside the footer container.
-
That container (and possibly its ancestors) may have
position: relative/absoluteor even its own stacking context. -
Even though your modal has
position: fixedand a highz-index, it is still constrained by the stacking context of its ancestors. That’s why it can appear behind the sidebar.
The typical fix
-
Append the modal to
<body>, not inside the footer or any gadget container.
Here’s why moving the gadget in Layout UI didn’t solve it:
-
Even in Page Body, the gadget’s HTML is still nested inside some
<div>containers (likemain-wrapperorcontent-wrapper) that may have:-
position: relativeorposition: absolute -
Their own stacking context
-
-
Because of this, your modal’s
position: fixedis still constrained by ancestor stacking contexts, so it can appear behind the sidebar.
✅ Conclusion
-
To guarantee the modal appears above all page elements, you need it to be a direct child of
<body>. -
The only reliable way in Blogger to do that is by editing Theme HTML and either:
-
Pasting the modal + overlay
<div>right before</body>, or -
Dynamically appending it to
<body>via JavaScript (from a gadget)...
Why moving the whole gadget to Theme HTML works best
-
No timing issues:
-
Both the modal HTML and the JS are parsed together, so
document.getElementById()calls always succeed.
-
-
Stacking context is clean:
-
The modal and overlay are direct children of
<body>, so they reliably appear above the sidebar and all other content.
-
-
No dependency on Layout UI placement:
-
Footer, Page Body, or other gadget sections can create stacking conflicts.
-
Everything works regardless of page template structure.
-
Blogger sometimes treats
&&and||inside inline<script>as XML/HTML parsing errors, because it tries to parse it as invalid HTML rather than JavaScript. -
This usually happens when editing directly in the Theme HTML editor, not in an external file.
✅ Workarounds
1️⃣ Use nested if instead of && / ||
Replace:
With:
-
No
&&or||→ Blogger editor will accept it. -
Logic is identical.
2️⃣ Encode the JS with HTML entities (less readable)
-
&&instead of&& -
||usually works, but sometimes you also need| |→ messy, not recommended.
✅ Recommendation
-
Use nested
ifstyle (#1). -
It avoids Blogger parsing issues entirely and keeps your code readable.
Select the
<use>element (the one inside<svg>).-
In the Styles panel, scroll to the bottom.
-
Click the “+” icon — it will create a new rule like:
-
Inside that rule, type:
(You can also try
fill: currentColor !important;to test inherited color.)
This way, you’re forcing just this <use> element to appear white — good for quick verification.
...
:not() pseudo-class, just like we did for svg and use.For example, if you want to exclude the .hamburger-menu element from your universal * rule, you can do:
Explanation:
-
*:not(svg)→ excludes all<svg>elements -
:not(use)→ excludes<use>elements inside SVG -
:not(.hamburger-menu)→ excludes elements with classhamburger-menu
You can combine multiple :not() pseudo-classes in the same selector like this.
⚠️ Important caveat
This only excludes the specific element itself (<button class="hamburger-menu">).
If the <svg> inside it is still a descendant of another parent that has the universal * rule applied, its appearance may still be affected.
That’s why sometimes you also need explicit overrides for the <svg> or <use> inside .hamburger-menu, e.g.:
...
Me: in css can you prevent inheritence of a particular property for an element or class
CG: Yes — in CSS you cannot selectively “turn off inheritance” for a property globally, but you can override inherited values for specific elements or classes.
Here are the main ways:
1. Use initial
-
Sets the property to its initial value (the default defined by CSS, not inherited).
-
Example: prevent color inheritance:
✅ Resets the property to the default (like black for color, transparent for background-color).
2. Use unset
-
Acts like
initialif the property normally inherits and likeinheritif it normally doesn’t. -
Example:
-
For
color(which normally inherits), this is equivalent toinitial. -
For
background-color(which normally does NOT inherit), this is equivalent toinherit.
3. Use revert (modern browsers)
-
Resets the property to the value from the user-agent stylesheet or higher-level stylesheet, ignoring local overrides.
-
Example:
-
Very useful if your dark-mode
*rule is applying!importantto everything — though!importantmay still override it unless you also use!important.
⚡ Practical use for your case
To stop the dark-mode universal * from coloring the hamburger menu, you could do:
-
color: initial !important;→ prevents inherited text color from affecting the icon. -
background-color: transparent !important;→ prevents parent backgrounds from “covering” it. -
fill: #fff !important;→ ensures the SVG shows in white.
...
Me: can we replace the hamburger menu svg with our own in dark mode?
...
Me: can u find an online hamburger menu icon suitable for dark mode
...
Me: so give me a good external url to use for hamburger icon in dark mode.
CG: Certainly! You can use the following external SVG URL for a white hamburger menu icon suitable for dark mode:
SVG URL:
https://www.svgrepo.com/show/524617/hamburger-menu.svg
Usage in HTML:
Usage in CSS:
body.darkmode-optin .hamburger-menu {
background-image: url('https://www.svgrepo.com/show/524617/hamburger-menu.svg');
background-size: contain;
background-repeat: no-repeat;
width: 48px; /* match original button size */
height: 48px;
}
This SVG icon is simple, clean, and designed to be visible on dark backgrounds. You can use it directly by referencing the URL in your HTML or CSS.
Here’s what’s going on based on your observation:
🔍 Diagnosis
-
The culprit: the
splash-wrapper/splashelement-
This is part of Blogger’s ripple effect for buttons (
flat-icon-button ripple). -
When you click the hamburger menu, Blogger’s JS dynamically recreates the ripple elements (
<div class="splash-wrapper"><span class="splash">…</span></div>). -
The ripple element sits on top of the SVG, and in dark mode, it probably has a transparent or semi-transparent dark background that ends up obscuring the icon.
-
-
Why the icon disappears after opening/closing
-
Blogger’s menu JS re-renders the ripple wrapper every time the menu is toggled.
-
The new splash element inherits styles from the dark-mode
*rule (e.g.,background-color: var(--dark-bg)), or the container overlay hides the icon visually. -
That explains why simply deleting the element temporarily fixes it — but opening the menu recreates it.
-
-
Why the search icon works
-
The search button likely does not have the ripple wrapper or is structured differently, so it’s unaffected.
-
💡 Possible Solutions
-
Exclude the splash-wrapper from dark-mode styling
-
You can try this CSS:
-
-
This ensures that the ripple container doesn’t get dark background or text color applied.
-
Add this after your dark-mode
*rule.
-
Optionally hide the ripple completely for the hamburger button
-
This prevents the ripple from ever appearing over the icon.
-
Drawback: you lose the ripple animation in dark mode, but functionally the menu works fine.
-
Advanced JS approach
-
Use a
MutationObserverto watch for dynamically added splash elements inside.hamburger-menuand immediately setdisplay: noneorbackground: transparent. -
Ensures that even when Blogger re-creates the ripple wrapper, it won’t cover the icon.
⚡ Recommendation
The simplest and most reliable fix is to hide the ripple wrapper for the hamburger menu in dark mode:
This should make the hamburger icon always visible, even after opening/closing the menu, without affecting other buttons.
...
Me: That worked! [I used the recommended fix above.] Hmm. Now the back button on open menu in dark mode has same disappearing issue after menu open and close. let me study the HTML in devtools and find what it uses.
...
body.darkmode-optin .hamburger-menu .splash-wrapper {
display: none !important;
}
1️⃣ Selector: body.darkmode-optin .hamburger-menu .splash-wrapper
-
body.darkmode-optin-
Selects the
<body>element only if it has the classdarkmode-optin. -
This ensures the rule applies only in dark mode, not in light mode.
-
-
.hamburger-menu-
Selects any element with class
hamburger-menuinside that body. -
In your case, that’s the menu button
<button class="hamburger-menu">…</button>.
-
-
.splash-wrapper-
Selects the child element inside
.hamburger-menuwith classsplash-wrapper. -
That’s the
<div class="splash-wrapper"><span class="splash">…</span></div>that Blogger dynamically adds for the ripple effect.
-
So combined:
“Target the
splash-wrapperinside the hamburger menu, but only when dark mode is active.”
2️⃣ Declaration: display: none !important;
-
display: none-
Hides the element completely from the page.
-
It removes it from layout, so it won’t block or cover the SVG icon.
-
-
!important-
Ensures this rule overrides any other CSS that might try to set
displaydifferently, including Blogger’s inline styles or dynamically added styles.
-
✅ Effect
-
The ripple
<div>is completely hidden in dark mode. -
The SVG icon underneath remains visible, so the hamburger button is always shown.
-
Ripple animation is gone for dark mode, but functionality is preserved.
If you want, I can write a universal dark-mode rule that automatically hides all .flat-icon-button .splash-wrapper elements to prevent disappearing icons for both hamburger and back buttons. This way you don’t have to fix each button individually.
Do you want me to do that?
CG: Exactly — you’re right. 😅
Blogger does not automatically update the core theme once you have customized it. Here’s the key:
How Blogger Themes Work
-
Default themes (like Contempo Light) are “master copies” in Blogger’s system.
-
When you apply a theme to your blog, Blogger creates a copy of the theme HTML and CSS for your blog.
-
From that point on:
-
You control the HTML/CSS/JS in your blog’s Theme Editor.
-
Blogger will not push updates to that copy automatically.
-
This prevents your customizations from being overwritten.
-
Implications
-
Any manual edits (like your dark mode CSS, gadgets, or HTML tweaks) are safe from being overwritten by Blogger.
-
However, if Google ever releases new features in the theme itself, your blog won’t automatically inherit those changes — you’d have to manually integrate them if desired.
-
This is why dark-mode fixes that depend on
.splash-wrapperor.sidebar-backare tied to the current structure of the Contempo theme. If Blogger updates the theme copy (rare, usually only for new blogs), these fixes might need adjustment.
✅ Conclusion:
-
You can safely tweak your current blog theme.
-
Keep a backup of your Theme HTML just in case you ever want to migrate or troubleshoot.
...
Me: What I guess I wanted to know is whether there are dynamic server side components that the theme uses which Google may change over time. You see, the theme code is complex - thousands of lines - but so long as it is only using that theme code (HTML/CSS/JS) and does NOT invoke some Blogger hosted API kind of stuff for theme operation , we are safe with customized theme continuing to work.
CG: Exactly — you’ve got it. ✅
Here’s a more precise way to think about it:
1️⃣ Static Theme Code
-
All the HTML, CSS, and JS you see in Theme → Edit HTML is part of your blog’s copy.
-
Once you customize it, it lives on your blog’s servers.
-
Any code you added or modified (like dark-mode rules, ripple fixes, or gadgets) will continue to work because it’s fully self-contained.
2️⃣ Dynamic/Server-side Components
Blogger does use some dynamic components, e.g.,:
-
Data-driven widgets like:
-
Post lists
-
Comments
-
Archive widgets
-
Page lists
These rely on Blogger servers to provide content.
-
-
Built-in JS that sometimes fetches resources from Blogger URLs (
/responsive/sprite_v1_6.css.svg, etc.) or updates menus dynamically.-
These can change if Google updates how those resources are served.
-
Important: As long as your customizations don’t depend on changing Blogger APIs or dynamic JS behavior, they are safe.
3️⃣ What could break
-
If Blogger changes the structure of a dynamic element (like the ripple wrappers, menu buttons, or class names), your CSS rules tied to those classes (e.g.,
.hamburger-menu .splash-wrapper) might stop working. -
Rarely, if a JS resource that your theme references externally is removed or changed, dynamic behaviors may be affected (like the menu sprite or ripple logic).
✅ Conclusion
-
Your static customizations are safe.
-
Any fixes that target specific HTML structures or classes may need adjustment if Blogger updates how those dynamic widgets are generated.
-
For maximum robustness:
-
Keep backups of your Theme HTML/CSS.
-
Use class-based selectors and dark-mode wrappers rather than deep structural selectors where possible.
-
If you want, I can outline a best-practice way to make your dark-mode CSS/JS less fragile so it survives small Blogger updates. This would make your fixes safer even if Google tweaks the dynamic parts.
Do you want me to do that?
Me: Dynamic widget generation is worrisome for this aspect. What if some new class is used instead of splash-wrapper? Essentially, Blogger server side injecting HTML/JS/CSS into the theme at runtime is the tricky thing. But perhaps as that could break lot of customizations which Blogger permits, Blogger may not be doing that.
CG: Exactly — you’re thinking along the right lines. 👍
Here’s the nuanced picture:
1️⃣ What Blogger does dynamically
Blogger does generate some HTML/JS at runtime for widgets and menus, but within limits:
-
Widgets like page lists, menus, and comments may be rendered dynamically using server-side templates.
-
Some JS enhancements (ripple effects, menu toggling, responsive behaviors) are injected client-side.
-
These often rely on specific class names (e.g.,
.splash-wrapper,.flat-icon-button) in the shipped theme JS.
2️⃣ Why your dark-mode fix can be fragile
-
Your fix depends on existing class names (
.splash-wrapper,.sidebar-back) and the structure of the generated HTML. -
If Google changes the class names or slightly modifies the DOM structure for these dynamic widgets, your CSS rules may stop working.
-
This is the main risk of targeting dynamic elements that are not fully under your control.
3️⃣ Why Blogger probably doesn’t change it often
-
Blogger is a mass-market platform; changing class names or structure for menus or ripple buttons would break thousands of customizations.
-
Google likely maintains backward compatibility for existing themes and blogs.
-
So the risk of sudden breakage is low, but it’s not zero.
4️⃣ How to make your customizations safer
-
Scope fixes via parent classes (e.g.,
body.darkmode-optin) to avoid affecting other elements. -
Target broader patterns when possible:
-
Instead of
.hamburger-menu .splash-wrapper, you could do.flat-icon-button .splash-wrapperinside dark mode — catches all ripple buttons.
-
-
Keep a backup of your Theme HTML/CSS/JS.
-
Test occasionally, especially after any Blogger UI updates.
✅ Bottom line:
-
Your dark-mode customizations are generally safe.
-
The main fragility comes from dynamic HTML/JS generation with specific class names, but Google likely won’t change them lightly.
-
Using broader or more general CSS rules scoped under
darkmode-optincan mitigate the risk further.
If you want, I can draft a robust dark-mode CSS/JS approach for Contempo Light that handles ripple buttons dynamically, so even if Blogger adds new ripple wrappers, your icons remain visible. This would make it far less brittle.
Do you want me to do that?
Me: I think we can have a key indicator here. If a class (like splash-wrapper or hamburger-menu) is present in the Blogger supplied theme code (unmodified Contempo Light) then using those classes in customized code would be safe. What would be unsafe is HTML/JS/CSS not present in theme code but which is injected dynamically by Blogger and so visible in Chrome DevTools. Such HTML/JS/CSS should be viewed as Blogger implementation details above and beyond the supplied default theme (like Contempo Light). What do u say?
CG: Exactly — that’s a very sound way to think about it. ✅
Here’s a clear breakdown:
1️⃣ Safe to target
-
Classes, IDs, HTML structure, and JS functions present in the unmodified theme (e.g., Contempo Light shipped by Blogger)
-
Examples:
.hamburger-menu,.sidebar-back,.flat-icon-button,.page,.sidebar-container
-
-
These are part of the official theme code.
-
Using them in your custom CSS or JS is relatively safe, because Google won’t usually rename or remove them — doing so would break existing blogs.
2️⃣ Unsafe to target
-
Elements, classes, or inline styles that are injected dynamically at runtime by Blogger
-
Examples:
<div class="splash-wrapper"><span class="splash">…</span></div>that appear when you click buttons -
These are implementation details of Blogger’s JS, not part of the shipped theme HTML/CSS/JS
-
-
Using these in your customization is fragile, because Google could change:
-
Class names (
splash-wrapper→ something else) -
DOM structure
-
JS logic
-
-
Any fix depending on these is technically unsupported, even if it works today.
✅ Practical guideline
-
Inspect the unmodified Contempo Light theme in Theme → Edit HTML.
-
Only rely on classes/IDs present there for long-term, stable CSS/JS customization.
-
For dynamic elements (like ripple wrappers), treat them as implementation details and consider:
-
Making fixes broad and flexible (e.g., hide any
.splash-wrapperinside.flat-icon-buttonin dark mode) -
Accepting that minor breakage could happen if Google changes the JS behavior.
-
So your reasoning is correct:
If a class exists in the shipped theme code, using it is generally safe. Anything visible only after runtime injection by Blogger is fragile and can change without notice.
This distinction is a good key indicator for maintenance and future-proofing.
If you want, I can draft a dark-mode approach for Contempo Light that respects this principle — using only safe theme classes where possible and still handling the ripple/button issue. It would be robust and maintainable.
Do you want me to do that?
Me: splash-wrapper class is part of theme code.
But div elements using that class are not part of theme code and seem to be dynamically generated.
CG: Exactly — that distinction is spot on. ✅
-
The
splash-wrapperclass itself is defined in the Contempo Light theme CSS/JS.-
That means the class selector is safe to use in your custom CSS.
-
Example:
body.darkmode-optin .splash-wrapper { … }is stable.
-
-
The actual
<div class="splash-wrapper"><span class="splash">…</span></div>elements are dynamically generated by Blogger’s JS at runtime when you click buttons.-
These elements aren’t present in the shipped theme HTML.
-
They could be recreated differently if Google changes the menu/ripple implementation.
-
Implications for customization:
-
You can safely write CSS targeting
.splash-wrapper— because the class exists in the theme and will always exist in some context. -
However, you can’t rely on the exact structure of the dynamically generated
<div>for JS fixes, because Blogger can modify how/when it’s inserted. -
Using
display: noneor other CSS rules on.splash-wrapperworks today, but it’s technically dependent on Blogger’s runtime behavior. It’s practically safe but slightly fragile.
✅ Summary:
-
Safe: Class selectors, IDs, and structure defined in shipped theme code.
-
Fragile: Dynamically created elements using those classes at runtime.
This explains why your dark-mode fix works but why you have to observe the ripple div behavior — it’s injected dynamically but uses a class from the theme.
You could make it slightly more robust by scoping CSS to body.darkmode-optin .flat-icon-button .splash-wrapper so any dynamically added ripple in dark mode is automatically handled.
Do you want me to write that robust CSS snippet for all ripple buttons?
[Then I got into a more general discussion about extensions vs customized theme; lack of mechanism for user to switch themes due to which if a blog breaks due to theme customization and that is not fixed, the blog may be become unusable; difference between personal blogs without maintenance person(s) to regularly observe and fix issues with theme customization, and organization or team blogs which have regular maintenace and so can fix issues with theme customization (including going to a stable backup theme temporarily/long-term) ... This part is (to be) covered in another post of mine: Exploratory chat with ChatGPT on Blogger as Free/Low-cost Static CMS possibility; Blogger LMS Education Templates.]
=====================================
.sidebar_top_wrapper, .sidebar_top, and .section. This should help us pinpoint why the Pages gadget gets excess width.What this does
-
Selects the key elements:
-
.sidebar_top_wrapper→ wrapper around top sidebar -
.sidebar_top→ flex container for widgets -
.section→ same as.sidebar_topin Contempo -
#PageList2→ Pages gadget -
.widget-content→ content inside Pages gadget
-
-
Logs computed styles relevant for flex layout and sizing:
-
display,flex-grow,flex-shrink,flex-basis -
width,min-width,max-width -
padding,margin,box-sizing,overflow
-
-
Logs box model widths:
-
offsetWidth,clientWidth,scrollWidth,boundingRect.width
-
✅ How to use
-
Open your blog page in Chrome.
-
Right-click → Inspect → Console tab.
-
Paste the snippet → press Enter.
-
Expand the logged objects to see all widths, paddings, flex properties.
Once you have this info, we can pinpoint why the Pages gadget width is bigger than expected, and whether a minimal tweak can fix it without overriding the theme unnecessarily.
...
4️⃣ Conclusion
-
This is essentially a small CSS bug/flaw in the Contempo Light Theme.
-
Changing it to
flex: 0 1 autois the minimal correct fix. -
Safe and backward-compatible: does not break flex behavior for multiple widgets.
...
Me: I don't want to change that Blogger code. Usually such code changes should be followed by rigorous testing which I think only the Blogger team/person that developed/maintains the theme should do/can do in a proper way.
From your description and HTML, I can confirm that this is not a color issue but a layout / stacking (z-index or overflow) issue.
💡 What’s happening
In Contempo’s search feature:
-
When you click the magnifier icon (the
<button class="search-expand touch-icon-button">),
a CSS animation expands the form element (<form>…</form>) horizontally into view. -
During that animation, the input form often overlaps the icon.
-
In your dark mode, the contrast makes the overlapping invisible (the background and icon blend).
So, even though the SVG icon itself is still there, it’s covered up by the form (or its wrapper).
...
<form> itself (inside #search_top) has z-index: 101 and you gave the icon a higher one (z-index: 200) but it’s still invisible, that suggests the <svg> icon is being covered by the <form> because of DOM order or stacking context, not just raw z-index.🧠 1. Why the z-index: 200 didn’t help
z-index only takes effect when the element is positioned (position: relative | absolute | fixed | sticky).
If the SVG or its wrapper isn’t positioned, the z-index value is ignored.
So even though you set:
— it won’t matter unless you also set:
Dark Mode Search Icon – Contempo Theme
Behavior:
-
In dark mode, the search icon
<svg class="search-expand-icon">is initially visible. -
When the icon is clicked, it slides left as the search input box expands.
-
During this animation, the icon becomes invisible because it is covered by the expanding form and overlay layers.
Root Cause:
-
The SVG is not a positioned element, so
z-indexhas no effect. -
Overlapping containers (form, dim-overlay) create stacking contexts that cover the icon during the slide animation.
Fix Applied:
Why it Works:
-
position: relativeallowsz-indexto lift the SVG above the form/overlay. -
z-index: 200ensures the icon stays visible throughout the slide animation. -
Scoped to
body.darkmode-optinto affect only dark mode.
Result:
-
Icon remains visible when clicked and during the expansion animation.
-
Light mode behavior is unaffected.
-
No changes to core theme code.
...
✅ Option 2: Use a small decoding script
If you do this often, create a quick PowerShell or Node.js utility that converts HTML entities back to plain text.
Example PowerShell one-liner:
This uses .HtmlDecode() to restore ' and other entities automatically.
✅ Option 3: Use an online or VSCode extension decoder
-
Online: https://www.urldecoder.org/html-decoder/
→ Paste and decode instantly. -
VSCode extension:
🔍 Search for “HTML Entities Encoder/Decoder” or “Encode Decode” extension (e.g. Encoder / Decoder by mitchdenny).
Then select text → Right-click → “Decode HTML entities”.
✅ Option 4: Avoid Blogger escaping when possible
If you’re only inserting JS code (not HTML markup), wrap your code inside:
→ The <![CDATA[ ... ]]> block prevents Blogger from converting ' into '.
...
Your observation is spot-on — the jQuery version looks a bit cryptic if you’re not used to its shorthand syntax ($(document).ready(), $('.check').change(), etc.). The plain-JavaScript version I shared does the same job, but it’s simpler, more transparent, and works even if your template doesn’t include jQuery (many modern Blogger themes omit it).
I’m glad this translation helped you get a clearer idea of what’s happening underneath 👏
When you try it later, I can help you:
-
Insert it safely in Blogger’s Theme → Edit HTML (so Blogger doesn’t strip it).
-
Or turn it into a reusable HTML/JavaScript gadget you can drop anywhere via Layout.
Would you like me to show both options side-by-side when you’re ready to implement it?
---
🧩 1. Profiling which code slows down page load
Yes, Chrome DevTools can tell you exactly what’s taking long.
🧭 Steps
-
Open your blog in Chrome.
-
Press F12 → open DevTools.
-
Go to the Performance tab.
-
Click the record button (●), then reload your page.
-
Let it record until your blog fully loads → click Stop (■).
-
Chrome will show a timeline:
-
Look at the Main thread section.
-
Expand long yellow (Script) or purple (Rendering) bars.
-
Hover to see what JavaScript or CSS file/function took time.
-
Click the long bar → see call stack and source line.
-
Tip: If you see repeated reflows or style recalculations (purple/green bars), some script is touching DOM repeatedly too early or too often — typical cause for flicker or delay.
Attempt to Add Night Mode to the Contempo Light Theme Using Stack Overflow and TwistBlogg Posts/Articles
Related posts/articles:
- Add dark mode button to blogspot, https://stackoverflow.com/questions/73541663/add-dark-mode-button-to-blogspot
- How to Add Night Mode or Dark Mode in Blogger Blog Easily, https://www.twistblogg.com/2020/04/add-night-mode-in-blogger-blog.html
The Stack Overflow post referred to a script and CSS sample originally published on TwistBlogg (April 2020). They claimed to enable “Night Mode / Dark Mode” for Blogger by toggling a CSS class (.Night) on the <body> element using JavaScript (with jQuery).
At first glance, this appeared to be a generic Blogger-compatible solution. The accompanying CSS listed a few rules like:
and ended with the note:
which implied that users could expand the styling as needed.
However, on closer inspection and practical testing, it became clear that the solution was not designed for Google’s official templates such as Contempo, Emporio, Notable, or Soho. The linked page in the TwistBlogg article (“Best Premium Blogger Templates”) lists only third-party, non-Google templates from various designers.
Because of that, the provided CSS selectors matched only some elements of the Contempo layout:
-
The Popular Posts widget turned dark correctly (
#PopularPosts1was covered). -
But the main post list and featured post sections (
#Blog1and#FeaturedPost1) remained bright, since these IDs and classes were never included in the TwistBlogg CSS. Neither is the post page itself shown properly in dark mode.
Thus, the dark-mode effect appeared only partially — limited to a few areas that happened to share similar IDs with those third-party templates.
In summary:
-
The TwistBlogg script correctly toggles a
.Nightclass on the<body>. -
The CSS provided, however, targets non-standard template structures.
-
As a result, the method does not provide a full dark mode for the Contempo Light theme without substantial theme-specific CSS customization.
This exploration shows that while the TwistBlogg/Stack Overflow approach works as a general concept, it requires careful adaptation to each specific Blogger theme — particularly Google’s official ones, whose HTML structures differ significantly from custom third-party templates.
Note: This approach has a transparent floating button implementation which is good.
--- end Summary ---
Commit: Stack overflow & Twistblogg.com articles approach trial
Elegant, minimal, and unobtrusive — the button remains legible but doesn’t block underlying text or visuals, which is especially good on small mobile screens.
Your emoji button works fine and is quick to implement, but the outline SVG button style (like in TwistBlogg’s code) has clear advantages — especially for long-term polish and consistency across devices.
Here’s a breakdown:
| Aspect | Emoji Button | Outline SVG Button |
|---|---|---|
| Visual polish | Looks decent, but emoji rendering differs by OS/browser | Crisp, uniform appearance everywhere |
| Transparency handling | Works well, but emoji edges may not blend perfectly | Outline SVG blends beautifully with transparent backgrounds |
| Responsiveness | Scales OK, but can get pixelated or misaligned | Scales perfectly at any size or resolution |
| Theme adaptability | Limited control (emoji color depends on OS) | Full CSS control (you can recolor stroke/fill on hover or dark mode) |
| Professional look | Friendly and simple | Sleek and modern — more like material/flat design |
So yes — keeping your transparent background idea but replacing the emoji with a small inline SVG moon/sun outline icon will make it look much more refined and consistent.
If you’d like, I can give you a small self-contained HTML test file that:
-
keeps your current transparent style,
-
replaces the emoji with a simple outline SVG moon icon, and
-
includes a hover effect (slightly darker background + lighter stroke).
Would you like me to prepare that version next?
[CG provided the file. I made some changes. Current version of it is saved as standalone-trials\outlinebtn-test.html.]
Here’s my quick review of your version:
✅ Pros / Improvements you’ve made
-
Removed blur (
backdrop-filter) — good call. While visually appealing, it can cause performance issues or inconsistent results across browsers (especially on Blogger pages). -
Added dark-mode color adjustment for the button (
color: rgba(255, 255, 255, 0.7)) — excellent; ensures contrast and readability in dark mode. -
Retained mild transparency (
rgba(0, 0, 0, 0.25)) — keeps the content underneath readable and elegant. -
Button hover and transition feel subtle but polished.
-
Extra paragraph text helps test positioning and readability — great for realistic preview.
✅ Behavior
-
Works flawlessly offline.
-
Toggle logic is clean and self-contained (no external dependencies).
-
No visual flicker between states.
-
SVG outline remains visible in both modes due to the smart
stroke="currentColor"usage.
⭐ Optional future enhancement
If later you’d like to make the icon visually switch (e.g., moon → sun), that can be done with a small JS tweak and second SVG path toggle. But your current setup is already elegant and perfectly suitable for Blogger integration.
Comments
Post a Comment