Closed Bug 159839 Opened 22 years ago Closed 22 years ago

move <marquee> into quirks mode

Categories

(SeaMonkey :: General, enhancement)

Product:
SeaMonkey
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: Matti, Assigned: doronr)

References

Details

(Whiteboard: Tough Luck, move along.) 

The recently added <marquee> should not be supported in the Standards compliance
mode.
marquee is no w3c-standard and i can't believe that mozilla supports it !

It would be o.k. for me and many other people if Mozilla supports it in quirks mode 
(and possible also in the "near Standards compliance mode")
Though I personally agree with this bug, I believe it has been decided that only
things which would otherwise make standards compliant pages break goes in quirks
mode... Hixie?
I think that Mozilla has the purpose.
1. Web Standard support.
2. Web site browsing.

This problem is in order to support 2.
But Such a site is rendered on Quirks mode.
See Bug 156979 comment 63.
There are marquee used site list and all web site are rendered
Quirks mode.

There is Standards Mode for 1.
If MARQUEE is supported by Standards Mode,
this cannot be called state good for Web Standard.
Have you read the comments I cited?

Basically, people pushing for this had better be willing to _personally_ fix all
marquee-related bugs in _both_ modes that appear because of insufficient testing
in one mode or the other.

Again, standards mode is the mode in which we do not violate any standards.  It
is not the mode in which we support nothing but the already existing standards
(should we remove DOM3 support in standards mode?  Should we remove CSS3 support
in standards mode?  Should we remove innerHTML in standards mode?  Should we
remove support for <meta http-equiv="refresh"> in standards mode, since that's
not codified in any standard either?).
(Bug 156979 comment 48)
> The CSSWG has been requested to add 'marquee'-like abilities to CSS,

The only way acceptable is to support marquee-like css with "-moz"
extension. And I don't think <marquee> is "innovation".
The Original extensions do not violate any standards?

Why do mozilla have any syntax sugar in Quirks mode only?
If it goes by your theory, what is this difference?

We sent mail to Japanease website master for mozilla will be supported,
if the website was no standards. 
We have performed the activity over one year.
The reason as which Mozilla has not displayed these,
because Mozilla did not have some syntax sugar by the reason for 
being contrary a standard.

But, this problem is "not violate any standard",
Mozilla should support all IE's syntax sugar support.
Of course, I don't want to be such browser.
But, Mozilla must support any syntax sugar by your reason.

Momoi-san.
If this problem Resolution is INVA,
We cann't continue Japanease website test project.
Because Mozilla don't support syntax sugar which reason is
Mozilla's BUG in his reason....
The rationale for implementation of marquee tag seems to be that it is an
extension  rather than going against standards. But as an extension to style it
is something that in future is likely to have standards through css. That
implementing this would give first hand experience for the csswg discussions was
given as a reason for putting it in by default. 

When standards to implement marquee-type styles by css are agreed, standards
mode will either have to remove support for <marquee> in html or be doing things
by violating the future standards. I think it should only be in quirks mode from
the start - or in any milestones. 

There can't be many sites to test that declare themselves as standards compliant
but use marquee tags although if mozilla supports it in standards mode - there
could be.

I think Mozilla may support marquee.

Mozilla's behavior currently seems consistent like this:
|--------------------------------------------------------|
|                      |            spec def.            |
|                      |---------------------------------|
|                      |yes             |no              |
---------------------------------------------------------|
|doctype|yes           |obey standards  |obey precedents |
|       |--------------|----------------|----------------|
|dcel.  |no            |obey precedents |obey precedents |
|--------------------------------------------------------|

In this case, there is a doctype declaration. and Mozilla try to obey standards,
but marquee is used against doctype decl.
There are no spec definitions about this error, so Mozilla may obey precedents.

http://www.w3.org/TR/WAI-WEBCONTENT/#gl-movement
  The BLINK and MARQUEE elements are not defined in any W3C HTML
  specification and should not be used.

<marquee> emulation is only a backwards compatible feature,
not "innovation".

And this makes the element's content hard to read in many cases.
cf. Bug 159932, Bug 161049.
These problems are against "If a user agent encounters an element it 
does not recognize, it should try to render the element's content."
http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.1

This should be moved to quirks at least.
See bug 161049 for a much better solution.

