This is the antithesis to bug 156979. If I want to get a headache, I already have more than enough ways; blinking text, animated GIF images, and popup windows will satisfy my cravings for cranial distress. I don't find the inclusion of an XBL scrolling marquee mechanism necessary to increase the intensity of my masochistic binges; they just give me something else to wait for while Mozilla loads into memory on startup. Fortunately, I have a prefs to turn off the blinking text, animations, and popups. But why should I shoot for yet another pref? Why have marquee at all? I mean, what Bugzilla QA could look at himself in the mirror after WONTFIXing *this* bug?

Adding a URL which functions not only as a testcase, but also a reference to the W3C's viewpoint on this issue. Whoopdee-doo. <http://www.hicom.net/~oedipus/wai/ua/tests/scrolling_text_test1.html>

-> Doron (marquee sucks) Near the whole mozilla community doesn't want marquee. (ask on #mozillazine !) This breaks the standards because it's no W3C standard. There is no difference if we add support to document.layers or document.all. The solution would be to support it as extension. Or add it only in the quirks mode : bug 159839 I can't understand why our standard persons wants this and all other people not. They ignore the Mozilla community. *Mozilla.org* should know it better... (or they don't want us) Sorry for this but i work for mozilla because it i love this great browser but a few people destroy it with this IE crap HTML TAG.

create a patch to make it an extension. I've said this over and over again.

You broke marquee's heart, he's now in the bathroom crying. I heard he's planning blinking marquee for revenge

This should be a pref instead.

bug 161109 is the pref.

Is the MARQUEE support off by defalt?

My personal feeling on <marquee> are that is should only work as a preference or and that, that preference should be off by defalt and that Loop ETC atributes should also work

In the mail component, there is a sanitisation list of tags which are allowed, could something simlar be done here?

Instead of listening to what I have to say, why don't you listen to the many supporters of a marquee-free browser in bug 156979? There are quite a few of them, and they make a good point: bug 156979 comment 20 bug 156979 comment 21 bug 156979 comment 22 bug 156979 comment 25 bug 156979 comment 28 bug 156979 comment 36 bug 156979 comment 43 bug 156979 comment 45 bug 156979 comment 49 bug 156979 comment 54 bug 156979 comment 61 bug 156979 comment 64 bug 156979 comment 66 By the way, bug 156979 comment 2 seems to be a broken promise. Why have this "feature" in the browser by default? To impress a few people in China? If these authors truly have a bona-fide reason for using <marquee> they can use a DHTML script. Or, if we do decide to leave marquee in, it should be disabled by default--if there's a good reason for a site to use a marquee, the user can easily open prefs and turn it back on (after the pref is added to the UI). The whole point is not to alienate users; it appears by the overwhelming show of disgust at bug 156979 and similar distaste in the past (bug 110925) that quite a few users would be alienated if we added marquee in by default. After looking through a few of those Chinese sites, I must say that most of them are using scrolling marquees because they look "cool," not because there is any serious need for them. (If they want to look cool they have plenty of plugin technologies at their disposal.) In fact, it seems like the general idea is to use marquee to make a long stream of text fit into a small area so as not to break a pixel-perfect layout. That would certainly be a shame! Also, marquee doesn't degrade any worse in the browser than it would on a printer. It should be clear that there is a perfectly good reason for this bug to exist, and for it to be reasonably high on everyone's lists to be resolved. I may not be fortunate enough to see the marquee patch backed out, but I'd like it to be a pref and disabled by default. By the way, it appears that Netscape will be implementing this same behavior. That would be a huge mistake on their part, so I'm using the proper NS keywords.

>By the way, it appears that Netscape will be implementing this same behavior. >That would be a huge mistake on their part, so I'm using the proper NS keywords. you should NOT be setting Netscape keywords. Especailly if Netscape implemented it. Like I said, create a patch to make it a extension if you feel it should not be on by default. One more useless comment and I will close this :)

