Various Styling Options

Ruben builds the editor surface for a corporate-blogging platform used by several hundred brands. Each brand has its own visual identity -- one is a navy/serif law firm, another is a pastel/sans-serif lifestyle company, another is a high-contrast/monospace engineering blog. The same writer might switch between three brand workspaces in a single afternoon, and the editor needs to feel like the brand's site every time.

His view model already knew which brand the writer was editing for. What he needed was an HTML editor whose document-level styling -- background, default font, body class, linked stylesheet -- could be driven entirely from that view model.

The WpfHtmlEditor turned out to give him exactly that. The styling surface is a small focused set of properties on the document body, not on the editor chrome, so what the writer sees inside the editor matches what the article will look like on the published site.

For body-level look and feel he had four levers:

BodyStyle -- raw inline style applied to the document's <body> (for example "margin:20px; line-height:1.6;").
BodyCSSClassName -- a class name on the <body> so rules from his stylesheet target it.
BodyColor -- background color of the document body (System.Windows.Media.Color).
BackgroundImagePath -- file or URL whose image becomes the body background.

For typography defaults there were three more:

DefaultFontFamily -- e.g. "Merriweather" for the law firm, "Inter" for the lifestyle brand.
DefaultFontSizeInPt -- pass with the "pt" suffix (for example "11pt"); without a unit the editor treats the number as pixels and converts.
DefaultForeColor -- default text color (System.Windows.Media.Color).

The piece that made Ruben's scenario actually work was DocumentCSSFilePath. Each brand workspace already had a published brand.css file. Point the editor at it, and the editor injects a matching <link rel="stylesheet"> into the document head -- so the writer sees the exact rendering the readers will see.

editor.DocumentCSSFilePath = $@"C:\BrandCache\{brandId}\brand.css";

For brand-specific tweaks that didn't belong in the published stylesheet (an extra heading override the editor needed for design-time legibility), he used the inline-stylesheet pair. HeaderStyleContentElementID names the <style> block; HeaderStyleContent sets its body. The ID lets him replace the block later without leaving stale style declarations behind:

editor.HeaderStyleContentElementID = "ruben-overrides";

editor.HeaderStyleContent          = "p { line-height: 1.7; } h1 { color: #003366; }";

Because every one of those properties is a real WPF dependency property, Ruben wired the whole thing up declaratively. When the writer switches brand workspaces, the view model raises one PropertyChanged volley and the editor reflows itself:

<wpf:WpfHtmlEditor x:Name="editor"

                   BodyStyle="{Binding DocBodyStyle}"

                   BodyCSSClassName="{Binding DocBodyClass}"

                   DocumentCSSFilePath="{Binding DocCssPath}"

                   DefaultFontFamily="{Binding DocFontFamily}"

                   DefaultFontSizeInPt="{Binding DocFontSize}"

                   DefaultForeColor="{Binding DocForeColor}"

                   BodyColor="{Binding DocBodyColor}"

                   BackgroundImagePath="{Binding DocBackgroundPath}" />

For one-off setups where binding was overkill -- a preview pane that always renders the firm's default style -- he set the same properties imperatively from the code-behind:

using System.Windows.Media;



private void Window_Loaded(object sender, RoutedEventArgs e)

{

    editor.DefaultFontFamily   = "Merriweather";

    editor.DefaultFontSizeInPt = "11pt";

    editor.DefaultForeColor    = Color.FromRgb(0x22, 0x22, 0x22);

    editor.BodyColor           = Colors.WhiteSmoke;

    editor.BodyStyle           = "padding:24px; line-height:1.6;";

}

The writers stopped asking him "is this how it'll actually look?" within the first sprint. The editor was finally honest about what the published article would be.