I don't think it makes any sense to move marquee into quirks. If we did that,
the decision for whether or not to have a marquee would still be up to the
author; if he wants to force a marquee down the viewer's throat he can just
change the DTD. Certainly marquee should not be supported in standard mode, but
we shouldn't leave it alone in quirks.
We should additionally add a -moz-marquee CSS property, as this is planned for
CSS3, according to Bug 156979 Comment #48 (Hixie).

In full-standards mode, I think we shouldn't render either <blink> or <marquee>
as this clearly breaks HTML W3C standards (See Bug 156979 Comment #64 and
http://www.w3.org/TR/html401/appendix/notes.html#h-B.1). We should simply ignore
those tags, rendering the contained text as inline text.

If we get an HTML 4.01 Strict DOCTYPE, we should support only the HTML 4.01
Strict tag namespace and no other tags, IMO.
Quirks mode is for when we have to deviate from standards in order to support
existing pages.  <marquee> is an allowed extension rather than a deviation from
a standard, so making it a quirk would only discourage use of strict doctypes.
kairo: Absolutely not, we can't be adding a new CSS property ahead of the W3C.
Especially not for marquee.
Skewer: we can do this and we have this already
Jesse:
From how I read the sources in my last comment, adding additional tags to an
HTML document is a deviation from standards, as this is explicitly nit allowed
by the standards definition.
Additionally, I personally think we should ignore all tags that are not in the
DTD, if the DTD is explicitely given with a URL in the DOCTYPE line. That way,
when the "correct" HTML 4.01 Strict DTD is given (.../strict.dtd), we shouldn't
only ignore <marquee> and <blink>, but also <center>, <font>, etc.

Skewer: we already did this a few time, and, AFAIK, we're still doing this in a
few CSS3 cases...
Well, if I see even one document out there with moz-marquee CSS in it, you might
as well find a madhouse with a vacancy ahead of time.

This is something we do NOT want happening. Especially in standard mode.
Skewer, if you personally do not like marquee, just friggin disable it in your
browser.  You can do it for our current implementation.  You would be able to do
it for -moz-marquee, if such a thing existed.

"I don't like it" is not a useful criterion for whether features should be
included in a product.

I have yet to see you make a coherent statement on this topic.  For that matter,
I have yet to see you make a statement on this topic that did not raise the
image of you, red-faced, with spittle flying from your mouth, on a street corner
in New York, preaching Hellfire and Damnation.

Calm down and try not to sound like a zealot who believes that there is no god
but W3C, which is infallible.  It's fallible.  Witness the long lists of errata
to the various specs (CSS2 is a great example of this).
(Also note that the W3C prefers declarative animation to script-based animation.
 See SMIL.)
I'm sure there are plenty of people in the sidelines who agree that marquee is
the most ridiculous move Mozilla has ever made, period. Don't be ridiculous or
resort to name-calling, as you are right now, because I'm the one who's speaking
rationally - we can NOT add new CSS to the browser and encourage webmasters to
use it! This is the same rationale that ian used to shoot down all of my
persuading to get Mozilla to support image placeholders, it would be
hypocritical of you to abandon that mode of thinking now. If you're going to
tell me now that Mozilla is *not* a standards browser, please reopen every bug
I've ever made on ALT text and image placeholders because apparently a change
has been made without my knowledge.

Furthermore, AFAIK, there is *no* way to disable marquee without hacking into
the browser files. At a bare minimum, there needs to be a pref. I shouldn't have
to rebuild the browser or hack data files to get rid of something that shouldn't
even be there to begin with.
Who said we're encouraging webmasters to use this, first of all?  I don't see us
doing it...

Mozilla supports image placeholders.  I'm not sure what your point there is and
more to the point, I don't see how it's hypocritical for _me_ to think
differently from _Ian_.  Did you really say what I think you said there?  That
anyone involved with the Mozilla project has to be of the same mind on all
issues at all times as everyone else involved with the Mozilla project?  That's
a tall order my friend.  Not gonna happen.

I will repeat one more time for your benefit.  Mozilla is a standards-compliant
browser.  If there is a standard for a web-related technology, we strive to
support it.  Many Mozilla developers also feel that we should strive to make the
web a better place for users.  This is related to, but not identical, to the
standards support issue.  Now in cases when there is no established standard,
trying to "support standards" does not get you very far.  In those cases, you
have to decide on something and just do it.

Now let me quote from the HTML 4.01 specification [1]:

   This specification does not define how conforming user agents handle general
   error conditions, including how user agents behave when they encounter
   elements, attributes, attribute values, or entities not specified in this
   document.

   However, for recommended error handling behavior, please consult the notes on
   invalid documents. [2]

Now these latter notes _recommend_ (not require, but recommend) that

   If a user agent encounters an element it does not recognize, it should try to
   render the element's content.

which is one of the most vague sentences I have ever read.  The presence of
"try" (what if we "fail"?) aside, it does not say what it means by "render".  We
could pop it up in a pop-up window and that would be in agreement with that text.

So let me summarize.  We have the goal of supporting the HTML4 specification. 
We would be completely conformant to this specification if we crashed whenever
we saw a tag that was not in that specification;  we would be completely
conformant if we just delivered a parse error and refused to render the page; we
would be completely conformant if we erased the hard drive after sending all the
user's data to the website, because the error-handling behavior is UNDEFINED.

OK.  So now that we have established that compliance with the letter of the
specification is a non-issue, that leaves only compliance with the spirit and
practical considerations.  The latter strongly dictate that we should implement
<marquee> (low effort, high reward, bigger user base, more people using a
browser that will render a page that follows standards _correctly_).  As for the
former, that is a decision that would be much harder if we did not already
support a huge number of tags that are not in HTML4, as well as doing parsing
that is completely bogus per the HTML specification.  I would much rather we
remove our support for <nobr> (which is quite difficult to implement, has very
odd behavior, and is a very odd beast from the point of view of CSS) than remove
support of <marquee> (which is a perfectly good replaced element from the point
of view of CSS).  Why do I see no one screaming for <nobr> removal?  Why has
there been no screaming about it over the years Mozilla has supported it? 
Netcape 4, Opera, etc. all support it, so that makes it suddenly OK?

I agree that we should have a single pref in our advanced UI that disables
<blink> and <marquee>.  Feel free to implement such a pref.  No one's stopping
you.  I'm fairly certain that it would be accepted.

A note on adding CSS properties.  Perhaps you missed the fact that those Mozilla
developers who are members of the CSS working group _explictly_stated_ that the
CSS working group is considering adding this to the specification.  Given that,
there are two possibilities:

1)  We have experience implementing a <marquee>-like thing and can block the
    standardization of aspects of <marquee> that are hard to implement in
    user-agents other than IE.
