CSS Shorthands in elements do not overrule definitions in <mj-attributes> if they are defined specifically (not as shorthand)

[ppdc]

Describe the bug
When defining an element's css properties in the section, there is a difference in the results, depending on whether the definitions are written as css shorthands or the attributes are defined explicitly.

To Reproduce
Steps to reproduce the behavior:
Compare these two tests:
1 Define section padding via css shorthand: https://mjml.io/try-it-live/5fM2CUrhn
2 Define section padding in four separate attributes: https://mjml.io/try-it-live/jUMYP1j5E

Expected behavior
Both examples should behave the same way. The section's definitions should overrule the one in <mj-attributes>

MJML environment (please complete the following information):

• OS: n/a
• MJML Version 4.xx

[iRyusa]

We don't really merge those as it's a bit complicated to explain who should take over the other.
The rule is pretty dumb : if you specify a padding-[direction] it will take over the padding shorthand. I know that it's not how it works in CSS, but it's the easiest way to handle that case.

Edit: To be clear, MJML attribute order doesn't have any impact on rendering.

[ppdc]

HI iRyusa, thanks for the quick reply.
I probably don't understand all the intricacies involved in making this work for email-code html and I assume your edit regarding the attribute order is linked to that problem: You would need to have an order rule implemented first, to be able to have logical override, correct?
Does the same principle apply to all attributes that can be written as shorthand?
At the very least I think it should be mentioned in the documentation (or maybe I didn't find it?) because it basically means that you have to decide whether you want to always use shorthands or never to use them because mixing them creates a spaghetti logic that will be hard to follow.
For example (how I discovered this) if you defined a padding-left & padding-right in mjml attributes but then use shorthand in an object, it will only override the properties that weren't defined in mjml attributes (top & bottom).

[iRyusa]

I believed we had something like that in the doc but I’ve found only how the inheritance works. We should add a specific warning about this behavior you’re right !As we can define the attribute multiple times and in multiple orders it’s far easier to have a common rule : if you define direction it takes over the shorthand as they’re 5 separate css attribute ( 1 shorthand + 4 direction )On 5 Mar 2026, at 13:13, ppdc ***@***.***> wrote:ppdc left a comment (mjmlio/mjml#3057) HI iRyusa, thanks for the quick reply. I probably don't understand all the intricacies involved in making this work for email-code html and I assume your edit regarding the attribute order is linked to that problem: You would need to have an order rule implemented first, to be able to have logical override, correct? Does the same principle apply to all attributes that can be written as shorthand? At the very least I think it should be mentioned in the documentation (or maybe I didn't find it?) because it basically means that you have to decide whether you want to always use shorthands or never to use them because mixing them creates a spaghetti logic that will be hard to follow. For example (how I discovered this) if you defined a padding-left & padding-right in mjml attributes but then use shorthand in an object, it will only override the properties that weren't defined in mjml attributes (top & bottom). —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[ppdc]

they’re 5 separate css attribute ( 1 shorthand + 4 direction )

Ah, okay, that explains why it's a problem, I didn't know that. Yes, a warning or best practice advice would help avoid confusion. Thanks.