fix: remove logic modifying inbound email CSS for padding.

[maxhaomh]

Summary

The logic of modifying email CSS based on unreliable heuristics can break HTML styling and rendering in unpredictable ways. Injecting Body Padding into the email itself, based on the presence of <style>, is unreliable, as many edge cases have not been accounted for, as seen in #433 with Outlook Web App. Beyond Outlook, there are certain marketing emails that may ship with a <style> tag but lack proper gutter/padding—in general, there are too many edge cases to make this method reliable.

This PR removes the CSS modifications (besides dark mode) and adds padding to the JSX wrapper itself. Email messages are rendered as is.

Changes

• Removed all heuristic-based CSS injection logic: isWordHtml, hasOwnLayout, bodyPadding, mobileBodyPaddingX, wordHtmlCSS. The email should handle mobile responsiveness itself.
• Stripped injected <style> block: (font-family, font-size, line-height, color, background, word-wrap, overflow-wrap, conditional padding/mobile media query). Removed ${wordHtmlCSS} interpolation.
• Moved padding from injected CSS to the JSX wrapper itself

Related Issues

Closes #433

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactor / code quality improvement
• Chore / dependency update / CI change

Checklist

• I have read the Contributing Guide
• My code follows the project's code style and conventions
• I have run npm run typecheck && npm run lint and there are no errors
• The build passes (npm run build)
• I have tested my changes locally
• I have added or updated documentation if needed
• I have updated translations (locales/) if my changes affect user-facing text
• I have included screenshots or a screen recording for UI changes

Screenshots / Demo

Notes for Reviewers

I'm not sure what the original intention behind handling the UI padding this way was, but in practice, it is rather unpredictable and an infinite game of chicken and egg. There are too many edge cases to reliably modify the CSS to ensure it renders correctly in our UI. In general, we should keep the email styling as close to the original as possible, and we just provide a canvas for it to be rendered in.

[rathlinus]

maybe making this a setting but completely removing is not a option

[maxhaomh]

Mind explaining what the original design decisions behind the css modification logic? Maybe there is something I am missing. But blindingly assuming all emails with <style> tags have handled padding is what creates these rendering issues. Just like an inline comment suggested “word/outlook Emails ship a <style>….”. AFAIK This fix only applies to the desktop classic version of outlook, and not OWA. But besides that, there are infinite possibilities of emails being sent with weird <style> tags that won’t play nice with this mechanism. Modifying how tables and it’s contents are displayed is what creates edge cases where email elements are not centered properly. Basically my intuition here says that we should avoid modifying email CSS. Ensuring an email renders correctly on mobile/etc is up to the sender to ensure… not us. We just provide a blank canvas.

…

On Fri, Jun 19, 2026 at 6:32 AM Linus Rath ***@***.***> wrote: *rathlinus* left a comment (bulwarkmail/webmail#438) <#438 (comment)> maybe making this a setting but completely removing is not a option — Reply to this email directly, view it on GitHub <#438?email_source=notifications&email_token=AOND4Y4BKMI7T7DT5FJTQJL5AUJCHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZVGA3TEOJWHE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4750729699>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOND4Y3KMF27O2MH5I34F535AUJCHAVCNFSNUABGKJSXA33TNF2G64TZHMYTCOBQG44DAMRVGI5US43TOVSTWNBWHEZDQOJZGMZDLILWAI> . You are receiving this because you authored the thread.Message ID: ***@***.***>