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?

Please read: Bug 156979 comment 30 Bug 156979 comment 38 Bug 156979 comment 48 Optional reading is Bug 156979 comment 29

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.

verified wontfix

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

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

Lets vote for it!