2)  IE's implementation is standardized as-is, since it's the only thing the
    working group has to go on.

Consider carefully which of these would be better for Mozilla, for the web in
general, and for your neighbor's pet rat.

In conclusion (and this part has nothing to do with Skewer's argument), as far
as I can tell all this screaming is going on about <marquee> due to two reasons.

A)  It's something IE does so it must be bad.
B)  It's something that could be annoying, so it must be bad.

I won't bother to comment on the former of these (the words "childish" and
"immature" spring to mind).  The latter is a quite valid reason in my mind.  So
I took the time to go and _look_ at these alleged chinese sites that use
marquee.  On almost every single one I looked at, the marquee text moved quite
slowly.  A few of the marquee's were actually quite aesthetically pleasing; much
more so than other parts of those pages.  So yes, this can be abused.  So can
anything else which has any conceivable utility....  think on that.

[1]  http://www.w3.org/TR/html401/conform.html#h-4.1
[2]  http://www.w3.org/TR/html401/appendix/notes.html#notes-invalid-docs
> Who said we're encouraging webmasters to use this, first of all?  I don't see
> us doing it...

The mere fact that such a CSS exists will become known, and webmasters will
start (mis)using it. This isn't bad until you take into account the sites that
will still have -moz-marquee when the CSS3 specification comes out.

> Mozilla supports image placeholders.  I'm not sure what your point there is and
> more to the point, I don't see how it's hypocritical for _me_ to think
> differently from _Ian_.  Did you really say what I think you said there?  That
> anyone involved with the Mozilla project has to be of the same mind on all
> issues at all times as everyone else involved with the Mozilla project?  That's
> a tall order my friend.  Not gonna happen.

Not in standard mode, in standard mode the ALT text flows with the text. I don't
expect total agreement about everything, but I also expect there to be a general
consensus on what is acceptable and what isn't. If some of the component owners
designed to standards, and some refused to touch them, it would be total chaos,
wouldn't it? Ian's idea of an ideal browser appears to be something that
educates webmasters to build websites that cater to Lynx and audio browsers at
the expense of functionality. Yours and David's appears to be one that has all
the nifty features that can be crammed under the hood no matter how annoying
they are or how naughty of habits they have the potential of encouraging. Right
now I'd be interested on hearing what Ian has to say about this -moz-marquee issue.

