Purpose and content model
Obsolete features remain visible in old source code because browsers preserve compatibility with historical documents. That does not make them suitable for new authoring. Migration should preserve the original intent while replacing outdated structure, styling, or behavior with a supported solution. A global search-and-replace can miss important differences.
For presentational markup, replace font and basefont with stylesheet rules, center with an appropriate CSS layout or text alignment, big with CSS font sizing, and tt with code, kbd, samp, or plain styled text according to meaning. Replace strike with s when information is no longer relevant, or del when recording an actual removal. Replace acronym with abbr and dir with a suitable list such as ul.
Frames and framesets should normally become ordinary pages with shared navigation and CSS layout. An iframe is appropriate only when a genuinely separate embedded document is needed, not as a blanket replacement for every old frame. Applet and plugin-dependent object configurations require a redesign using supported web capabilities rather than an instruction to install an obsolete plugin. Param is obsolete and should not be used to revive those configurations.
Replace marquee with static content by default; if motion is essential, provide user control and respect reduced-motion preferences. Replace nobr with carefully scoped CSS white-space when preventing wrapping is actually usable. Replace xmp, listing, and plaintext examples with escaped text inside pre/code. Old Shadow DOM content and shadow insertion points should be redesigned using current template, shadow-root, and slot mechanisms. Ruby examples should use current ruby/rt/rp structure rather than obsolete rb/rtc patterns.
Syntax and working example
<!-- Legacy source: <center><font color="green">Opening hours</font></center> -->
<p class="opening-hours">Opening hours</p>
<style>.opening-hours { text-align: center; color: #176b52; }</style>Supported attributes and behavior
Legacy presentational attributes such as align, bgcolor, cellpadding, and cellspacing should be evaluated alongside obsolete elements. The HTML Standard distinguishes obsolete-but-conforming legacy cases from nonconforming features; a validator warning and a validator error are not always the same category. Browser support is also separate: a feature may still render while remaining obsolete for authors.
Another practical pattern
<!-- Display source safely instead of using xmp. -->
<pre><code><button type="button">Save</button></code></pre>
<p><abbr title="HyperText Markup Language">HTML</abbr> describes document structure.</p>Accessibility and browser notes
Migration is an opportunity to restore headings, labels, keyboard behavior, and readable reflow. Do not preserve inaccessible movement or tiny text merely to make screenshots look identical. Validate the replacement against the original user task and information, not just the old visual style.
Common mistakes
Do not assume every old tag has a one-to-one modern element. Replacing center with div without CSS does not preserve presentation, while replacing every tt with code can invent semantics. Remove unused plugin scripts and dependencies as part of a reviewed migration.
Verify your implementation
Inventory obsolete markup, classify its purpose, and migrate one component at a time. Compare content, navigation, keyboard operation, responsive behavior, and form submission before and after. Keep representative legacy fixtures for regression checks and validate the final HTML against current rules.
Standard status and sources
Obsolete; browser availability must be checked independently of specification status.