I use the dark theme, and emails that ship their own dark background end up inside a thick white frame. Here's one of mine:
I went looking at the code and started trying fixes locally, but I stopped, because every version I came up with traded one case for another and none of them felt like a call I should be making on my own. So I'd rather ask what the intended behaviour is first.
Three things add up to the frame:
p-0 md:py-4 px-5 on the container — applications/mail/src/app/components/message/MessageBody.tsx:144padding-block-start: em(18), marked // design request — applications/mail/src/app/styles/_message.scss:396.dark-style { background: white; }, applied only in dark themes — applications/mail/src/app/styles/_message.scss:438, condition at MessageBody.tsx:145
I tried swapping the padding for margin, which does look better on my dark emails, but it's clearly wrong the other way round: a light email would sit on a dark page with a dark rim around it. Dropping dark-style removes the frame entirely, but that one is obviously load-bearing, since an email with hardcoded dark text and no background of its own would become unreadable on a dark surface. So the white background isn't an oversight, it's the safe default, and the padding is doing its job for most mail.
The way I see it there are three cases:
- Email with no background and dark text — needs a light surface, which is what happens today.
- Email with an explicit light background — today's behaviour is already right.
- Email with an explicit dark background — this is the one that looks broken.
Only the third is a problem, and telling it apart from the first requires knowing the email's effective background, which the container currently doesn't. I can think of a few directions — read the background out of the rendered content and match the container to it, let the iframe body colour reach the container edges, or keep the padding but paint it with the detected colour — but which one is acceptable seems like a design decision more than a code one, and I don't want to spend a PR guessing at something the design team would turn down.
So: is case 3 something you'd want handled, and if so is there a direction that fits the design guidelines? Happy to do the work if there's a shape you'd accept.
I use the dark theme, and emails that ship their own dark background end up inside a thick white frame. Here's one of mine:
I went looking at the code and started trying fixes locally, but I stopped, because every version I came up with traded one case for another and none of them felt like a call I should be making on my own. So I'd rather ask what the intended behaviour is first.
Three things add up to the frame:
p-0 md:py-4 px-5on the container —applications/mail/src/app/components/message/MessageBody.tsx:144padding-block-start: em(18), marked// design request—applications/mail/src/app/styles/_message.scss:396.dark-style { background: white; }, applied only in dark themes —applications/mail/src/app/styles/_message.scss:438, condition atMessageBody.tsx:145I tried swapping the padding for margin, which does look better on my dark emails, but it's clearly wrong the other way round: a light email would sit on a dark page with a dark rim around it. Dropping
dark-styleremoves the frame entirely, but that one is obviously load-bearing, since an email with hardcoded dark text and no background of its own would become unreadable on a dark surface. So the white background isn't an oversight, it's the safe default, and the padding is doing its job for most mail.The way I see it there are three cases:
Only the third is a problem, and telling it apart from the first requires knowing the email's effective background, which the container currently doesn't. I can think of a few directions — read the background out of the rendered content and match the container to it, let the iframe body colour reach the container edges, or keep the padding but paint it with the detected colour — but which one is acceptable seems like a design decision more than a code one, and I don't want to spend a PR guessing at something the design team would turn down.
So: is case 3 something you'd want handled, and if so is there a direction that fits the design guidelines? Happy to do the work if there's a shape you'd accept.