feat: add CSS inlining support for mj-style with inline attribute

[sciyoshi]

Description

This PR implements CSS inlining support for MJML templates with the 'inline' attribute on mj-style elements.

Changes

• Added support for the 'inline' attribute on mj-style elements
• Implemented CSS inlining using the css-inline crate (version 0.14.4)
• Modified the rendering process to differentiate between regular styles and inline styles
• Updated the header mechanism to store inline styles separately
• Added error handling for CSS inlining failures
• Added test cases to verify the CSS inlining functionality

How It Works

• When an mj-style element has the 'inline' attribute, its content is stored in the header's inline_styles collection
• During the final rendering process, the CSS inliner is applied to the HTML output only if there are inline styles
• Non-inlined styles are still preserved as regular style tags

Fixes #17

[jdrouet]

Several questions:

• As this been generated by an AI?
• Did you run a benchmark?

Moving forward:

• Could you put this behind a feature flag?

[codecov]

Codecov Report

❌ Patch coverage is 94.44444% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.84%. Comparing base (5311e58) to head (ce90fe1).
⚠️ Report is 157 commits behind head on main.

Files with missing lines	Patch %	Lines
packages/mrml-core/src/prelude/parser/output.rs	0.00%	4 Missing ⚠️
packages/mrml-core/src/mjml/render.rs	96.15%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #537      +/-   ##
==========================================
- Coverage   92.89%   92.84%   -0.06%     
==========================================
  Files         227      206      -21     
  Lines       12203    11357     -846     
==========================================
- Hits        11336    10544     -792     
+ Misses        867      813      -54     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jdrouet]

@sciyoshi for me to keep track of your changes before approving the workflows AND for my reviews to stay attached to your code, could you push new commits instead of push-forcing?
Thanks in advance

[sciyoshi]

Thanks @jdrouet, and my apologies, will do. Just attempting to fix the latest CI issues.

As for your questions: the first pass was mostly generated with Sonnet 3.7 Thinking, but I had to make a number of manual changes to get it working. I have not run any benchmarking yet on the new code.

It is possible to add a feature flag, but the behavior won't apply unless there's any inline styles in the input, so I wasn't sure if that was necessary.

[sciyoshi]

The only change from the original commit so far was to fix a clippy error and to add blocking as an option for reqwest to attempt to fix the current build failure.

[jdrouet]

The only change from the original commit so far was to fix a clippy error and to add blocking as an option for reqwest to attempt to fix the current build failure.

The means that css_inline uses reqwest inside. I think, instead, you should disable some features in css_inline 😉

[jdrouet]

Hey,
Sorry for the late reply and thanks for your changes.
Could you put the css_inline behind a feature flag disabled by default? It's not just for the performance but also for the binary size.

[sciyoshi]

@jdrouet sure, I added a css-inline feature which is disabled by default, as well as a warning that gets emitted if you try to use <mj-style inline="inline"> when the build doesn't have the feature enabled.

[kivra-mikgra]

We're really looking forward for this change let me know if I can help in any way!

[Stranger6667]

css-inline author here. If you need any adjustments from the crate side, don't hesitate to tag me :)

As performance was mentioned, I am wondering if it would be useful to have some CSS pre-compilation feature in css-inline? I.e., if you have all the CSS upfront, it could be useful to parse it just once and then apply inlining without re-parsing. Depending on the input, it could be a significant win (talking about ~20% in my benchmarks)

[QuentinFchx]

👋 Hi,
Gently bumping this PR, we are also very much interested in this feature! This is currently the only thing preventing us from migrating to mrml 🤞.

[jdrouet]

@sciyoshi could you resolve the conflicts so that we can trigger the tests?

[sciyoshi]

Done - also bumped css-inline to 0.18.0.

[jdrouet]

We are almost there, thanks for your changes!
Could you also sign your commits?

[jdrouet]

I have mixed feelings around enabling this by default. This will impact the performance by default 🤔
Although probably not when inline CSS is not used.
I'm interested to see some benchmarks.

[sciyoshi]

My thought here is that it should be enabled by default for the Python lib, because otherwise there's no way to enable it for a consumer without rebuilding this package, and the performance impact if you are not using inlining should be negligible.