[Standards stuff omitted]

There's nothing wrong with adding new CSS or HTML tags to support functionality
that's worthwhile. You can't expect browser authors to wait for W3C's okay to
implement new functionality; that would hinder progress unnecessarily. But this
deserves an exception. Come on, it's marquee! Adding the marquee tag satisfies
webmasters who already use it. Adding new CSS for the same thing is irresponsible.

> 1)  We have experience implementing a <marquee>-like thing and can block the
>     standardization of aspects of <marquee> that are hard to implement in
>     user-agents other than IE.
> 2)  IE's implementation is standardized as-is, since it's the only thing the
>     working group has to go on.

Of course there should be some work on supporting a CSS property and finding out
how it behaves in Mozilla. There's no need to leave it in the public builds!
This kind of work belongs behind the scenes.

> In conclusion (and this part has nothing to do with Skewer's argument), as far
> as I can tell all this screaming is going on about <marquee> due to two reasons.
>
> A)  It's something IE does so it must be bad.
> B)  It's something that could be annoying, so it must be bad.
>
>I won't bother to comment on the former of these (the words "childish" and
>"immature" spring to mind).  The latter is a quite valid reason in my mind.  So
>I took the time to go and _look_ at these alleged chinese sites that use
>marquee.  On almost every single one I looked at, the marquee text moved quite
>slowly.  A few of the marquee's were actually quite aesthetically pleasing; much
>more so than other parts of those pages.  So yes, this can be abused.  So can
>anything else which has any conceivable utility....  think on that.

Most of us don't go to Chinese sites. Most of us go to people's personal sites.
These are people who happen to think scrolling marquees, blinking text, and
spinning at-signs for e-mail are the coolest thing ever. I don't want to see
that kind of garbage when I come across one of these sites. Mozilla should allow
a certain level of control to the viewer, for accessibility and comfort reasons.

The fact that MS created it is irrelevant; I would theoretically love BLINK
because it's a Netscape creation if that were the case. Microsoft has been
innovative at times; adding privacy controls, supporting .cur files in the URI
for CSS2 cursors, etc. But marquee deserves an exception. It's annoying, and in
most cases it's only used to add non-tasteful animation to a site. The fact that
some of you think it's worthy of a publicly available Mozilla CSS extension is
comical.

Failing any request for marquee support to be removed entirely, I think it would
be best to

1. add a pref and put it in the UI to remove marquees, and
2. support only the HTML tag until W3C says otherwise.

Or, if you'd like, we can start burdening the Tech Evangelism workers with every
site that misuses <MARQUEE>.
I'm not sure why -moz-marquee being around when CSS3 comes out is a "bad
thing"....  I see no obvious relationship between the two.  Clarify?

Expecting consensus from a group of 100+ people is never a good idea... As it
happens we have precisely the situation where some components care about the
standards (and quirks vs. standards divisions) much more than others.  Compare
the style system to the parser, for example.  This is not to say that the parser
does not care about standards.  It's just that when standards and rendering lots
of webpages come in direct conflict the parser usually chooses to render the
pages.  Even in standards mode.

I won't speak for David, but _my_ idea of an ideal browser as a _user_ is that
it should let me view the sites I want to view.  Period.  I care for nothing
else from a user perspective.  As a web developer, my ideal browser is one that
renders my pages (written to the standards) as I want them rendered (according
to said standards).  What it does with invalid markup is of little concern to me
as a web developer. I don't care about browsers in and of themselves; they are
tools to get something done.

If you want to know what Ian has to say on the -moz-marquee issue, maybe you
should have bothered to do some reading.  Bug 156979, comment 48.  Bug 156979,
comment 51.  Bug 156979, comment 72.

In case you missed this, the _absolute_majority_ of the uses of <marquee> on the
popular Chinese sites in question are _not_ annoying and are in fact quite
aesthetically pleasing.  The fact of the matter is that this is apparently a
common mechanism for displaying text in China even when one is not talking about
the Web.  Not adding a feature to a language just because some self-centered
Americans do not see a use for it would be irresponsible.  Why not drop support
for encodings other than ASCII while we're at it?

