Modern HTML, CSS and JavaScript features (Known Issues)

A senior developer at a marketing-automation startup is evaluating the WinForms HTML Editor for the company's email-campaign authoring tool. He has read the docs, downloaded the trial, and built a one-form prototype. The first test campaign goes through clean -- toolbar, table, image, hyperlink, all the obvious stuff. Then he opens a campaign template a designer handed him: a modern responsive layout that leans on CSS Grid for the multi-column hero section. He pastes the markup into the editor's HTML source view and switches back to WYSIWYG.

The hero section collapses. The grid columns stack vertically as if the display:grid declaration were not there at all. He tries Flexbox in another test -- partial success, layout is close but not quite. He tries a CSS custom property (--brand-color) -- ignored. He files an issue: "does this editor support modern CSS?"

The honest answer, which this page is about, is "the WYSIWYG edit surface does not, and here is why -- plus what to do about it."

What is actually inside the edit surface

The WYSIWYG and Preview surfaces of the WinForms HTML Editor host the Windows Forms WebBrowser control, which is a thin wrapper around MSHTML -- the rendering engine that powered Internet Explorer through version 11. Microsoft put MSHTML into deep maintenance mode many years ago. New CSS features (Grid, modern Flexbox semantics, custom properties, container queries) and new JavaScript features (ES6+ syntax, classes, modules, fetch, async/await) have not been backported to MSHTML and never will be. On a stock Windows install, the WebBrowser control runs in IE7 emulation by default, which restricts the supported feature set further still.

That is the actual constraint, stated plainly. It is not a defect in the editor -- it is the rendering host the editor builds on.

Why MSHTML, still

The reason this matters less than it might sound is that MSHTML is the only Windows-bundled engine that exposes a full, programmable contenteditable surface with a deep COM-level DOM. IHTMLDocument2, IHTMLElement, the execCommand API, programmable selection and range objects, command targets, MSHTML editor designers -- that programmatic surface is what makes high-quality WYSIWYG authoring possible. Modern engines (Edge's Blink-based WebView2, Chromium directly) expose far less of that surface, far less directly. They are excellent renderers; they are not, out of the box, an authoring platform.

The product builds on MSHTML because that is the trade the platform gives. The result is an authoring experience that produces clean, well-formed HTML 4 / XHTML 1.0 with CSS 2.1 -- markup that renders identically in every modern browser, every modern email client, and every downstream pipeline, exactly because it does not depend on anything new.

The feature map -- what works, what does not

The browser-emulation lever

The WebBrowser control honors per-process registry keys under HKCU\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION. Setting the key for the host executable to value 11001 (decimal) pushes MSHTML to IE11 edge mode. That lifts some restrictions -- Flexbox starts to behave for most cases, ES5 strict mode becomes available, several CSS 3 properties light up. It does not lift the deeper limits: CSS Grid, ES6 syntax, and Web Components remain out of reach because MSHTML in IE11 mode is still MSHTML, not Edge.

For most teams, the IE11-emulation upgrade is worth doing -- it costs one registry entry shipped with the installer, and it widens the supported subset noticeably. Set the key once at install time for the host executable.

What to do when modern CSS really is the requirement

Three paths exist, and the right one depends on what the developer is actually trying to ship.

1. Use WebView2 alongside the editor for accurate preview. Microsoft Edge's Chromium-based WebView2 control supports the full modern web platform -- Grid, Flexbox, ES2022, the lot. It is not an authoring surface (no rich contenteditable command API), but it is excellent as a read-only "this is how the recipient will see it" preview pane sitting next to the WinForms editor. The marketing-automation startup ends up shipping exactly this: the salesperson authors in the editor, the WebView2 panel renders the same HTML through the live brand stylesheet, and the campaign looks the way the designer intended.
2. Evaluate the SpiceLogic WPF HTML Editor. The WPF edition is the same toolbar, same dialogs, same public API surface, but it is built on a fundamentally different rendering stack with broader CSS coverage. For teams whose primary requirement is modern-CSS authoring on Windows -- and who can choose between WinForms and WPF hosts -- the WPF SKU is the right starting point.
3. Split the render pipeline. Author the human-written parts (text, simple inline structure, the parts the user actually edits) in the WinForms editor; template in the modern-CSS fragments (the grid layout, the responsive hero) at output time on the server or in a renderer. The editor produces clean, predictable HTML 4, and the final page composes that markup into a modern shell. Common pattern for transactional-email and report-generation systems.

What the editor still does well

The constraint described here is on what the edit surface can render, not on what the audience can render. Markup authored in this editor lands cleanly in every modern browser, every modern email client, and every downstream rendering pipeline -- because the markup is the kind of HTML and CSS that has been universally supported for two decades. For documents, reports, knowledge-base articles, formatted notes, transactional email bodies, and the long tail of editable rich-text scenarios on Windows, the trade is the right one. For an authoring tool whose primary purpose is producing modern responsive web layouts, the alternatives above are the next step. SpiceLogic is happy to help work through which path fits a given product.