Scrolling Marquee Block

[iamtakashi]

It'd be nice if there is a block that allows creating easily a scrolling marquee.

For example:

I had a quick look here if there has already been a request for something similar, but I didn't find one. If there is please kindly point me there. Thanks!

[carlomanf]

I had a quick look here if there has already been a request for something similar, but I didn't find one. If there is please kindly point me there. Thanks!

#27508

[iamtakashi]

Thank you, @carlomanf.

The request was closed 2 years ago, but I think it's gaining popularity recently. I left a comment to see if it's worth reconsidering now.

[iamtakashi]

The recent examples on the web don't seem to use generally the actual marquee tag. Based on that, the conversation in #27508 concluded it would be better suited for doing it as a standalone block in the block directory.

[iamtakashi]

@mtias shared with me an example that only uses CSS animation. That doesn't rely on front-end JS, and we could encapsulate it in core if we take that route. I'm reopening this to hear more thoughts on this.

[aristath]

This feels a bit too niche for a Core block... IMHO this would be better suited for a plugin. Considering the "80% rule" that we try to follow in WordPress Core features, I doubt 80% of users need a marquee/scrolling-text block. (see the Clean, lean and mean section in the WordPress Philosophy page)
Sure, there are scenarios where it can be useful like certain news sites, stocks/financial sites and a couple of other scenarios, but can we in good conscience add that block in Core and say "we need this in Core, it should not be a 3rd-party plugin"? 🤔

[sabernhardt]

Adding a Core block that scrolls through its content could easily reduce the usability of sites across the Web.

If you really want a block like this, there is at least one existing block plugin. For a somewhat better block, you could create a plugin that:

1. Honors visitors' browser/OS motion preferences.
2. Allows visitors to pause/resume the CSS animation and to view all of the block's content without scrolling.
3. Pauses animation automatically when hovering over its content or when focusing on an interactive element—such as a link—within that block.
4. Considers the length of the content when setting the animation duration (48 seconds can be a slow crawl for a few words but ridiculously fast for a paragraph).

Even with those four considerations (plus any I missed), you still need to expect that some visitors will not appreciate that they must either view the content at the given speed or else find the pause button. And the ire against unwanted motion likely would be greater among people with certain disabilities.

[afercia]

I'm honestly surprised to see this proposal included in the Roadmap for WordPress 6.4.

Historically, scrolling text was implemented via proprietary HTML tags like <marquee>. At the very early stage of the web standards movement, the marquee element was one of the first ones to be basically 'banned', for many good reasons. Even if this proposed feature doesn't use marquee, scrolling text is always highly problematic and I don't think WordPress should ever encourage its usage. It would be like going 25 years back in the Geocities era.

As @aristath mentioned, I do think this is plugin territory. It shouldn't be in WordPress.

Even before accessibility considerations, there are serious usability and readability concerns with scrolling text. All this is not new and I'm surprised scrolling text gets repurposed so lightly, with little knowledge that it's is widely recognized as a bad practice. I'd like to point to a post by the Nielsen Norman Group. Note that the post dates April 30, 1996:

A web page should not emulate Times Square in New York City in its constant attack on the human senses: give your user some peace and quiet to actually read the text!

Besides the sarcams used in the above statement, which may sound slightly unfair, the usability concerns are well known since many years.

On top of that:

• Text that move automatically may even be dangerous for some users, as it may trigger seizure.
• It is highly distracting for all users.
• It is difficult to read for all users.
• [Update] Users with dyslexia would find scrolling text even more troublesome to read.
• It is difficult to click on when it contains links.
• It is frustrating for users with low vision, cognitive disabilities, or attention deficits.
• It doesn't provide any semantic meaning.
• The speed of the scrolling is very subjective and varies greatly from user to user. it will likely be frustratingly slow for some, and frustratingly fast for others.
• Scrolling text is not always completely visible on rendered pages, making printing such pages an inefficient (if not impossible) task.

@joedolson when you have. chance: Any other usability / readabiility / accessibility concerns I may be missing?

[johnstonphilip]

Agree, this is plugin territory.

[joedolson]

I think you've covered the issues pretty well, @afercia. I fully agree that this is something that should not be available in core. If it does go into core, it needs to support everything @sabernhardt suggested.

[afercia]

I forgot users with dyslexia or other reading / learning impairments. Added to the list of concerns in my previous comment.

[richtabor]

If it does go into core, it needs to support everything @sabernhardt suggested.

Agreed.

[annezazu]

With additional work needed to get this block ready for consideration in Core, let's punt this to 6.5 at this point to focus current efforts.

[afercia]

Although this is now punted to consideration for 6.5, I'd like to hear thoughts from other accessibility practitioners about the general proposal and whether or not to include it into core. To me (and others) it seems WordPress should not encourage this pattern. As such, instead of just punting, I'd vote for just discarding this proposal. Cc @andrewhayward

[andrewhayward]

