Marquee should be able to animate smoothly (either via smooth scrolling or transform animations)
Categories
(Core :: DOM: Core & HTML, enhancement, P3)
Tracking
()
People
(Reporter: jack, Assigned: emilio)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
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•19 years ago
|
||
That's not what IE6 is doing, is it? The marquee implementation tries to mimick IE's implementation, so I think this is invalid.
Reporter | ||
Comment 2•19 years ago
|
||
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•19 years ago
|
||
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
Updated•18 years ago
|
Comment 4•8 years ago
|
||
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•8 years ago
|
||
Another instance of marquee implementation difference. https://webcompat.com/issues/3607
Comment 6•8 years ago
|
||
Another instance of marquee https://webcompat.com/issues/3631
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Comment 7•7 years ago
|
||
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.
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Comment 8•7 years ago
|
||
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"
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Comment 9•6 years ago
|
||
Setting to [webcompat:p3] because this is highly visible in regions that make heavy use of marquee.
Updated•6 years ago
|
Comment 10•6 years ago
|
||
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•5 years ago
|
||
See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.
Updated•5 years ago
|
Comment 12•4 years ago
|
||
Smoother animation is not necessarily safer, for example ease in-out, smooth scrolling, etc. can all trigger migraines.
Updated•4 years ago
|
Comment 13•4 years ago
|
||
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•4 years ago
|
||
Whoops, replied to wrong thread.
Updated•4 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 15•3 years ago
|
||
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.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•1 year ago
|
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Comment 16•16 days ago
|
||
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)
Updated•16 days ago
|
Comment 17•9 days ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0506d9964b32 Use transform animations to implement marquee. r=smaug,firefox-animation-reviewers,boris
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45618 for changes under testing/web-platform/tests
Comment 19•9 days ago
|
||
Backed out for causing reftests failures in 371466-1.xhtml and mochitests failures in test_memoryReporters.xhtml.
-
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
Upstream PR was closed without merging
Updated•9 days ago
|
Assignee | ||
Updated•9 days ago
|
Comment 21•9 days ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c5dcab43fa40 Use transform animations to implement marquee. r=smaug,firefox-animation-reviewers,boris
Comment 22•8 days ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Updated•7 days ago
|
Description
•