What problem are you trying to solve?
The HTML Standard currently requires user agents to support <marquee>, while its use by authors is non-conforming. As a result, browsers continue to ship a native scrolling-content primitive while authors are expected to recreate similar behavior with CSS and JavaScript.
The issue is not simply the historical <marquee> presentation model. There is currently no standardized, native primitive for continuously moving content. Implementations built with CSS and JavaScript often require authors or libraries to handle content measurement, animation distance, resizing, dynamic content, writing modes, bidirectional text, and accessibility themselves.
The proposal is intentionally not committed to either modernizing <marquee> or introducing a new primitive. The purpose of this issue is to establish whether continuously moving DOM content represents a useful platform capability, and, if so, determine whether HTML, CSS, or an evolution of existing <marquee> behavior is the most appropriate place to provide it.
What solutions exist today?
CSS animations can provide the basic motion, but more complete implementations often require JavaScript to measure rendered content, determine animation distances, respond to layout and content changes, and coordinate the animation.
Libraries can abstract some of this complexity, but each implementation still has to solve many of the same problems independently.
<marquee> already provides much of this behavior natively and has broad browser support, but its authoring model and API are historical and non-conforming. A new HTML element or CSS primitive could also be appropriate.
This issue is intended to explore these alternatives rather than assume that <marquee> is necessarily the correct solution.
How would you solve it?
I would like to investigate whether <marquee> could be modernized into a conforming, accessible native primitive for continuously moving content while preserving necessary legacy behavior for compatibility.
A modern implementation could move responsibilities such as determining the scrolling distance from rendered content, responding to layout and content changes, supporting writing modes and bidirectional text, and integrating with accessibility and user preferences such as prefers-reduced-motion into the user agent.
The element should continue to contain ordinary DOM content without requiring duplicated or specially measured content. CSS should remain responsible for presentation, while JavaScript could provide imperative control where appropriate.
I am intentionally not proposing a complete API at this stage.
Anything else?
Accessibility should be a fundamental part of the design. This includes reduced-motion preferences, user control over motion, keyboard interaction with descendants, focus behavior, and assistive technology. Simply pausing when the element receives focus is unlikely to be sufficient.
I would particularly appreciate feedback from browser implementers on whether existing <marquee> implementations could reasonably be adapted for a modernized model, or whether a new HTML or CSS primitive would be more appropriate.
If there is sufficient interest, I would be happy to develop a prototype and a more concrete proposal based on that feedback.
~ This is my first time ever making a recommendation to the HTML Standard. This post was written over a few days (I have a horrible schedule), but I really appreciate any suggestions if I've made any mistakes in writing this! BuddyWinte ~
What problem are you trying to solve?
The HTML Standard currently requires user agents to support
<marquee>, while its use by authors is non-conforming. As a result, browsers continue to ship a native scrolling-content primitive while authors are expected to recreate similar behavior with CSS and JavaScript.The issue is not simply the historical
<marquee>presentation model. There is currently no standardized, native primitive for continuously moving content. Implementations built with CSS and JavaScript often require authors or libraries to handle content measurement, animation distance, resizing, dynamic content, writing modes, bidirectional text, and accessibility themselves.The proposal is intentionally not committed to either modernizing
<marquee>or introducing a new primitive. The purpose of this issue is to establish whether continuously moving DOM content represents a useful platform capability, and, if so, determine whether HTML, CSS, or an evolution of existing<marquee>behavior is the most appropriate place to provide it.What solutions exist today?
CSS animations can provide the basic motion, but more complete implementations often require JavaScript to measure rendered content, determine animation distances, respond to layout and content changes, and coordinate the animation.
Libraries can abstract some of this complexity, but each implementation still has to solve many of the same problems independently.
<marquee>already provides much of this behavior natively and has broad browser support, but its authoring model and API are historical and non-conforming. A new HTML element or CSS primitive could also be appropriate.This issue is intended to explore these alternatives rather than assume that
<marquee>is necessarily the correct solution.How would you solve it?
I would like to investigate whether
<marquee>could be modernized into a conforming, accessible native primitive for continuously moving content while preserving necessary legacy behavior for compatibility.A modern implementation could move responsibilities such as determining the scrolling distance from rendered content, responding to layout and content changes, supporting writing modes and bidirectional text, and integrating with accessibility and user preferences such as prefers-reduced-motion into the user agent.
The element should continue to contain ordinary DOM content without requiring duplicated or specially measured content. CSS should remain responsible for presentation, while JavaScript could provide imperative control where appropriate.
I am intentionally not proposing a complete API at this stage.
Anything else?
Accessibility should be a fundamental part of the design. This includes reduced-motion preferences, user control over motion, keyboard interaction with descendants, focus behavior, and assistive technology. Simply pausing when the element receives focus is unlikely to be sufficient.
I would particularly appreciate feedback from browser implementers on whether existing
<marquee>implementations could reasonably be adapted for a modernized model, or whether a new HTML or CSS primitive would be more appropriate.If there is sufficient interest, I would be happy to develop a prototype and a more concrete proposal based on that feedback.
~ This is my first time ever making a recommendation to the HTML Standard. This post was written over a few days (I have a horrible schedule), but I really appreciate any suggestions if I've made any mistakes in writing this! BuddyWinte ~