I'm in general alignment with others above, and would discourage adding this as a feature to core. Aside from the fact that (as mentioned) it feels a bit too niche, I don't think this is a pattern we should be promoting in general.

The only reason I can see to do so would be to have more control over its implementation, but that's a bit of a stretch. We could do that as a plugin, if we really wanted to.

[costdev]

I agree with the sentiments shared by others above. I don't see enough demand or use cases, and I think the accessibility and UX concerns for scrolling text are well established. I'd recommend that this idea isn't only punted, but that we make a decision not to include a scrolling text block in Core.

Scrolling text aside, a ticker that switches between text items, with motion preference awareness and controls to manually switch to a previous/next/specific item, may be desirable from a news or marketing perspective. This could be achievable with a Carousel/Slider block that only contained text, and such a block would have enough flexibility for other content types, thereby offering more than a single use case. This may be something we can consider when working on a Slider block and deciding which inner blocks it should support.

[scrobbleme]

-1
Despite this being a nice feature, this is far from a “standard” block anybody needs. Actually, never see this life…

I agree, that this might be a feature of a Slider block, which there is really demand for.

[fclaussen]

-1
I agree with the general sentiment in this thread. There are other more important things to focus on.

[Sirjazzfeetz]

"It's constant attack on the human senses: no peace and quiet to read!"

Historically, yes, the marquee was frowned upon, leading to a web standards prohibition.

But I don't think we want text theologians to be in-charge of modern design standards.

Granted, it was a 'legitimate' accessibility concern at the time: Early websites were text-based and static (bandwidth limitations, non-interactive), so inserting animated text was a jarring disruption. Combine this with the design standards and aesthetic intelligence of the early web. The inevitable excess of novel animation technology. And you get GeoCities, where 'scale' itself then became the problem in a Pandora's Box-like moment, which produced moral panic (the hilarious quote mentioned above).

Today, we'd be lucky if WP released any feature with the same aesthetic impact. Let alone by promoting a text-feature in an increasingly image-based world. So I think we can safely put aside concerns about repeating the trauma of GeoCities; rather than dominating our sensibilities at scale, it's more likely to be sparsely included as part of a much more seamless, suitable design.

---

In design, not all text is meant to be read. Especially when moving, purposefully tilted at difficult to read angles, or repeated in a pattern. It's the gestalt of the page or pattern that counts. Form and style are prioritized, total effect over specific meaning. Although, readability has come a long way from the pixelated days of small fonts on low resolution, low frame-rate, screens. And the trend is towards large and interactive (and controllable) fonts, amidst parallax scrolling, zooming effects, and many more motion graphics. The response to all this animation or increase of movement has produced solutions for both browser and OS.

So despite accessibility being an admirable and popular topic, I question whether it's still a problem in this situation. So far, only comments made by those who think others will be affected, based on depreciated data. As for inclusion in core, I'm agnostic.

[joedolson]

There is no need for WordPress core to support something like this; the choice not to have this in core does not in any way stop people from implementing it in plugins.

In design, not all text is meant to be read. Especially when moving, purposefully tilted at difficult to read angles, or repeated in a pattern. It's the gestalt of the page or pattern that counts. Form and style are prioritized, the total effect over specific meaning.

All I can say to that is I do not agree with your concept of design. Design is intended to communicate; if the text is not meant to be read, then omit it and just use random shapes and colors. That's what videos and animated gifs are for.

[Sirjazzfeetz]

Either way, by blurring the line between text-based development and image-based design, the Scrolling Text Marquee could act as a boundary object: "A boundary object is any object that is part of multiple social worlds and facilitates communication between them; it has a different identity in each social world that it inhabits." Providing much needed common ground for communication between developers and designers; the latter for who communication is not what you say, but the effect of what you say. Which is often a nostalgic effect of perpetual returns and purification, rather than the eternal depreciation of progressive revolutions.

[scrobbleme]

I think one major issue with this ticket is not the "marquee" effect itself.
But, that the team is working on a feature, which is generally considered of "being bad" instead of working on really needed and useful features.

(Personally, I don't know anyone using or recommending marquee, haven't seen this in years … I really wonder where this "high need" comes from)

[richtabor]

But, that the team is working on a feature, which is generally considered of "being bad" instead of working on really needed and useful features.

I'm not aware of folks working on this currently.

[trynet]

Please, no scrolling marque block. We have plenty of blocks already and more moving content is not needed. Besides, leave something for the extenders to do!

[colorful-tones]

This is plugin territory and we should stop punting and just rename this issue to prepend something like [Will Not Implement].

[annezazu]

Punting this out of 6.5 as no efforts have been made to move this forward in time.

[Sirjazzfeetz]

Perhaps best integrating marquee into a more feature-rich animation block,
so text (and icons) are non-default options, after border-lines and/or colors.
I'm thinking wavey and geometric shaped paths, rather than a simple ticker.

[colorful-tones]

Hi folks,
We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.