Some time ago, I needed to make some scrolling text for a site. Text that scrolls from left to right so long strings can be read without needing line-breaks.

I expected I would need a hacky JavaScript solution to achieve it, which is why I was surprised to discover the <marquee> element.

Here is what it does in action:

<marquee>
    <em>This text should be scrolling if your browser supports the <code>&lt;marquee&gt;</code> element!</em>
</marquee>

false

false

This is super cool and it even has a bunch of other cool features!

And that's all without any CSS or JavaScript. S tier element in my book. How did I not discover this until now?

Well, that may be because it is deprecated.

Explanations for why it was deprecated are scarce, but here are four potential reasons:

1. It was never part of any HTML spec
2. It is animated, and HTML should define structure, not animation
3. It is intrusive
4. It does not respect reduced-motion preferences

As a result, despite having solid browser support, it is not recommended to use and (at least in theory) can lose support at any time.

I am nowhere near qualified enough to answer this question. But I can draw some comparisons.

Introducing: the <details> element!

<details>
    <summary>Open me</summary>
    Now you can see me!
</details>

While it could be argued that the <details> element helps to define document structure, it also certainly defines some animation—even if that animation is just opening and closing some text.

<details>
    <summary>Open me</summary>
    Now you can see me!
</details>

false

false

While this is by no means as intrusive as the <marquee> element, I do think there exists an argument (albeit a potentially weak one) saying that if <details> can exist, why can't <marquee>?

Regardless of whether or not you are pro or anti <marquee>, there is something that I think most people can agree on: backward compatibility is important.

One of the things I like about HTML files (and by extension, CSS and maybe JavaScript) is that they are normally backward compatible. You can open an old HTML file from 2001 and it should still work! And I love that.

Imagine if each new HTML version added breaking changes. That would be awful. Especially since the web has become the world's biggest historical archive.

So, at the very least, I think browsers continuing to render <marquee> and other deprecated elements is good. Because, at the end of the day, <marquee> and all other HTML elements have rich history that we shouldn't ignore.

Does this mean browsers will have to put work into supporting elements that are not used much anymore? Yes. But I think that is a price worth paying for historical preservation.

To replace Marquee, it is recommended to use CSS keyframes, like this nice example from Codepen:

<div class="marquee">
    <div>
        <span>You spin me right round, baby. Like a record, baby.</span>
        <span>You spin me right round, baby. Like a record, baby.</span>
    </div>
</div>

.marquee {
    height: 25px;
    width: 420px;
    overflow: hidden;
    position: relative;
}
.marquee div {
    display: block;
    width: 200%;
    height: 30px;
    position: absolute;
    overflow: hidden;
    animation: marquee 5s linear infinite;
}
.marquee span {
    float: left;
    width: 50%;
}
@keyframes marquee {
    0% { left: 0; }
    100% { left: -100%; }
}

false

This is a good solution, but has some drawbacks compared to the <marquee> element:

• It requires duplicate instances of the content in the HTML (and to lots of developers, duplicate code is a big no no)
• Requires a lot more HTML elements (three layers of nested elements)
• That's a lot of lines of code...

I can't be the only one who thinks it would be better to build up the <marquee> element instead of deprecate it, right? Perhaps by improving its spec and adding default reduced-motion support?

Whatever issues there are with <marquee>, is abandoning it really the best solution?

There are definitely good reasons in favor of its banishment. I just think there are also good reasons to keep backward compatibility for elements like this.

...just not for <blink>. That can go.