Doron: Those are nomination keywords... explain to me why this doesn't involve Netscape? You are free to change them to nsbeta1- and nscatfood- if you honestly feel those keywords don't apply; AIUI, they shouldn't be removed unless the bug doesn't occur in Netscape.

The addition of marquee to Moz makes no sense to me. Chinese sites don't support xbrowser scrollers because no one uses Moz. I live in Vietnam and no one uses Moz here either. Has nothing to do with support for marquee. Add it in and still no one will use it. -But then you ruin Moz by subjecting everyone to what people using Moz don't want. If the goal is to have 30 (!!!) Chinese sites use xbrowser scrollers, email the 30 Chinese sites this link: http://www.dynamicdrive.com/dynamicindex2/index.html and they can go from there. Hell, choose the best scroller, and send an official email from Mozilla/Netscape/whomever. They'll be very impressed. Grotesque overkill to add marquee in to Moz, especially in standards mode, when an email and some free dhtml code can have the same (non-)effect. Otherwise you appear to assume these people are stupid and can't write xbrowser scripts like everyone else in the world. Or let Netscape add it in to their version if they insist, but I don't see how Moz should have it added. The best way to go is to build a user-friendly standards browser, thus making it more and more popular such that 3rd world developers will support it more. That's my argument for removing marquee support: adding it in doesn't solve the problem, annoys everyone else, and there are better ways to approach the problem.

Question for <bobj@netscape.com>: In bug 156979 comment 159 you said: > From comment #157 > > Will this mean the Marquee tag will work in Netscape 7? > Yes. In that case, should this bug also be used by Netscape to track possible user satisfaction issues with scrolling marquee support, and the need for a solution such as full removal, making it an extension, or adding a pref? In that case I certainly think it is correct for this bug to be nominated as nsCatFood.

The decision for marquee support has the backing of the module owners and staff@mozilla.org. As QA contact for this change, I'm resolving it as wontfix. If you re-open this be prepared for it to be resolved again. If you file another bug on this same topic be prepared for it to also be resolved.

I don't agree with WONTFIX.

One must wonder if the talk (or perhaps threats) of mutiny and forking will come to fruitition over this one stupid issue. Nonetheless I don't agree with it either, for this violates one of the very reasons I like Mozilla.

It doesn't matter whethere or not everyone agrees with this. Mozilla is not a democracy. This feature has been implemented with the support of module owner and staff@mozilla.org. It is not going to be removed without the support of module owner and staff at mozilla.org, which it does not have. This bug is won'tfix.

Should I open bugs, "Rename Mozilla to Microsoft Mozilla" and "Change browser from open source to closed source"? Those are next in line...

Yes Skewer quick let's panic ! VERIFIED RUNAROUNDLIKEHEADLESSCHICKENS It's a bad decision but I am afraid you'll have to respect drivers decision :)

In response <asa@mozilla.org> thought it would be cute to remove my permissions for speaking my mind. That's very mature. </sarcasm>

Skewer, I haven't touched your bugzilla permissions. Claiming that I did and attibuting it to a disagreement of some kind in a bug is completely inappropriate. I'd like an apology.

It's obvious that this was done as a response to my support of this bug, as everything worked fine last night. I don't see any valid reason why they might have been removed. I'd prefer to wait until I know who is responsible for this before I credit you with innocence. Who else controls the permissions on Bugzilla?

Pretty much any big name on the project does. I don't agree with that anyone took permissions from you, but that _was_ pretty uncalled for, IMHO. I may not like the changes either, but I've made my complaint in a dignified way and have decided it's in my best interest with the project to bide my time with the Powers That Be, at least for the present time.

I'm very dissapointed that the big heads of Mozilla care more about their module owners than 99% of their users. I have now stopped evangelizing mozilla since it is no longer a standards-comliant browser, and I will stop helping Mozilla in every other aspect as well. Asa, you if anyone knows exactly how much the majority of Mozilla users hate the implementation of marquee, and I have lost all respect I previously had for you because of this. Mozilla is 100% dependent on their users, and they let them down like this. It's very sad.

