[jdrouet]

Content pulled in through mj-include renders differently from the same content written inline.

inc.mjml = <mj-column><mj-text>hi</mj-text></mj-column>
           <!-- a comment -->

via mj-include : mj-column-per-50
inlined        : mj-column-per-100

The include renderer forwarded only index and siblings to its children, so the comment was counted as a layout sibling and the column rendered at half width. It also never implemented set_container_width, so the width never reached the children at all — an <mj-image> inside an included fragment came out with no width attribute and no width on its wrapping <td>.

Both now match the inlined form: mj-column-per-100, and width="550" on the image.

raw_siblings is computed the way mj_section computes it for its own children — a count of raw children over the child list — rather than the way mj_raw does it. In mj_raw every child is raw so raw_siblings == siblings, but an included fragment holds a mix, and copying that would have been wrong.

Two regression tests comparing included against inlined output with html_compare::assert_similar, both confirmed failing before the change (expected .mj-column-per-100, got .mj-column-per-50; and the missing image width) and passing after. No golden fixture uses mj-include, so the full suite passing is also a clean check that non-include templates are untouched.

Tests 621 -> 623.

Follow-up, deliberately not in here: a section still treats an entire included fragment as one opaque non-raw child, so it emits a single Outlook conditional <td> around the whole include instead of one per column. Fixing that needs the section's child iteration to flatten includes, which is a bigger change than this one.

[github-actions]

📈 This is how your metrics evolved 📉