Thre is no "behind the scenes" here, my friend.  This is an open source project.
 Every single build we ship has big disclaimers on it that it is for testing
purposes only.  Mozilla distributors, who are the ones providing actual users
with a browser to use as opposed to a browser to test, could very well turn off
marquee before shipping.  Take that argument to them.

I realize that you do not go to chinese sites.... and there are millions of
people in China who do.  I do not know who these "us" you speak of (and for)
are, but surely you must be excluding these people (some of whom _are_ using
Mozilla, and more of whom _could_ be).  

We agree that Mozilla should allow control for the viewer.  We keep agreeing on
that.  Yes, there should be a pref.  Feel free to implement it; otherwise it
will have to wait until someone else has the time to do it.

Sites that misuse marquee are hardly Evangelism and your "threat" is pretty
pathetic.  Just like a site that has ugly colors is not going to be evangelized,
neither will a site that shows poor taste by using an ugly marquee....

So other than the fact that we need a pref for this (which we do) do you have a
point?

some corrections:

the W3C has not even a draft for marquee, the only think if the might add such a
thing some day (see the CSS3 box model module, property overflow), there's this
comment.

<nobr> is <span style="white-space:nowrap;"> as of CSS2.1, the property now
applies to all elements, not only block.

we have a bug for the pref and a bug for disabling <marquee> at all. There's no
visible benefit for the users to move it into quirks mode.

most arguments here are also valid for many other elements, like <table
bordercolor="" height="">, <td background="">, <nobr>, <blink> and maybe some
more I missed right now and _all_ are valid for <blink>, which not only can be
anoying, but is 100%.
Kai:

> most arguments here are also valid for many other elements, like <table
> bordercolor="" height="">, <td background="">, <nobr>, <blink> and maybe some
> more I missed right now and _all_ are valid for <blink>, which not only can be
> anoying, but is 100%.

Right. That's why I came to the conclusion that we should ignore all tags not
defined in the given DTD (in a strict DOCTYPE), if the DTD is explicitly
specified via a URL (e.g. "http://www.w3.org/TR/html4/strict.dtd"). This sounds
to me like it would be the right thing to do.
If web designers want to use arbitrary extensions, they can always use a
transitional DOCTYPE. If they use a strict one, they can be sure we only follow
the given DOCTYPE, and nothing else. If they mistakenly put a "non-existing" tag
into their markup, they'll see that there's something wrong simply by viewing
that markup with our browser.
Additionally, we should spit out an error message in an error console, as we do
currently with JavaScript errors.
Robert: you can add that maybe as an option - if you really do, whatever the
used DOCTYPE says, you'll have maaany more TE to do. File a bug for an Option,
where the Browser belives the DOCTYPE exactly, if any URL to a DTD is given ;)
> There's no visible benefit for the users to move it into quirks mode.
I don't think so
As Boris said/quoted:
    If a user agent encounters an element it does not recognize, it should try
    to render the element's content.

What's the best mozilla can do if it sees a <marquee> ?
- Hiding this text? This would be very bad
- Ignoring marquee and just printing the text out as it is (like NS 4 did it..)?
Of course that's better than hiding the text, but a marquee with a LONG text
looks VERY UGLY (and can 'distroy' the layout).

So the best that mozilla can do is to render the marquee tag like the IE does.
Of course it's not a standard tag, but it isn't a very dumb tag (just see how
many people are 'emulating' marquee with java script!) and it's used on many
pages! Not on US or European pages.. but (as boris said again :) ) it's often
used on chinese pages..

and mozilla is no end user product.
Everyone who distributes a mozilla-based browser can turn marquee of.
Why you want to implement <MARQUEE> tag?
To gather more user in China?
I think that it is bad idea.

Even if you implement <MARQUEE> tag, those user will not change their browser to
Mozilla. Even if you implement <MARQUEE> tag, those users will not think that
Mozilla is better than IE.
Many users don't care about the details of a browser. Many users are satisfied
with the present condition. And many users hate something that is takes time and
effort. 

I think that Mozilla should not gather more users by such way.

Implementing only discourages the present user.

...sorry for my bad english.

Unless we actually know how to parse DTDs and verify that what we think is
appropriate for standards mode actually corresponds to the exact DTD that the
author is using, we shouldn't be omitting support for certain elements.  Doing
so would be likely to create two problems (the second of which would exist even
if we did know how to parse the DTDs):

 1. Forward-compatibility would be broken with future DTDs that might include