supporting marquee does not make any browser less standards-compliant. sure, it is annoying and should be removed, but fact is that mozilla is still as standards-compliant a browser as before the marquee checkin.

Christian, supporting marquee does not remove the standards support mozilla has, correct. But it adds a non-standards tag to mozilla which is almost equally bad. It gives webdesigners the wrong signal - that it's ok to use non-standards tags.

André: as <td background=""> and many more. If you really only look at the standards, you have a browser like Amaya, which renders more or less no "real" page out there. The only valid point is that it is (if can be) anoying. For that, we have a pref-bug. Why aren't you in strike to get <blink> out, which is even more anoying (and can't break any layout, if disabled)?

Thing is, a lot of these people want to be pedantic about standards compliance, for fear of the many messes back in the days of all the different bloody incompatable extensions (<layer>, anyone?). Rather than wanting this to be additive where we meet and exceed the standard (that still sounds too "embrace and extend" for my liking), these people want strict adherance, with any deviance approved of on Form 3190Q-A and in triplicate. Though with the history of the web before MSIE becoming king of the hill, can you really blame them?

Kai, you have to pick your battles. Mozilla supports several non-standards things in quirks mode, but why should it support it in Standards Compliant mode? Isn't the whole point of Standards Compliant mode to render the page according to standard, and nothing else?

I really don't see why people object to marquee so much more than blink, or the fact that we imitate so many tiny formatting details exactly despite that HTML is supposed to be semantic markup (which I think, frankly, is far worse for the web than either). However, to the people who are "on strike", etc.: please note that a *good* patch to make marquee an optional extension would, I think, be accepted. The module owners have not rejected that approach. They also haven't rejected the idea of a pref to disable marquee (bug 161109). However, the optional extension idea hasn't even been filed as a bug, despite comments in bug 156979. All the controversy has centered on the remedies that have don't make sense -- it doesn't make sense to remove it because some distributors / embedders of Mozilla intend to distribute this (and probably will whether we have it in the tree or not), and the quirks mode doesn't make sense for reasons I described in bug 159839 comment 28.

and how did it go that time? Browsers added new features, if they are good enough, others did too, else they died (somebody ever seen a page using <multicol> or <spacer>?). Also W3C added the good ones. something has changed since, first authors now only look at one browser and second the W3C doesn't add any more layout ideas to (X)HTML. The Quirks mode is for - read exactly: "changes from the behavior written in the Standards, that whould break the display of _valid pages_.", so <marquee> has _nothing_ to do with that, as there's no change for a valid page. Also please remember, that the behavior on <marquee> as in the HTML4 standard writen ist not "ignore", it's _undefined_!

The important point is that marquee support is against the will of the majority of mozillas users.

Filed bug 163048, "Make marquee an optional extension".

IMO, it's the responsibility of people adding grossly unpopular stuff to make it optional, not the responsibility of disagreeing people to clean up afterwards just to keep having a useable browser. I do hate blink and pixel formatting, but that can be considered legacy-crap. Here, we are *adding* another bit of major crap, and even in standards mode. Would a patch to remove the <marquee> definition from html.css be accepted?

This backs out the marquee support (and does not compile any of the marquee code). I cannot delete the (unused after the patch) xbl-marquee directory, since that is beyond patch's capabilities. If I missed anything with this patch, let me know. I compiled and tested with it, and it has no side effects that I noticed.

I have hacked xbl-marquee.xml to provide scrollbar instead of automatic scrolling. This is only a "hack", but you can use it just now to disable annoying behavior of <marquee>. Please, test it. For details see http://bugzilla.mozilla.org/show_bug.cgi?id=163048#c5

verified. see bug 163048.