The internet has been around for a long while, and over time we’ve changed the way we think about web design. Many old techniques and ways of doing things have gotten phased out as newer and better alternatives have been created, and we say that they have been deprecated.
Deprecated. It’s a word we use and see often. But have you stopped to think about what it means in practice? What are some examples of deprecated web elements, and why don’t we use them any more?
What is deprecation?
In everyday English, to “deprecate” something is to express disapproval of it. For example, you might be inclined to deprecate a news story you don’t like.
When we’re speaking in a technical sense, however, deprecation is the discouragement of use for an old feature. Often, the old feature remains functional in the interests of backward compatibility (so legacy projects don’t break). In essence, this means that you can technically still do things the legacy way. It’ll probably still work, but maybe it’s better to use the new way.
Another common scenario is when technical elements get deprecated as a prelude to their future removal (which we sometimes call “sunsetting” a feature). This provides everybody time to transition from the old way of working to the new system before the transition happens. If you follow WordPress at all, they recently did this with their radically new Gutenberg editor. They shipped it, but kept an option available to revert to the “classic” editor so users could take time to transition. Someday, the “classic” editor will likely be removed, leaving Gutenberg as the only option for editing posts. In other words, WordPress is sunsetting the “classic” editor.
That’s merely one example. We can also look at HTML features that were once essential staples but became deprecated at some point in time.
Why do HTML elements get deprecated?
Over the years, our way of thinking about HTML has evolved. Originally, it was an all-purpose markup language for displaying and styling content online.
Over time, as external stylesheets became more of a thing, it began to make more sense to think about web development differently — as a separation of concerns where HTML defines the content of a page, and CSS handles the presentation of it.
This separation of style and content brings numerous benefits:
- Avoiding duplication: Repeating code for every instance of red-colored text on a page is unwieldy and inefficient when you can have a single CSS class to handle all of it at once.
- Ease of management: With all of the presentation controlled from a central stylesheet, you can make site-wide changes with little effort.
- Readability: When viewing a website’s source, it’s a lot easier to understand the code that has been neatly abstracted into separate files for content and style.
- Caching: The vast majority of websites have consistent styling across all pages, so why make the browser download those style definitions again and again? Putting the presentation code in a dedicated stylesheet allows for caching and reuse to save bandwidth.
- Developer specialization: Big website projects may have multiple designers and developers working on them, each with their individual areas of expertise. Allowing a CSS specialist to work on their part of the project in their own separate files can be a lot easier for everybody involved.
- User options: Separating styling from content can allow the developer to easily offer display options to the end user (the increasingly popular ‘night mode’ is a good example of this) or different display modes for accessibility.
- Responsiveness and device independence: separating the code for content and visual presentation makes it much easier to build websites that display in very different ways on different screen resolutions.
However, in the early days of HTML there was a fair amount of markup designed to control the look of the page right alongside the content. You might see code like this:
<center><font face="verdana" color="#2400D3">Hello world!</font></center>
…all of which is now deprecated due to the aforementioned separation of concerns.
Which HTML elements are now deprecated?
As of the release of HTML5, use of the following elements is discouraged:
<acronym>
(use<abbr>
instead)<applet>
(use<object>
)<basefont>
(use CSS font properties, likefont-size
,font-family
, etc.)<big>
(use CSSfont-size
)<center>
(use CSStext-align
)<dir>
(use<ul>
)<font>
(use CSS font properties)<frame>
(use<iframe>
)<frameset>
(not needed any more)<isindex>
(not needed any more)<noframes>
(not needed any more)<s>
(usetext-decoration: line-through
in CSS)<strike>
(usetext-decoration: line-through
in CSS)<tt>
(use<code>
)
There is also a long list of deprecated attributes, including many elements that continue to be otherwise valid (such as the align
attribute used by many elements). The W3C has the full list of deprecated attributes.
Why don’t we use table for layouts any more?
Before CSS became widespread, it was common to see website layouts constructed with the <table>
element. While the <table>
element is not deprecated, using them for layout is strongly discouraged. In fact, pretty much all HTML table attributes that were used for layouts have been deprecated, such as cellpadding
, bgcolor
and width
.
At one time, tables seemed to be a pretty good way to lay out a web page. We could make rows and columns any size we wanted, meaning we could put everything inside. Headers, navigation, footers… you name it!
That would create a lot of website code that looked like this:
<table border="0" cellpadding="0" cellspacing="0" width="720">
<tr>
<td colspan="10"><img name="logobar" src="logobar.jpg" width="720" height="69" border="0" alt="Logo"></td>
</tr>
<tr>
<td rowspan="2" colspan="5"><img name="something" src="something.jpg" width="495" height="19" border="0" alt="A picture of something"></td>
<td>Blah blah blah!</td>
<td colspan="3">
<tr>
<!-- and so on -->
</table>
There are numerous problems with this approach:
- Complicated layouts often end up with tables nested inside other tables, which creates a headache-inducing mess of code. Just look at the source of any email newsletter.
- Accessibility is problematic, as screen readers tend to get befuddled by the overuse of tables.
- Tables are slow to render, as the browser waits for the entire table to download before showing it on the screen.
- Responsible and mobile-friendly layouts are very difficult to create with a table-based layout. We still have not found a silver bullet for responsive tables (though many clever ideas exist).
Continuing the theme of separating content and presentation, CSS is a much more efficient way to create the visual layout without cluttering the code of the main HTML document.
So, when should we use<table>? Actual tabular data, of course! If you need to display a list of baseball scores, statistics or anything else in that vein, <table> is your friend.
Why do we still use <b> and <i> tags?
“Hang on just a moment,” you might say. “How come bold and italic HTML tags are still considered OK? Aren’t those forms of visual styling that ought to be handled with CSS?”
It’s a good question, and one that seems difficult to answer when we consider that other tags like <center>
and <s>
are deprecated. What’s going on here?
The short and simple answer is that <b>
and <i>
would probably have been deprecated if they weren’t so widespread and useful. CSS alternatives seem somewhat unwieldy by comparison:
<style>
.emphasis { font-weight:bold }
</style>
This is a <span class="emphasis">bold</span> word!
This is a <span style="font-weight:bold">bold</span> word!
This is a <b>bold</b> word!
The long answer is that these tags have now been assigned some semantic meaning, giving them value beyond pure visual presentation and allowing designers to use them to confer additional information about the text they contain.
This is important because it helps screen readers and search crawlers better understand the purpose of the content wrapped in these tags. We might italicize a word for several reasons, like adding emphasis, invoking the title of a creative work, referring to a scientific name, and so on. How does a screen reader know whether to place spoken emphasis on the word or not?
<b>
and <i>
have companions, including <strong>
, <em>
and <cite>
. Together, these tags make the meaning context of text clearer:
<b>
is for drawing attention to text without giving it any additional importance. It’s used when we want to draw attention to something without changing the inflection of the text when it is read by a screen reader or without adding any additional weight or meaning to the content for search engines.<strong>
is a lot like<b>
but signals the importance of something. It’s the same as changing the inflection of your voice when adding emphasis on a certain word.<i>
italicizes text without given it any additional meaning or emphasis. It’s perfect for writing out something that is normally italicized, like the scientific name of an animal.<em>
is like<i>
in that it italicizes text, but it provides adds additional emphasis (hence the tag name) without adding more importance in context. (‘I’m sure I didn’t forget to feed the cat’).<cite>
is what we use to refer to the title of a creative work, say a movie like The Silence of the Lambs. This way, text is styled but doesn’t affect the way the sentence would be read aloud.
In general, the rule is that <b>
and <i>
are to be used only as a last resort if you can’t find anything more appropriate for your needs. This semantic meaning allows <b> and <i> to continue to have a place in our modern array of HTML elements and survive the deprecation that has befallen other, similar style tags.
On a related note, <u>
— the underline tag — was at one time deprecated, but has since been restored in HTML5 because it has some semantic uses (such as annotating spelling errors).
There are many other HTML elements that might lend styling to content, but primarily serve to provide semantic meaning to content. Mandy Michael has an excellent write-up that covers those and how they can be used (and even combined!) to make the most semantic markup possible.
Undead HTML attributes
Some deprecated elements are still in widespread use around the web today. After all, they still work — they’re just discouraged.
This is sometimes because word hasn’t gotten around that that thing you’ve been using for ages isn’t actually the way it’s done any more. Other times, it’s due to folks who don’t see a compelling reason to change from doing something that works perfectly well. Hey, CSS-Tricks still uses the teletype element for certain reasons.
One such undead HTML relic is the align attribute in otherwise valid tags, especially images. You may see <img>
tags with a border
attribute, although that attribute has long been deprecated. CSS, of course, is the preferred and modern method for that kind of styling presentation.
Staying up to date with deprecation is key for any web developer. Making sure your code follows the current recommendations while avoiding legacy elements is an essential best practice. It not only ensures that your site will continue to work in the long run, but that it will play nicely with the web of the future.
Questions? Post a comment! You can also find me over at Angle Studios where I work.
Perhaps the
del
tag could be a good modern alternative tos
andstrike
? It also provides more meaning along withcitation
anddatetime
attributes.https://developer.mozilla.org/en-US/docs/Web/HTML/Element/del
They have different meaning. The
ins
anddel
elements represent edits of the document (https://html.spec.whatwg.org/multipage/edits.html#edits). However, there are cases where “old” information need to be output along with the “new” one that are not edits (e.g. the regular price near the discounted price). For these cases, thedel
element would be impropriate.What about
<del>
instead of<strike>
?The
<i>
Tag is now used for icons.It definitely has been used for icons because it used to lack semantic meaning, but that’s changed. It’s used for phrasing content that needs to be set apart visually from other content for readability.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/i
While I’m certain that most CSS Tricks regulars know this, it’s probably worth mentioning that
<i>
is nowadays often (mis?)used for icon fonts.Also, does anybody else think that replacing
<acronym>
with<abbr>
feels a bit odd. I wonder what the semantic reasoning behind this move was (or is it some inside-joke?)It does seem a little odd. I wonder if the term “acronym” was a little too specific and moving to “abbreviation” opened the semantics up to more possibilities of shortened content.
Why don’t some CSS properties become deprecated?
I think, the good word is semi-deprecated in real. For example what about the HTML parts of an email?
Thanks for this article. I think a lot of the things discussed have already been talked about 15 years ago when older web developers were adopting new WC recommendations at the time. That’s why in 2003 I started using “strong” instead of “b” in all my web projects and threw out all the ones you mentioned. Here we are in 2020 rediscovering the semantic purpose of these old elements? Sadly, this is the curse of technology…we dont read or learn from what older techies discovered so left to rediscover them all over again. This is precisely why HTML5 went backwards as XHTML 1.1 was moving us into a cleaner, repurposeable Web where we could write out own elements. That’s been trashed so kids can go back to HTML4 concepts and ECMAScripted API’s. We are all doomed to repeat the same mistakes I think, which keeps the simple process of displaying a siple HTML page way more complicated today than it was 20 years ago.
XHTML1.x wasn’t moving us anywhere. It was basically nothing more than reformulation of the same HTML4 semantics in the XML syntax, and potential advantages of XML didn’t really work for web because web was (and still is) the unpredictable environment where the XML well-formedness could get broken by thousands of reasons, from network interruption to third-party software intervention (e.g. some personal firewalls used to replace ad banners with XML-incompatible HTML comments). Replacing the XHTML1.x doctype with the custom one defining custom elements etc. automatically made it a custom XML application rather than XHTML1. On the other hand, you actually can define your own custom elements in HTML5 right now:)
Both WHATWG Living Standard and W3C HTML5.2 Recommendation (the last one before W3C gave up maintaining its own branch of the HTML standard) list the
<s>
element among the active text-level elements and say nothing about its deprecation. Didn’t it appear in the article by mistake?The
element is not deprecated.https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-s-element
<b>
is for drawing attention to text without giving it any additional importance. It’s used when we want to draw attention to something without changing the inflection of the text when it is read by a screen reader or without adding any additional weight or meaning to the content for search engines.”so why are you drawing attention to the text? what’s the meaning for it? and …why should a screen reader user not know that you’re drawing attention to it?
If only the
<strong>
elements had any meaning for most actual screen readers either… https://www.brucelawson.co.uk/2018/screenreader-support-for-text-level-semantics/Hi
Hmmm As Google said:
<b>
or<strong/>
could be used without any difference in terms of Google ranking https://www.youtube.com/watch?v=awto_wCeOJ4So, it looks like they exist thanks to their support in most CMS :(
I’m surprised
<hr>
isn’t on this list.