Since the last platform update (v3.7.1), our email campaign workflow has been critically degraded. The updated WYSIWYG composer is aggressively stripping inline and embedded CSS upon switching from the "Source" view back to the visual editor, rendering our meticulously crafted transactional email templates unusable. This is not a minor formatting quirk; it's a systemic issue that breaks functionality.
Our team relies on a standardized template system for consistency across password resets, order confirmations, and system alerts. The previous composer handled this without issue. Post-update, we've documented a reproducible pattern of CSS removal that targets specific properties crucial for client compatibility (e.g., Outlook).
**Observed Behavior & Data Loss Pattern:**
1. Paste or write valid HTML with inline CSS into the "Source" code view.
2. Switch to the visual "Design" view. The preview renders correctly.
3. Switch back to "Source" view. The CSS properties have been partially or completely removed.
**Example of the Corruption:**
Original code block pasted into Source:
```html
Your order is confirmed.
```
After toggling to Design and back to Source, it becomes:
```html
Your order is confirmed.
```
Note the removal of `background-color`, `border`, `font-family`, `color`, and `line-height`. The process appears to use a overly aggressive sanitization library that misidentifies these standard CSS properties as invalid or unsafe.
**Immediate Workflow Impact:**
* **Time Cost:** Each email now requires a manual save of source code to an external file before any preview, and re-pasting if edits are needed.
* **Risk:** High potential for sending broken, unstyled emails if a team member forgets the strict "no toggle" rule.
* **Testing Blocked:** A/B testing of new templates is halted, as we cannot trust the composer to preserve our changes.
Has anyone else in the community conducted a technical deep-dive on this regression? I'm particularly interested in:
* Whether you've identified a pattern in which CSS properties are targeted (is it all `background-*` rules, certain selectors, etc.?).
* Any workarounds beyond the "never switch views" directive, which is fragile.
* If you've traced the issue to a specific new dependency or sanitization tool (like HTMLPurifier or a similar library) introduced in the update.
Our current hypothesis is that the new composer is either invoking a different sanitation routine with an overly restrictive allowed-CSS property list or is attempting to "normalize" styles for a mobile view but failing to reinstate them upon serialization back to source. Logs from our end show no server-side filtering, pointing squarely to the client-side editor.