Skip to content

Email body: td, th { word-break: break-word } shatters table content into one character per row in CJK/RTL/long-string columns #341

Description

@shukiv

What I see

When opening an HTML email that contains a <table>, every <td>/<th> cell has its content broken character-by-character down the column. Hebrew column headers like מוצר / כמות / מחיר render as one glyph per line.

Why

A global stylesheet inside the bundled email-body chunk applies:

td, th { word-break: break-word; padding: 0.5rem; }

word-break: break-word (a non-standard alias for overflow-wrap: break-word, but in some engines treated as break-all) tells the layout engine that it MAY break a word at any character. Combined with narrow auto-laid-out table columns, the renderer happily lays out one glyph per row, breaking ordinary RTL Hebrew/Arabic content into vertical character ladders even when the word would fit if the column expanded.

Verified live by deleting the rule in DevTools — the same email renders correctly with all glyphs on one line.

Where

Found in the production bundle at:

/.next/static/chunks/0cltb1~1itxeh.js

(also present in /.next/static/chunks/0d_5j~v2g--nx.js and the SSR equivalents — likely a single source CSS block bundled into multiple chunks)

Expected

Either:

  1. Drop the global rule entirely (browsers already handle email-table wrapping fine; senders set their own widths).
  2. Or use overflow-wrap: anywhere instead of word-break: break-word — that only breaks when the word would actually overflow the column.
  3. Or scope the rule to a narrower selector (e.g. only .email-order-details td, .email-order-details th) so generic transactional tables aren't affected.

Steps to reproduce

  1. Open any transactional email that contains an order-summary table with mid-length text (Hebrew, Arabic, Chinese, or long English headers).
  2. Observe: every cell collapses to one glyph per line.
  3. DevTools → uncheck the word-break: break-word rule on td, th → email renders normally.

Environment

  • Bulwark Webmail 1.7.1 (self-hosted, latest tag)
  • Chrome 147 / Firefox 134, both reproduce
  • Stalwart 0.16.5 behind
  • Hebrew + LTR test mail (issue is not RTL-specific; CJK and long English strings reproduce too)

Screenshots attached in the linked PR/issue if useful.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions