Closed Bug 161049 (killmarquee) Opened 22 years ago Closed 22 years ago

Remove scrolling marquee support

Categories

(SeaMonkey :: Build Config, enhancement)

Product:
SeaMonkey
Component:
Build Config
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: SkewerMZ, Assigned: doronr)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: DO NOT COMMENT unless resolving/patching/reviewing a patch)

Attachments

(1 file)

Back out marquee support
6.44 KB, patch
Details | Diff | Splinter Review 
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?
Alias: killmarquee
Keywords: 4xp, nsCatFood
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>
URL: http://www.hicom.net/~oedipus/wai/ua/...
-> 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.
Assignee: Matti → doron
Severity: normal → major
create a patch to make it an extension. I've said this over and over again.
Severity: major → enhancement
Component: Browser-General → Build Config
Keywords: helpwanted
Whiteboard: DO NOT COMMENT unless resolving/patching/reviewing a patch
You broke marquee's heart, he's now in the bathroom crying.  I heard he's
planning blinking marquee for revenge
Keywords: 4xp, nsCatFood
Depends on: 159839
This should be a pref instead.
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.
Keywords: nsbeta1, nsCatFood
>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 :)
Keywords: nsbeta1, nsCatFood
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
I don't agree with WONTFIX.
Status: RESOLVED → REOPENED
Resolution: 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.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
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.
Keywords: patch, review
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.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: