Font family does not persist when typing after applying in Safari
OS: macOS 14.0 · Device: Desktop or Laptop Any · Browser: Safari 17.0 · Keyboard: US
Open case →Scenario
Changing font family in contenteditable elements behaves inconsistently across browsers. The font-family CSS property may be applied inline, as a style attribute, or may not be applied at all. The behavior also varies when editing text after applying a font.
Changing font family in contenteditable elements behaves inconsistently across browsers. The font-family CSS property may be applied inline, as a style attribute, or may not be applied at all. The behavior also varies when editing text after applying a font.
Implement custom font handling:
element.addEventListener('beforeinput', (e) => {
if (e.inputType === 'formatFontName') {
e.preventDefault();
const selection = window.getSelection();
if (selection.rangeCount === 0) return;
const range = selection.getRangeAt(0);
const fontName = e.data || prompt('Enter font name:');
if (fontName) {
// Apply font to selection
if (range.collapsed) {
// Set font for future typing
document.execCommand('fontName', false, fontName);
} else {
// Apply font to selected text
const span = document.createElement('span');
span.style.fontFamily = fontName;
try {
range.surroundContents(span);
} catch (e) {
// If surroundContents fails, extract and wrap
const contents = range.extractContents();
span.appendChild(contents);
range.insertNode(span);
}
}
}
}
});
Visual view of how this scenario connects to its concrete cases and environments. Nodes can be dragged and clicked.
Each row is a concrete case for this scenario, with a dedicated document and playground.
| Case | OS | Device | Browser | Keyboard | Status |
|---|---|---|---|---|---|
| ce-0106-font-family-persistence-safari | macOS 14.0 | Desktop or Laptop Any | Safari 17.0 | US | draft |
| ce-0135-font-family-empty-style | Windows 11 | Desktop or Laptop Any | Chrome 120.0 | US | draft |
| ce-0155-font-family-inheritance-issue | Windows 11 | Desktop or Laptop Any | Firefox 120.0 | US | draft |
This matrix shows which browser and OS combinations have documented cases for this scenario. Click on a cell to view the specific case.
| Browser | Windows | macOS |
|---|---|---|
| Chrome | — | |
| Firefox | — | |
| Safari | — |
Open a case to see the detailed description and its dedicated playground.
OS: macOS 14.0 · Device: Desktop or Laptop Any · Browser: Safari 17.0 · Keyboard: US
Open case →OS: Windows 11 · Device: Desktop or Laptop Any · Browser: Chrome 120.0 · Keyboard: US
Open case →OS: Windows 11 · Device: Desktop or Laptop Any · Browser: Firefox 120.0 · Keyboard: US
Open case →Other scenarios that share similar tags or category.
Changing font size in contenteditable elements behaves inconsistently across browsers. Font sizes may be applied as inline styles, as font tags, or may not persist when typing new text. The unit (px, em, rem) handling also varies.
Changing text color in contenteditable elements behaves inconsistently across browsers. Colors may be applied as inline styles, as font tags, or may not persist when typing. The color format (hex, rgb, named colors) handling also varies.
Changing background color (highlighting) in contenteditable elements behaves inconsistently across browsers. Background colors may be applied as inline styles, may not persist when typing, or may interfere with text selection. The behavior differs from text color changes.
Editing text within code blocks (<pre><code>) in contenteditable elements behaves inconsistently across browsers. Line breaks, indentation, whitespace preservation, and formatting may be handled differently, making it difficult to maintain code formatting.
The document.execCommand() API, which is commonly used to apply formatting (bold, italic, etc.) in contenteditable regions, has been deprecated. However, there is no complete replacement, and many implementations still rely on it. This creates uncertainty about future browser support.
Have questions, suggestions, or want to share your experience? Join the discussion below.