306344 - Marquee should be able to animate smoothly (either via smooth scrolling or transform animations)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Jack Eidsness]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050829 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050829 Firefox/1.0+

In a perfect world, there would be no marquee, but since it exists, maybe it
should look 50% less awful.  It's always jumping around and is very hard to
read.  Since this problem has already been addressed with the most common
example of moving text, the scrolling of a perfectly ordinary window, I was
hoping that it could be used on marquee text as well.

I don't have a lot invested in seeing this happen, but I thought it was an idea
worth sharing once.

Reproducible: Always

Steps to Reproduce:
1. Use marquee tag
2. Try to read it
3. get mad

Actual Results:  
human eyes have mild difficulty tracking the letterforms

Expected Results:  
it would be no harder than reading text on a slow moving truck

Comment 1

[Martijn Wargers (dead)]

That's not what IE6 is doing, is it?
The marquee implementation tries to mimick IE's implementation, so I think this
is invalid.

Comment 2

[Jack Eidsness]

As far as I can tell, they both faithfully jump as many pixels (scrollamount) as
the author specifies at the interval specified by the scrolldelay, with some
kind of limit on how often the contained page elements can be moved.  Speed can
be made up by bigger jumps, but the number of milliseconds... I have no idea how
to calculate what will be the smoothest scroll that actually allows reading of
text, considering that the width will vary from page to page as well as screen
to screen.

There is no way to specify an actual speed that looks smooth, yet is independant
of the capabilities of the displaying computer;  Obviously, if it were possible,
most authors would want the scrollamount to always be one, and the delay would
be as low as necessary to produce the desired speed.  I could not prove this,
but I suspect that the designers intent was to provide an interface for speed,
in two different attributes instead of one.  That may be wishful thinking on my
part.

It's like reverse of the old joke where the policeman says "You were going 90
miles an hour" and the driver who responds "It's ok, I was only going to drive
another 15 miles"

Comment 3

[Silvio Macedo]

Hi,
I agree - this is not a bug (but there is lack of functionality, i.e. "truespeed" which I will submit on another bug). 

Regarding marquee usage and looks, useless comment ;) :
In case you want to use a marquee to simulate a news crawler, like CNN for example, you get close to it by setting scrollamount=1 and scrolldelay=8 or so (depending on the width of your window). 
Current FF v1.5.0.1 does not allow scrolldelay less than 40ms... so, scrollamount=1 will go really slow. But in IE, one can add "truespeed" to achieve this result. The drawback?
If marquee is implemented in software, no gpu acceleration, this will be slow and consume about 70% of a 1.8GHz cpu. 
On the other hand, with hw acceleration (most X servers and Windows drivers), scrollamount=1 will be ok and CPU will stay below 5-7%.
Regards,
Silvio

Comment 4

[Karl Dubost💡 :karlcow]

We have a Web compatibility issue related to this.
https://webcompat.com/issues/3551

I guess the big difference in between Blink and Gecko
```html
<marquee scrollamount="3" direction="up" height="300" bgcolor="">
```

is that changing the scrollamount="3" values changes 
* the speed of the scrolling in Blink 
* not the jump from pixel to pixel (Gecko). 

So basically it's faster in Blink not jumpier.

Comment 5

[Karl Dubost💡 :karlcow]

Another instance of marquee implementation difference.
https://webcompat.com/issues/3607

Comment 6

[Karl Dubost💡 :karlcow]

Another instance of marquee
https://webcompat.com/issues/3631

Comment 7

[Karl Dubost💡 :karlcow]

The code used for marquee is not coming from the animation stack code in Gecko. 
It's probably not an emergency. An idea would be to reuse the code of CSS animation for making it smoother.

Comment 8

[Carlos Alén Silva]

This bug's summary should be changed from:

"Marquee should be able to use smoothscroll code to"

to either:

"Marquee should be able to use smoothscroll code too"

or

"Marquee should be able to use smoothscroll code"

Comment 9

[Mike Taylor [:miketaylr]]

Setting to [webcompat:p3] because this is highly visible in regions that make heavy use of marquee.

Comment 10

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Using CSS animations (or Web animations) would allow this to run on the compositor.

We may or may not want to hide such animations from the animation inspector, however.

Comment 11

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.

Comment 12

[MarjaE]

Smoother animation is not necessarily safer, for example ease in-out, smooth scrolling, etc. can all trigger migraines.

Comment 13

[MarjaE]

I use userChrome.css and userContent.css to force things into 16 pt Andika, because I find that a lot easier to read. Minimum font sizes also help with small text. Full-page zoom has to be pretty extreme to fix small text, and invariably makes larger text far too big, making it harder to navigate pages.

Comment 14

[MarjaE]

Whoops, replied to wrong thread.

Comment 15

[Karl Dubost💡 :karlcow]

data:text/html,<!doctype html><marquee width="55%" scrolldelay="2" behavior="alternate">Is my scrolling janky?</marquee>

Chrome is smooth
Safari and Firefox are janky.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 306344 - Use transform animations to implement marquee. r=#firefox-animation-reviewers!,smaug!

This matches what chromium does, and is both simpler and prettier.

The overflow: hidden enforcement also matches chromium / WebKit via:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/resolver/style_adjuster.cc;l=482;drc=88c8510c16d44e0dc8c07426db31aa5bb3c90a2b
https://searchfox.org/wubkat/rev/473ca5f8512b88edd7e82c8783e7e09158f17ba1/Source/WebCore/style/StyleAdjuster.cpp#581-596

Adding white-space: nowrap isn't strictly necessary, but also matches
other implementations:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_marquee_element.cc;l=66;drc=4aba604f0aae6fb93eab830b68765604e9a2cca0
(and same link as above on WebKit)

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0506d9964b32
Use transform animations to implement marquee. r=smaug,firefox-animation-reviewers,boris

Comment 18

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45618 for changes under testing/web-platform/tests

Comment 19

[Serban Stanca [:SerbanS]]

Backed out for causing reftests failures in 371466-1.xhtml and mochitests failures in test_memoryReporters.xhtml.

• Backout link

• Push with failures - reftests failures

• Failure Log

• Failure line: REFTEST TEST-UNEXPECTED-FAIL | dom/base/crashtests/371466-1.xhtml | assertion count 1 is more than expected 0 assertions

---

• Push with failures - mochitests failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | toolkit/components/aboutmemory/tests/test_memoryReporters.xhtml | assertion count 1 is more than expected 0 assertions

Comment 20

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c5dcab43fa40
Use transform animations to implement marquee. r=smaug,firefox-animation-reviewers,boris

Comment 22

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/c5dcab43fa40

Comment 24

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot