Semantic Rich Text Editor: My Hackathon Case Study
Most intranet content is text. SharePoint’s rich text editor treats it as a formatting issue, not a content-structure issue. Semantic Rich Text Editor changes that. Custom fonts in Brand Center were a first step, but typography is more than font files. It’s about hierarchy, spacing, and semantic meaning. So I built one.
Web Fonts
Brand fonts aren’t decoration. They’re recognition. The intranet is where employees spend hours every day. If it looks SharePoint-generic, you spend your hours on Microsoft’s intranet, rather than your intranet.
Web fonts predated SharePoint by three years and became a mainstream feature in 2010. SharePoint is only catching up now.
SharePoint loads fonts through a limited JavaScript font-loading API. The Semantic RTE application customizer fixes that. It loads brand center fonts the way font loading was always meant to work. Through CSS @font-face.
The result: faster load times, no flash of unstyled text, and access to features like variable fonts and font-display control that JavaScript font loading simply can’t offer. The correct way to treat fonts in 2026.
Editorial Styles
Branding does not end at having the correct font file loaded, either. It’s a set of rules for how text behaves: heading hierarchy, spacing, emphasis, rhythm.
Most intranets get the logo and colors right, then dump everything into a kitchen-sink toolbar that lets anyone override the style guide with a single click.
Semantic RTE takes the opposite approach. Three block types: headings, paragraphs, pull quotes. No font picker. No arbitrary size selector. Each block gets purpose-built controls. The typographic rules (type scale, font pairings, effects like drop caps or gradient clips) are configured by admins, not authors.
Authors write content. The system handles how it looks. Here’s how.
Editorial Style Configuration
The entire typography is managed through JSON configuration. Define the type scale, font pairings, and heading treatments once. Authors can’t break it.
Responsive/Fluid Typography handles the rest. The same content scales cleanly from mobile to a 4K display without a single media query.
Paragraphs includes drop-caps for the first letter of each paragraph.
Clean Content to SharePoint
SharePoint’s default editor dumps all content into a single rich text block. Headings, paragraphs, lists — one undifferentiated HTML blob. Semantic RTE separates content into individual, typed blocks. Each one carries its own semantic role, styling rules, and editing controls.
But structure is only half the problem. Content rarely starts in SharePoint. It starts in Word, Google Docs, email, and Markdown. Every paste brings invisible formatting baggage that breaks the editorial design.
Right: The same content but autocleaned up by the Semantic RTE paste.
Semantic RTE includes a paste sanitizer that strips all formatting while keeping the semantic structure. Paragraphs stay paragraphs. Lists stay lists. The styling mess stays out. SharePoint only offers cleanup after the mess is already on the page. Semantic RTE prevents it from getting there in the first place.
AI to SharePoint
Every AI tool outputs Markdown. Copilot, ChatGPT, Claude — all Markdown. Paste that into SharePoint’s default rich text editor, and you get raw syntax on the page, not formatted content.
Semantic RTE parses Markdown natively. Paste AI-generated content, and it arrives as structured, brand-compliant typography. No reformatting. No cleanup. The fastest path from AI output to published intranet content.
Accessible by Awareness
When it comes to accessibility, the conversation usually starts and ends with “check the contrast ratio.” That makes me cringe. Not because contrast doesn’t matter, but because the way we measure it is broken.
WCAG 2.x’s contrast formula was designed for CRT monitors. It doesn’t account for text weight or how humans actually perceive contrast on modern displays. It overstates the readability of light text on dark backgrounds, making it useless for dark mode. It treats thin 12px text the same as bold 24px. And it reduces everything to a binary pass/fail that tells you nothing about real-world readability.
Meeting the current standard is the floor, not the ceiling. If your accessibility effort stops at passing an automated check, you’re doing compliance, not accessibility.
Semantic RTE checks both. It runs the current WCAG 2.x contrast ratio alongside APCA. When an author selects a Brand Center color, both scores appear right in the editing toolbar. Not buried in a settings panel. Not hidden in an audit report or tool setting. Awareness at the moment of creation.
APCA is the candidate contrast method for WCAG 3.0, which is expected no earlier than 2028. By supporting both, Semantic RTE meets the legal baseline today while already preparing for what replaces it.
CSS Effects, Admin-Controlled
Drop caps, gradient-clipped headings, image fills, text shadows, outline type. None of this is new to CSS. All of it is missing from SharePoint’s editing experience. It even goes so far that predefined headline colors are not possible.
Semantic RTE includes a config-gated FX layer. Every effect is defined at the heading level in the configuration, not selected from a toolbar. Admins decide what’s available. Authors just write.
For Developers: Why No React
React solves a real problem: keeping UI in sync with state. But a rich text editor’s state lives in the DOM. The browser’s contenteditable state is the content’s editable state. Wrapping it in React means fighting the framework: intercepting renders, suppressing reconciliation, working around synthetic events that don’t match native selection behavior.
Every major React-based editor (Slate, Lexical, Draft.js) exists precisely because React and contenteditable are fundamentally at odds. They built an entire model layer to reconcile the two.
That’s thousands of lines of abstraction before you write a single feature.
Semantic RTE skips that layer entirely. Native DOM APIs handle selection, input, and mutation observation. CSS custom properties handle theming.
<dialog></dialog>handles modals.- The Popover API handles dropdowns.
- clamp() handles responsive typography.
- mix-blend-mode handles video text effects.
The result: a smaller bundle, fewer dependencies, faster rendering, and direct access to every browser capability, including ones React abstracts away. No virtual DOM diffing against an engine that already manages its own DOM. No framework version to keep current when SharePoint updates its toolchain.
The web platform in 2026 is not the web platform that made React necessary. For this particular problem, a constrained, config-driven editor inside SharePoint, HTML, CSS, and TypeScript are not just sufficient. They’re faster to build with, easier to debug, and produce less code.
Hackathon 2026 and Final Thoughts
Designers and developers should ask themselves: how can we make things better?
Having a rich text editor in SharePoint doesn’t mean we need the full capabilities of Word. Fewer options, applied well, make it easier for everyone.
One of my favorite books, The Laws of Simplicity by John Maeda, shaped how I approached this project. Maeda is currently CVP Engineering at Microsoft CoreAI Design & Research. Three principles in particular:
Reduce. The simplest way to achieve simplicity is through thoughtful reduction. Three block types instead of a kitchen-sink toolbar. No font picker. No arbitrary size selector.
Organize. Organization makes a system feel simpler than it is. Config-driven typography, semantic blocks, and admin-controlled effects turn complexity into structure.
Trust. When the system handles the complexity, users can trust the output. Authors write. The system handles how it looks.
I entered the SharePoint Hackathon to show what’s possible. There are still things to improve, but the foundation is solid: real typographic structure, proper font loading, editorial control, awareness of accessibility, and modern CSS effects. All in SharePoint. The web platform is enough.