something we're excluding in our strict mode, for example "XHTML 3.0, 2.0
Compatible".  Sniffing for the word "Transitional" or "loose" in a DOCTYPE
declaration is not an acceptable workaround for this.  Future FPIs and system
identifiers (as URIs) need not maintain the naming used in HTML 4.0 and XHTML 1.0.

 2. We'll be discouraging authors from writing pages that trigger strict mode. 
It's pretty easy for an author to tell whether they're using elements that are
in the DTD they use (via an HTML validator), but it's a lot harder for them to
tell if the browser's they're using to test are doing the right thing with those
elements (and the CSS, etc.).  It's thus best for the web if we display valid
documents correctly in as many cases as possible.  The important difference
between strict mode and quirks mode is that in strict mode we display valid
documents correctly, not that we choke on invalid ones.  Beyond that, adding
additional differences requires additional engineering effort, additional
testing, and leads to additional bugs that are in one mode but not the other
(remember the "standards mode" form controls?).  Discouraging authors from using
quirks mode by removing support for certain elements means that those authors
won't get to see the correct behavior of the parts of their page that are valid,
and thus it will require that incorrect support for valid documents continue to
be the standard on the web for a longer period of time in the future.  (Stricter
error-handling in SGML-based HTML is hopeless, considering the stuff that passes
for HTML on the web today and the need for a web browser to be able to browse
the web.)
Since this bug is "move <marquee> into quirks mode" and not "add -moz-marquee to
CSS" I will not discuss this -moz-marquee nonsense further. If you want to try
to add such a property to the browser create a new bug; then it will be tested
on its own merits and will be more likely to be rejected, as it should be.

Back to this bug, I think that as long as marquee is supported, it should work
in both modes (largely for the reasons already given). But of course my stance
is that it should work in neither, and the voices of reason on bug 156979 agree
with me. See bug 161049 for a summary of the argument against having <MARQUEE>
in the browser and enabled by default at all.

But as I've said, I think that this bug as it is written should be WONTFIX,
since it would create a nasty fork and discourage strict mode. You'll find that
stubborn web authors love their scrolling marquees more than they love Mozilla
and W3C standards.
I don't really understand why this debate isn't focusing on the central issue:
that it seems madness to re-introduce stylistic markup to modern HTML when so
much effort has gone into removing it. It seems insane to me to have all the
beauty and wonder of HTML 4, which has a great separation of content from
layout, and then turn around and say 'Oh, why not have one *entirely*
layout-based tag in our spec'. 

So basically, if we're going to support this tag at all, please keep it out of
HTML 4, at least in standards mode, because people need to be writing their
pages in terms of content, and only delving into layout in their CSS pages.

One question, that hopefully someone can answer: if this stays in, how long will
it be supported for? Are outdoor store websites going to find that their tents
scroll just because their XML has a <MARQUEE> tag defined in it?
Only if their XML put this marquee tag into the XHTML namespace.
> What's the best mozilla can do if it sees a <marquee> ?
> - Hiding this text? This would be very bad
> - Ignoring marquee and just printing the text out as it is (like NS 4 did 
> it..)?

- Displaying it as a div with style: "overflow: scroll" . So the user has
control over how and when it gets scrolled, but it doesn't break layouts.

This would be an _improvement_ on the IE handling of this tag. So if we're
looking for a good web experience, rather than IE emulation, we should be doing
that.

Gerv

overflow: scroll; would be a decent solution, but it would almost certainly
involve drawing a scrollbar widget around the marquee. A better solution would
be for the contents to just sit there, and the user can scroll it by dragging it
around (similar to the way the "hand" cursor works in Acrobat).
As QA contact for this change, and based on
http://bugzilla.mozilla.org/show_bug.cgi?id=159839#c28, 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
verified wontfix
Status: RESOLVED → VERIFIED
Marquee is so obviuosely somthing that Mozilla.org has been told to do, by AOL
or they will cut finding LMFAO
Or to increase site compatability
Whiteboard: Touch Luck, move along.
Whiteboard: Touch Luck, move along. → Tough Luck, move along.
doron@netscape.com

Says an AOL-Netscape employee.
stop spamming my bug. I don't like marquee but you will never change this stupid
decision with your comments.

Thanks
Product: Browser → Seamonkey
Lets vote for it!
You need to log in before you can comment on or make changes to this bug.