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
Summary: Marquee should be able to use smoothscroll code to → Marquee should be able to use smoothscroll code to
That's not what IE6 is doing, is it? The marquee implementation tries to mimick IE's implementation, so I think this is invalid.
Component: General → Layout
Product: Firefox → Core
Version: unspecified → Trunk
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"
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 v126.96.36.199 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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → https://webcompat.com/issues/3551
Another instance of marquee implementation difference. https://webcompat.com/issues/3607
See Also: → https://webcompat.com/issues/3607
Another instance of marquee https://webcompat.com/issues/3631
See Also: → https://webcompat.com/issues/3631
See Also: → https://webcompat.com/issues/10768
See Also: → https://webcompat.com/issues/10725
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox58: --- → affected
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.
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"
Summary: Marquee should be able to use smoothscroll code to → Marquee should be able to use smoothscroll code
You need to log in before you can comment on or make changes to this bug.