Need to add optional XBL emulation of marquee. A huge number of top web sites in China rely upon the non-standard HTML <marquee> tag. Because IE currently has 99% market share in China, efforts to evangelize these sites to use W3 standard compliant alternatives have been unsuccessful. In order to make Gecko-based browsers acceptable and successful in China, we have developed an XBL emulation of the <marquee> tag. There are 2 Gecko-based products which need this for Chinese versions. Other Mozilla/Gecko based applications may also want/need this feature when deploying to China. However, we do not want to encourage the use of the non-standard <marquee> tag, so we want to make this feature an optional extension. The standard Mozilla (including MachV) and embedding builds will not include the marquee support. However, the build system should allow this to build option be easily enabled for builds that require it (e.g., Chinese Gecko-based products). The changes required: * appending an two rules to res/html.css for marquee, and * including xbl_marquee.xml (the XBL implementation of the <marquee> emulation) All new files would be checked into a new directory: mozilla/extensions/xbl-marquee/ Changes to other existing makefiles will be wrapped with !if defined (XBL_MARQUEE) ... !endif and by default XBL_MARQUEE will not be defined and such that the default builds will be unaffected.

99% MSIE in China where it sometimes looks as there would be no Windows allowed? ;)

Again, this will NOT be built by default.

-> build config

topembed. Assigned to yokoyama. Cc'ed momoi.

afaik you need approval from staff@mozilla.org or their proxy to add extensions, please be sure you have this. (leaf?) this is an enhancement, if you want to indicate that it's important, please have your assignee set its priority and target milestone to indicate its importance.

If this is implemented, we should consider putting the parser changes we made to support <marquee> inside an #ifdef XBL_MARQUEE

boris: can you point us to the parser changes you are referring? Thanks

doron's latest contents.rdf

doron's latest marquee.xml

I assume Comment #6 > If this is implemented, we should consider putting the parser changes we made to > support <marquee> inside an #ifdef XBL_MARQUEE refers to bug 154173, Make marquee a block element to not break site layout That fix should not be #ifdef XBL_MARQUEE because it makes the parser treat marquee tag as a block, so the rest of the page is displayed correctly even if the marquee tague is ignored.

fixes some whitespace and removes commented out code

For Mozilla-based clients (vs. Gecko-embed clients), there will also need to be some changes in mozilla/xpinstall/packager/ to create the XPI installer for an optional component which would install the XBL marquee files.

setting the priority and the milestone.

Where's the patch to html.css? Why wouldn't we want this on by default and not any kind of extension? /be

> Where's the patch to html.css? Here's the additional rules: /* marquee rules to be appended to res/html.css which * provides emulation of non-standard HTML <marquee> tag */ marquee { -moz-binding: url('chrome://marquee/content/marquee.xml#marquee-horizontal'); } marquee[direction="up"], marquee[direction="down"] { -moz-binding: url('chrome://marquee/content/marquee.xml#marquee-vertical'); } > Why wouldn't we want this on by default and not any kind of extension? There were some who felt adding this support would be contrary to our evangelism efforts to get sites to comply with open standards. I'm open to making it the default. Let's hear from others.

Cc'ing some evangelism folks for their thoughts on supporting <marquee> by default in Mozilla. /be

CC'ing additional folks who expressed their opinions on this issue earlier.

I must admit that I am not enthused with the idea of supporting marquee by default in Mozilla although I can see the viewpoint where is might be considered desirable. The major practical obstacle which was performance appears to have been resolved. As long as CPU utilization is no longer a factor, I see no absolutely compelling reason to not include XBL Marquee in Mozilla. I have debated whether to comment at all in this bug. In the end, I have decided to get it off my chest so please take the following in the cooperative spirit it is intended. Supporting marquee does some degree of disservice to the standards movement and to other browsers which attempt to be standards compliant. By supporting marquee we promote the use of a tag which will only work in either IE or Mozilla. XBL marquee began due the large number of sites in China which appear to have a fetish for marquee. At first the approach was to create a DHTML JS object which could be used to reproduce the behavior of marquee. This was accomplished using a mix of standard and non standard techniques in order to support as many browsers as possible. The benefit of the DHTML solution was that it potentially allowed other browsers to be supported. Once the DHTML marquee object was available, several people considered the possibilty that it could be used as a basis for creating an XBL implementation of marquee. If such an implementation of marquee was available in Chinese clients, then a major evangelism issue would 'just go away'. XBL marquee was not originally intended to be included in Mach5 or Mozilla. Now, since it is available, we are faced with the choice of whether we should include XBL marquee in Mozilla by default. Some might argue that this is a 'horrible' thing to do to a standards based client such as Mozilla and to a certain extent I agree. However, we do already support a number of very useful IE proprietary extensions especially with regard to the DOM HTML and DOM Style. In fact, the standards alone do not make for an easy authoring environment. The real question is "How far do we go in emulating IE ?". Since I became involved in Mozilla evangelism in December 2000, it seems that there is a common reoccuring sequence of events. At first the 'purist' view holds the floor and states that implementation of non-standard features is not considered a possibility. Evangelism is then faced with communicating with and helping sites to implement the desired functionality using standards based approaches within the limitations of our own implementation. As time progresses and the number of sites which are affected is better known, the 'practical' view holds the floor and the non-standard features are allowed into Mozilla to increase compatibility. This is not inherently bad. The bad part is this 'creeping compatibility' *can* undermine our credibility. Consider a business who does listen to us and spends thousands of dollars (or more) upgrading their site to support us. Remember, due to many reasons, supporting us usually means using non-standard extensions anyway. Now suppose that a year later, we decide to change our minds and implement the non-standard features this business was using. If I were the owner/manager/web developer of such a business, my lesson would be clear. 1) I wasted my money updating my site. 2) I did not recupe my investment due to Mozilla's market share. 3) Mozilla will change if I wait long enough. 4) Mozilla is difficult to support due to it's ever changing compatibility with other browsers (and it's earlier versions). So I want to ask everyone here to think about and make a decision on what we plan to support in terms of compatibility with Internet Explorer and Navigator 4. Let's think this through now and stop making these decisions in a piecemeal fashion. "And that's all I have to say about that."

bclary, thanks. I agree, and I'm stirring the pot harder by cc'ing Hixie. Ian, you have the floor. If we need to take this to a newsgroup, that's cool, but I think so far, this bug is the place for a civil, ordered, non-repeating debate. /be

Two additional reasons Mozilla should not support <marquee> by default: - It would pages containing the <marquee> tag harder to read in Mozilla. Moving text that "scrolls off" is hard to read and hard to click, and it distracts from other text on the page. - Legitimizing the use of <marquee> would make the web harder to use for users of other browsers, whether those browsers support <marquee> or not.

I think we should give users (even in China) the possibility to use Mozilla or Netscape without haveing this anoying thing. So make it a user-option in the scripts&windows section to disable <marquee>, disable it always, if JS is disabled (to remove this argument to prefer <marquee> over a real JS construction and set a waring about this comptibility hack in the JS Console (as we do with broken CSS files). The <marquee> should be disabled as default (except in Chinese Gecko browser versions..)

The prefs dialog should contain useful prefs, not apologies for misfeatures, and I'm getting a little tired of having to stand on guard to keep such detritus out of the Scripts & Windows panel in particular. In my opinion, an option for MARQUEEs would be useless, since users (as opposed to Web authors) would never want to turn it on. In my experience, pages containing MARQUEEs consistently display more pleasantly in a browser that does *not* support MARQUEE than in a browser which does. But I don't read Chinese. Are there any marquees for which this not the case? Are there sites which sulk and block Mozilla entirely because of its perfunctory marquee {display: block}? See also bug 80269 comment 2.

I also think there should be no new user-visible pref. I further agree that marquee should not be supported by default. The question then, assuming others agree, is how to let vendors who feel the need for it configure support for it. I can't believe those vendors hand-munging a forked version of html.css is the right answer. /be

Maybe this comments are stupid, but: Shouldn't this binding be added to quirks.css instead of html.css? And having it working as a binding, if a user doesn't like marquees and his distributor has enabled them, couldn't it be turned off using something like marquee { -moz-binding: url(none) !important; } in his userContent.css?

For what it's worth, I think marquee should not be supported by default. As for an easy way to enable it, how about a build step that takes a marquee.css and merges it with the quirks.css that's in the dist directory?

To answer mpt's question in comment #22, > In my experience, pages containing MARQUEEs consistently display more > pleasantly in a browser that does *not* support MARQUEE than in a browser which > does. But I don't read Chinese. Are there any marquees for which this not the > case? There are sites which use vertically scrolling marquee. Some sites have a lot of lines of scrollable text, e.g. 10-15. This means that Mozilla will add these many lines to layout. This sually breaks the layout of the page in a big way. There are also horizonatal scroll cases which feed many lines than can fit on 1 line or space allocated. In this case also, we get broken layout. We have found that nearly 30% of top 150 sites in China use the marquee element -- many sites use it several times in different places on a page.

From comment #24 > Shouldn't this binding be added to quirks.css instead of html.css? Good suggestion. Doron and Kat, This should work, right? We probably should retest agains the top Chinese sites using marquee. (BTW, it's quirk.css, not quirks.css) From comment #25 > As for an easy way to enable it, how about a build step that takes a > marquee.css and merges it with the quirks.css that's in the dist directory? Yes, that is the idea. The makefile could just append a text file with the additional 2 rules to the source of the quirk.css file and install the results to the dist directory. And the makefile would do this conditionally (if defined $(XBL_MARQUEE).

First of all, this should never be built be default. Sending this to the rest of the world would just cause negative feedback. Adding the style rules to quirk.css should be safe, since chinese sites are behind the rest of the world means they don't have doctypes. I'll create an xpi for iQA

I don't understand why people are so opposed to this. Well, this is what I just sent in private email: -- ...Above all else, we're a web browser. We're not just an HTML browser. If there's something out there that lots of people are using and there isn't a "more correct" way to support it with existing documented standards, I think that we should consider implementing it and supporting it. Put that way, layers and document.all are out, but marquee is in. I think that we should put marquee in and support it. I don't want people to be able to turn it off since it's important to installed user base, even if english isn't their first language. We need more users, not fewer.

I'd agree that we should just have this on. Having forks makes bugs difficult to reproduce, fixes difficult to test, etc. Furthermore, this is a relatively simple feature (unlike document.all or document.layers) -- less complicated than lots of the other wacky things we do for compatibility with MSIE and with 4.x. (I also think any build mechanism to append to quirk.css or html.css would make development a bit more difficult, at the very least in any builds that had marquee enabled.) If we went by "just the standards" without regard for compatibility, then we'd have a browser that actually displayed simple HTML nicely but that would break most existing pages on the web (by doing things like having a larger default 'line-height'). We're a web browser. We support standards and display standards-conformant pages correctly (at the very least in strict mode, and in quirks mode too, unless doing it in quirks mode would break real pages on the web). However, we support lots of other things that the web needs, like really quirky parsing of HTML. As far as I can tell, marquee is only different from all the other strange things we do because it wasn't added four years ago. It wasn't added four years ago because it was an IE-only feature rather than a NN4-only feature, which was acceptable at the time since NN4 still had market share similar to WinIE at the time.

the problem is, that for many people <marquee> is the evil itself, the sign of proprietary HTML. The second proble is, that it can make many pages less readable.

Added Microsoft documentation on marquee to the URL field. As people are arguing about turning on <marquee> support fully or not, I should mention that that there are a number of features listed in the document our current solution probably does not support. Have we done enough analysis to see if they are supportable? Supporting a full set of features described in the document may not be trivial. It is possible some may not be supportable. Are we willing to support additional marquee attibutes in the future?

I also heard from some people that they consider <marquee> to be a bad thing. And of course, we should never use a <marquee> in almost- or full standards mode. Never. This is and would be a quirks-only thing, I'd believe. I even think it should show up as an error if we ever go and create an HTML error window or something like that.

> ...Above all else, we're a web browser. We're not just an HTML browser. If > there's something out there that lots of people are using and there isn't a > "more correct" way to support it with existing documented standards, I think > that we should consider implementing it and supporting it. See comment 18 for a reference to a standards based approach. The one thing that can be said for <marquee> is that it's probably a little less work than including the DHTLM JS object and setting it up just so. Case in point being home.netscape.com, which is getting by without <marquee> just fine. I still say Mozilla shouldn't have this on by default, and I think support for this code shouldn't lie with Mozilla, but rather Netscape. I think this code should live in ns/extensions/, not mozilla/extensions/. This would still make life easier for the Netscape China build people.

> I think support for > this code shouldn't lie with Mozilla, but rather Netscape. I think this code > should live in ns/extensions/, not mozilla/extensions/. This would still make > life easier for the Netscape China build people. I think this should be checked into mozilla/extensions. Based upon the evangelism efforts with the top Chinese sites, any Gecko-based browser will run into this problem when deploying to China. There's nothing proprietary about this code, so I see no reason not to share this implementation with any Mozilla developers which want it. We should not decide for developers whether to enable marquee or not.

One off-the-wall idea might be to support <marquee> as an div with overflow:scroll; that is, the user gets to scroll the content rather than having it moving irritatingly. <shrug> But, as it stands, I would oppose turning this on by default in Mozilla builds - it's possible to argue that we can make a distinction (as Blizzard attempts) between things that can be done in an alternative standards-compliant way (layer) and things which can't, at least easily (marquee). But this hair-split may not come across. I think bobj put the position very well - turning this on sends a dangerous message to people we are trying to evangelise to upgrade their site - "Ignore us; if you wait long enough, we'll give in." Gerv

Also, this is a minimal api built upon what chinese sites use, this isn't a 100% reproduction of the marquee api.

I don't want to see Netscape and Mozilla diverge on what is really a core layout feature. If we're going to put it in the code at all, let's turn it on. I want web developers to expect this support to be there or not - one or the other so let's pick one. Plus, we don't get QA on it if isn't on by default and QA is important to me, I don't know about anyone else. Second, I don't buy the "we're being pushed around by web developers" argument. We need to find the balance between supporting and promoting standards and supporting existing web pages. If there are a lot of pages out there using <marquee>, which I'm convinced there are, we should be supporting it since there isn't a direct equivelant. Someone has written support for it, we should be taking it.

> If there are a lot of pages out there using <marquee>, which I'm > convinced there are, we should be supporting it since there isn't a > direct equivelant. What we know about marquee usage through our evangelism efforts in Japan, China, US, Germany, France, UK, Brazil, and other Latin American countries does not show that there are any siginicant number of major sites using <marquee> except in China. For example, we tested some 500 sites in Japan, only 2-3 sites were using marquee and they were all minor sites. I think it is safe to assume that marquee will not be a significant issue anywhere other than China for major web sites. It seems to me the proposal to ship this feature ON to China only sounds like a resonable compromise between promoting standards and providing support to non-standard feature to match local market conditions.

> If there are a lot of pages out there using <marquee>, which I'm convinced > there are, we should be supporting it since there isn't a direct equivelant. I was going to ask you for some proof of that, but Kat already debunked it. > Someone has written support for it, we should be taking it. As far as I know Mozilla doesn't incorporate code just because it's been written.

> Someone has written support for it, we should be taking it. No, someone has written partial support, specifically tailored to the features that Chinese sites use since Chinese sites are (vritually) the only sites that use <marquee>. See comment 37.

fwiw someone has provided a partial implementation of document.all which we have also currently rejected. I don't want to see either document.all or marquee. gerv suggested overflow:scroll. that sounds like a neat idea, can we get some people to look into that? (yes i know, i should poney up the people, but i don't read chinese and i don't know of many chinese mozilla volunteers outside of sun china, and i know they have work to do... maybe i'll ask them anyway) personally as an end user, i think i'd prefer that over supporting marquee. it would allow *me* to control the content I see. which is what I expect a *user-agent* to allow. If overflow:scroll works for end users, then i (as a non netscape employee who really has no say) support jag's position which is to make this a netscape/extensions extension and have mozilla simply provide the overflow binding just as we currently have it display:block instead of display:inline. -- comment posted in links (which will probably mess up line wrapping).

In comment #36, Gerv meant bclary, not bobj, I think. timeless, please stop injecting unwrapped miles-long paragraphs-all-on-one-line! I do not agree with blizzard's apparent contentions that (a) marquee is in demand enough to be on by default, or (b) just because someone wrote some code to implement (partial support for) marquee, that we should take it. I'm still ok with partial marquee support being off by default except for certain localizations or vendor builds. I'm not sure about dbaron's argument that developers and testers are better off with marquee on by default. Even if I take his word for that (as I'm always inclined to do with dbaron's words), my concern is that turning it on by default will put us on a slippery slope to full support, and to an even-slight increase in marquee adoption. Actually, my main concern is that turning it on by default "sends the wrong message", even were there to be no slide down the slipper slope. Anyhoo, that's where my brain is right now on this bug. /be

Even with IE supporting this, very few people actually use it. I doubt if Mozilla supporting it would encourage it more. After all, those who really want scrolling text would find a way to do it whether or not marquee is supported. So why not just include it? It will make life easier for those who need it, since it eliminates the need for complex dhtml.

I'd like to bring this to closure. It's always dangerous to generalize the comments of others, but I'll try... Comments favoring enabling marquee-emulation by default: - Mozilla is a web browser and not just an HTML browser, and should do its best to support widely used markup. We already support other non-standard extensions. - Forking is nasty for maintenance and QA Comments favoring disabling marquee-emulation by default: - Sends wrong message about standards and is a disservice to efforts to evangelize standards compliance. - Current implementation is a partial emulation of the MS marquee and it would be significant work to make if a full emulation. - Outside of China there is no popular demand for marquee Most of us seem to be convinced that China needs a marquee solution, but from the evangelism experience in "Japan, China, US, Germany, France, UK, Brazil, and other Latin American", marquee currently is not an issue outside of China. My conclusion/suggestion: While I agree that we should do our best to support widely used markup, the data does not support marquee is widely used except for withing China. Disabling marquee by default now, does not preclude enabling by default later. Switching the default will be easy. And it is more difficult to put the genie back in the bottle, if try to do the opposite. We should make this available to any developers that want it and check it into mozilla/extensions, but disable it by default. Developers who needd it (e.g., for China-bound projects) will have to suffer the nastiness of forking... If we discover contrary data or marquee becomes more widespread outside of China, we can enable this by default at that time. Can we get staff@mozilla.org to allow the mozilla/extensions/xbl-marquee to be created?

Bob, thanks for the summary. I think it's fair. One thing (I asked this in e-mail, better to ask it here): Why should the few new source files go under mozilla/extensions? Can't we fold the changes into quirk files that already exist? One new .xml file to hold the XBL won't require a new extensions subdir. /be

> Most of us seem to be convinced that China needs a marquee solution, but from > the evangelism experience in "Japan, China, US, Germany, France, UK, Brazil, > and other Latin American", marquee currently is not an issue outside of China. > So this means that people using a US build and viewing sites in China will not be able to use the marquee tag? Just because it's used on chinese sites does not mean that people outside of China will not need it. This is silly. The Internet transends geography. Also, the idea of localized builds for Chinese users supporting different things via layout just does not pass the sniff test for me. At all.

The CSSWG has been requested to add 'marquee'-like abilities to CSS, specifically because of the Chinese contingent. I can't say when it'll happen, but I'm sure eventually it will, because requiring authors to use SMIL for what in China is a simple text overflow mechanism is not acceptable. My position would be Yes, we should implement <marquee>, at least as much as is required by Chinese sites, and gracefully degrade in other cases. If someone wants to implement the other cases eventually then great. That way, Microsoft will not be the only group in the CSSWG with implementation experience. So from the standards side, I say go with it. Going beyond the specs is not evil, it's innovation. What's evil is going _against_ the specs. If we do take this, let's go with html.css and not quirk.css. Quirks mode should only be about breaking the specs, not about stopping innovation. Speaking of innovation, using XBL to implement this kicks ass. Great work!

Hi, I'll be your incarnation of evil (as defined by Hixie) for today: I would oppose implementation of MARQUEE even if it was in any version of the HTML specification (which, let's not forget, it isn't). Standards compliance should not be a suicide pact, but neither should compatibility with other browsers' misfeatures. And I remain of the view that any page with marquees is considerably more usable in a browser which does *not* support MARQUEE than in a browser which does. It's much easier to read, easier to select for copying, searching, translating, etc, and more predictable when printing; and fidelity of layout comes a distant second as far as I'm concerned. (Similarly, MSIE 3.0 implemented most NS-specific HTML but ignored BLINK, thereby being more usable.) If Mozilla ever became usable enough to introduce at our Internet cafe, I expect the lack of MARQUEE would be an attraction for our (many) Chinese customers, as it would make pages easier to read. (Similarly, I expect that our rejection of the MSIE DOM would be an advantage, since the DHTML I see on Chinese portals is predominantly floating adverts which get in the way of what people are reading.)

The open issue remains whether this should be enabled/disabled by default for all Gecko/Mozilla builds. I believe the majority of the comeents support at least making the XBL marquee support available for Chinese-bound projects at the developers' discretion. I would like to get staff@mozilla to create this extension, so we can start working on the build changes. It will be trivial to switch the default from disabled to enabled, depending upon the resolution of that issue. From comment #46 > Why should the few > new source files go under mozilla/extensions? Can't we fold the changes > into quirk files that already exist? One new .xml file to hold the XBL > won't require a new extensions subdir. It's not just a new .xml file. If it's optional, I assume - We'll have a file with the additional rules to be appended/included to the default quirk.css (or html.css) - I didn't see an appropriate chrome for this, so I assumed marquee will need it's own chrome and therefore a contents.rdf file - For Mozilla clients, I assume this would be packaged in a separate optional XPI. So we need a jar.mn to create the jar file and a xbl-marquee.jst to create the install.js for the XPI - For Gecko embedders, we need to add the .xml and contents.rdf to embed.jar. Again, I assume that we would have a file with the lines we need to append to embedding/config/embed-jar.mn. Also, by creating a separate directory, we can minimize the changes to existing files. I think we can limit the changes to - the top-level makefiles in mozilla/extensions/ - the top-level makefiles in mozilla/embedding/config/ (for Gecko embedders) - the list of packages in mozilla/xpinstall/packager (for Mozilla clients) In addition, to the files in extensions/xbl-marquee, we will need - xpinstall/packager/xbl-marquee.jst (to create install.js for the XPI)

Put marquee { -moz-binding: none ! important; } ...in your cafe's userContent.css and that will solve your support problems. In the meantime, there is MASSIVE (relatively speaking) demand from the Chinese web community for easy <marquee>-like behaviour. I'm not Chinese, I don't speak Chinese, I don't read Chinese, I don't understand Chinese culture, but I don't see why we should alienate such a huge potential market. Regarding the copying point -- I think it would be wise of us to add an onmouseenter/onmouseexit handler pair to the XBL which would stop the scrolling while the mouse was above the element. We could do something similar for onfocus/onblur, if those events are triggered during keyboard copy and paste.

If we want marquee support to be optional, then I suppose the whole jar.mn business is necessary and an extensions subdir is the way to go. But if, as dbaron and Hixie have both argued along with blizzard, we want marquee support by default, then why bother with extra files and packaging? Staff@mozilla.org is likely to defer to dbaron and Hixie (blizzard is on staff and he has weight too; I'm not slighting his opinion, just separating staff from non-staff experts who are closer to the source code and the web standards than staff :-). Unless I override everyone and insist on optional marquee support, it seems to me we should defer to dbaron@fas.harvard.edu and ian@hixie.ch. I don't feel strongly enough (much as I dislike marquee) to override the domain experts here. /be

I agree with the idea that this should be built by default, but show up only in quirks mode. Doing so we make it clear that it is not a standard and we support it only for compatibility. Just like other quirks, authors who want nonstandard behavior simply need to create their sites to display as quirks.

You've heard from MPT who is very informed about the user experience concerns, but seem to be ignoring him. It is very well known in usability circles that blinking and automatically scrolling text is extremely distracting to users. I've seen marquee badly abused on more sites than I've seen it used reasonably. (I could say the same thing about animated images, but look, I can turn them off.) Mozilla doesn't need this. Gerv summed it up well in comment 36. This sends the wrong message. He has a potentially better solution for Mozilla (and users).

Comment #52 From Brendan Eich > ... Unless I override everyone and insist on optional marquee support, > it seems to me we should defer to dbaron@fas.harvard.edu and ian@hixie.ch. > I don't feel strongly enough (much as I dislike marquee) to override the > domain experts here. Does that mean we have staff@mozilla.org's approval to add the marquee support? Shall I update the Summary from XBL emulation of marquee as a mozilla extension to Add XBL emulation of marquee

Comment #48 From Ian 'Hixie' Hickson > If we do take this, let's go with html.css and not quirk.css. Quirks mode > should only be about breaking the specs, not about stopping innovation. And should we put the marquee rules in html.css as Ian suggests?

Comment #47 From Christopher Blizzard 2002-07-17 09:19 ------- > ... Just because it's used on chinese > sites does not mean that people outside of China will not need it. This > is silly. The Internet transends geography. This is a good point and one that I18Ners fully support. A related issue: If some Mozilla's support marquee and others do not, it will be difficult for content authors to sniff and do the "right" thing. Some Chinese pages do sniff the UA to determine whether to use marquee. They could add special case handling in their sniffing code for the UA locale component. blech.

Tim Powell: if you were addressing me, my response would be that mpt's usability expertise doesn't trump the layout/css gurus' opinions here, because this bug is not about default UI or anything to-do with Mozilla usability. A site that uses marquee badly may be unusable, but I am told that highly-used (if not usable by mpt's lights) Chinese sites want marquee, and that lack of marquee support is hurting Mozilla adoption in China. If mpt wants to bug the authors of those websites, he's welcome to try. If he and you claim that marquee (along with blink, which we suppoort) is inherently unusable, good luck to you in your evangelism effort. This bug is about how Gecko should support a tag that may or may not be well-used (we support blink too), where support for that tag should lead to greater Mozilla adoption, and where staff@mozilla.org are not about to say "take it to mozdev, not in our pure and precious cvs repository!", so the option of rejecting marquee support entirely has been foreclosed. Usability of web pages already using that tag is not the issue reported here. (I don't think this bug's Component should be Build Config, therefore, but I'll leave it to someone else to fix that.) dbaron, would you be willing to specify how you'd like to see marquee support integrated with enough detail that Roy or someone else can do the work? /be

brendan, you just made the case for document.all while we're at it, let's readd document.layers

timeless, when I make a case for something like layers, you'll know it. This bug is not about layers or document.all, so stop dragging them in. If you think there is no difference between any of these things, and they're all "non-standard" and therefore evil, or to be avoided, then you are ignoring Hixie's distinction in comment #48. You are also off-topic as far as the usability issue that I was addressing. Analogy with JavaScript and its standard: ECMA-262 specifically allows extensions (Chapter 16 of Edition 3), and I have driven JS by extending the standard (also, JS was a de facto standard before any ECMA de jure spec, but that's a different issue). So please stop appealing to standards without thought of the particular costs and benefits of extending or violating a standard. Try to make the necessary distinction between what is a pure extension with no existing standardized alternative (e.g., marquee), and what is redundant in view of standard methods (document.all vs. document.getElementById, or layers vs. CSS-P and its DOM). /be

> Try to make the necessary distinction between what is a pure extension with > no existing standardized alternative (e.g., marquee), and what is redundant > in view of standard methods (document.all vs. document.getElementById, or > layers vs. CSS-P and its DOM). Brendan, such a distinction seems irrelevant to Gecko, since (a) there is so an existing standardized alternative to marquee (as used on netscape.com), and (b) we do so support redundant standard methods in some cases (innerHTML). I suggest a more useful distinction is, does implementing something make the user experience for Mozilla (or any other Gecko browser) better or worse? (If this wasn't about usability, as you claim, I wouldn't be interested in it.) A week ago I asked the two questions necessary to answer this: (1) Are there any sites for which Mozilla's marquee {display: block;} is less usable than MSIE's MARQUEE rendering? (2) Are there any sites which block Mozilla because it doesn't support MARQUEE? Since this bug report is decked with Evangelism people I would have expected several examples for either question, if such sites were at all common, but so far the number of examples has been *zero*. So I am perplexed at your (and Blizzard's) claim that lack of MARQUEE is hurting Gecko adoption in China, since no-one has offered any evidence for that, and unless Chinese Web surfers are psychologically different from those in rest of the world, the opposite should be the case. If Evangelism people are trying to get Chinese Web sites to be just as infuriating in Mozilla as they are in MSIE, I rather think they have lost sight of the long-term goal.

mpt, using gobs of JS to implement a DHTML marquee (or an innerHTML setter and getter pair) is not the same thing as having the tag (or property) support intrinsic in Gecko. All those Chinese sites are not about to write or acquire appropriate DHTML emulation of marquee and include it somehow. JS can be used to emulate lots of built-in things; the DOM is not a minimal set of primitives, with all else synthesized using JS functions and getters/setters. I wrote clearly (comment #58) that I am told by others that lack of marquee is hurting adoption in China; I'm relying on testimony of people I trust. Kindly don't be perplexed by that as if it were my claim. Do adduce evidence that shows my trust is misplaced, if you can :-). Your question is fair, I think: evangelism and i18n folks, please list a bunch of Chinese URLs that suffer from lack of marquee. /be

Kat is out this week for personal reasons. Here is an unedited/reviewed list of his marquee bug urls: http://www.wyw.com.cn/ http://mail.21cn.com/ http://www.chutianbs.com.cn/ http://www.52kan.com/ http://www.hkyule.com/ http://www.csdn.net/ http://www.yestock.com/ http://chinese.china.com/zh_cn/ http://www.chinaren.com/ http://www.lycos.com.cn http://www.rednet.com.cn http://www.yesky.com http://www.phoenixtv.com/home/0,1328,1-1,00.html http://www.xinhua.org http://www.cycnet.com/youth.htm http://www.sohu.com/ http://www.chinabyte.com http://www.ccidnet.com http://www.21dnn.com/ http://www.163.com/ http://www.sina.com.cn/ http://www.newscartoon.com.cn/ http://www.stockstar.com http://www.51job.com/ http://www.founder.com.cn http://www.lanyue.net/chat/login/ http://xajh.com/ http://www.263.net/ http://www.ycwb.com/ http://www.sxrb.com/mag6/index.htm http://www.infomorning.com/ http://www.chinamp3.com/ http://joy.cis.com.cn/ http://www.zhaopin.com/ http://dailynews.sc.cninfo.net/ http://www.tyfo.com/ http://www.yangtse.com/gb/node/2002-05/31/default.htm http://www.stardaily.com.cn/ http://www.china.org.cn/chinese/index.htm http://tech.enet.com.cn/

As a web developer, I don't think marquee should be enabled by default. It might be an innovation, but not every innovation is good. I consider marquee bad, because (a) as presentational element it violates a basic principle of HTML, (b) it has a poor usability and accessability and (c) it doesn't degrade gracefully (if it did this bug would not exist!). The W3C tries to throw presentational elements and attributes out of the HTML standard and recommends the use of CSS, so adding marquee support would be contrary to the current direction of the standards. If the CSS WG includes something marquee-like into the CSS standard, there is no need to implement a marquee element, because page authors could then use those property/value to get the effect, it would degrade gracefully and could be simply overridden in an user stylesheet (how many people will know about -moz-binding? I wonder how many people will fallback to display:none or visibility:hidden to get rid of the marquees). Additionally, AFAICT adding non-standard elements _is_ a violation of the HTML spec: From http://www.w3.org/TR/html401/appendix/notes.html#h-B.1 | For reasons of interoperability, authors must not "extend" HTML through the | available SGML mechanisms (e.g., extending the DTD, adding a new set of entity | definitions, etc.). Even if the standard would allow such a behavior, sites with marquee suffer an decrease in accessability and usability. Many people have difficulties with scrolling text (e. g. young children and older people that cannot read that fast). Jakob Nielsen considers marquee very harmful: From http://www.useit.com/alertbox/9605.html | 3. Scrolling Text, Marquees, and Constantly Running Animations | Never include page elements that move incessantly. Moving images have an | overpowering effect on the human peripheral vision. A web page should not | emulate Times Square in New York City in its constant attack on the human | senses: give your user some peace and quiet to actually read the text! | Of course, <BLINK> is simply evil. Enough said. In his later Alertbox "Top Ten Mistakes of Webdesign Revisited" he rates the usability impact of this as "very severe". He targets web developers, but Mozilla as an user agent should try to protect its users from such design-mistakes and has already gone in that direction by implementing anti-popup controls, ignoring the target attribute, image blocking and image animation preferences. The UAAG even requires browsers to allow users to protect themselves from badly authored pages. The following guidlines and checkpoints seem to be relevant for marquee: From http://www.w3.org/TR/WAI-USERAGENT/guidelines.html | Guideline 2. Ensure user access to all content. | 2.4 Allow time-independent interaction. (P1) | | Guideline 3. Allow configuration not to render some content that may reduce | accessibility. | 3.3 Toggle animated/blinking text. (P1) | | Guideline 4. Ensure user control of rendering. | 4.4 Slow multimedia. (P1) | 4.5 Start, stop, pause, and navigate multimedia. (P1) | 4.7 Slow other multimedia. (P2) | 4.8 Control other multimedia. (P2) (Scrolling text could be considered as "other multimedia" here) If I understand that correctly, it means, that if marquee is implemented, there has to be a way to disable, start, stop, pause and slow its behavior. And this are mostly P1 points! Then there are unresolved problems how certain browser function should behave: - How would marquee print? Printing only the section of the text that is currently on screen => People will have to time printing or print multiple pages, if the amount of text they want would not fit into the marquee block Printing the whole text => The text might not fit on the page - How would text selection work? The marquee is stopped when selecting => How would one select more text than the marquee block can contain? - How would marquee interact with caret browsing or searching? It has been said that evangelising this would be impossible. But it surely is a lot simpler to evangelise this than bug 22274 (dupe count 102). That one was a long time considered to be evangelism and has made a lot people change their sites (there are mutiple threads about this topic per week in comp.infosystems.www.authoring.*, most end with the authors changing their pages). Activating this by default should be reconsidered. Only because something is possible or allowed, it is not always a good thing to do. Even if the spec would allow the implementation of marquee, achieving a better layout does IMHO not justify the usability and accessability problems marquee has. Perhaps the proposed overflow:scroll would be better a solution to the layout problems. Note: I have not seen any comment about accessability on this bug. Does that mean that Mozilla's and Netscape's accessability teams don't think marquee is a problem, or does it mean that they aren't aware of this bug?

> How would marquee print? It should print like any text in a block-level element. > Printing the whole text. The text might not fit on the page. HTML is designed to flow, right? If the text is too long, it should simply wrap.

> It should print like any text in a block-level element. > HTML is designed to flow, right? If the text is too long, it should simply > wrap. That's the current behavior, this bug is about changing that. Many designers don't take the flowing of HTML into account and that causes misaligned graphics or empty gaps in the pages. As I understand it, that is the reason for wanting to implement marquee. Please correct me if I'm wrong. Anyway, I have looked at the 40 pages Bob Clary postet and compared the IE rendering to a out-of-the-box Mozilla nightly. Five of them were either unreachable, redirected me to some english version without marquee or didn't contain any marquee elements. Of the other 35 five used js browser sniffing to write some or all marquees and would have to be evangelised anyway. In two pages the marquee content was inaccessible because of this. I didn't check for server side browser sniffing. The large majority of the pages (21) degraded gracefully, with no (noticable) break in layout. Ten pages had minor problems (mostly misaligned graphics) and on two were large empty gaps. No page broke completely. Marquee was badly abused on two pages (the text bounced about 1ex back and forward very fast). I don't know any chineese, but on most pages the scrolling was so slow, that I couldn't read them fluently if it were latin characters. One page made up for only having 3 characters in the marquee by choosing the probably slowest possible scrolling speed. Another page had nine images in an slowly scrolling marquee, so it took about a minute to see them all. They were all visible at the same time in Mozilla. A third site scrolled a very large timetable. Again you'd have to wait half a minute if you were looking for the last entry in that table. In most pages, the marquee box was larger than its content and degraded gracefully (mostly into centered static text). Almost all pages used some js funtions onmouseover/onmouseout to stop the marquee. Most pages don't seem to have a problem in Mozilla. Those that do are still a lot more usable since you don't have to wait for the content you want to read to scroll into view and don't have to read it while its moving. I can't see why _users_ would want to have that implementet.

It's also ok with me if you want to make it an extension. I don't really care, as long as I'm not the one who has to figure out why it broke "sometime in the last 6 months" because nobody was testing it.

Should David's Comment #67 From David Baron, be the last word on this bug? Is the decision to implement this as an "extension"? if yes, can we drivers' approval to check this in as an "extension" on the trunk and branch, as we need to get this in asap for a major embeddor.

Thank You Markus for comment #64 I agree that the integration of the marquee element into mozilla would probably not be the best idea. Besides the usability issues, the marquee element is contrary to what the W3C is trying to do with (X)HTML: seperate content from presentation. If the marquee element had been a part of an HTML specification, I am sure it would be deprecated (and removed from XHTML1.1). The idea of extending the DTD (a violation) for somehting the W3C would never endorse just seems dirty. Now, I understand that there *may be* a need for marquee support for certain Chinese sites. And I do know that we have had several bugs calling for the inclusion of marquee (bug 80269 being one). If, because of this, we want to include an XBL control to implement marquee, we then should go all the way and not make it an extension. Having marquee supported in only some builds vs others would create a huge mess. Could you imagine web developers being told that "cross-platform Mozilla" supported a certain feature in only some of its builds? We'd be a bigger laughingstock than MS with its different IE for Mac vs. Win. And, what is worse, the idea of Chinese sites being read by only people in China is an assumption that seems ill-founded anyway. So what would I propose? Since it seems people want this even if it isn't built by default, I'd say that we build it all the time (no extension). That way we don't have to worry about build and bug report issues ("The marquee support broke sometime in the last 5 months" for example) and we don't have to have a fear of different geckos (from the same time) supporting differnet things. And here's where I'll get lambasted -- support should be a pref (oh god I hear the beating coming...) which is off by default (except in vendor-defined circumstances). How this pref is implemented (hidden vs. shown) isn't up to me. I do believe that the "Advanced" Panel is getting misused with everything under the sun thrown into it. But as the Accessibility guidelines say, if this is implemented we are going to need a way to turn it off, so a pref will become necessary eventually. (Although I think we are living without one for blink... are we?) So if this is a must-have for our Chinese-reading (not just Chinese) markets, then do it. But don't fork the code and create a management nightmare. Good web developers will continue to make websites without marquee, and the assumption that only IE supports marquee will still be mostly true.

This might be sillly but here I go. If marquee has 0% usage in non-chinese sites, and 30% in chinese sites, wouldn't it be posible to enable it when the charset one used by chinese sites (like GB2312)? Yes, "charset sniffing"... =)

I will note that drivers don't approve concepts, they approve patches. I haven't yet seen a patch on this bug for the build system changes needed to integrate marquee as an optional extension. Such build changes do need code review, since the details of those changes will determine (among other things) how easy or hard it is to work on style system changes in the future. There's been a lot of discussion here, but no proposed patches. Does anybody have a patch?

Bamm Gabriana: > Just like other quirks, authors who want nonstandard behavior simply need to > create their sites to display as quirks. Please avoid confusing behaviour that is beyond the standards with behaviour that violates the standards. Standard-violating behaviour is bad, and our quirks mode is strictly about trying to render legacy content that relies on standard-violations. Standards-extending behaviour is vital for the members of the standards setting bodies (such as several of the posters on this bug) to gain implementation experience so that the standards can be set in the best possible way. In the field of Marquee-like effects, Microsoft currently has the only implementation experience (to my knowledge) and is therefore able to hold a trump card over other members of the working group. This is generally not a good situation to be in. (Similar situations exist in reverse, and those are not good situations either.) Tim Powell: > You've heard from MPT who is very informed about the user experience > concerns, but seem to be ignoring him. Quite the opposite, you will see I addressed his concerns above. > It is very well known in usability circles that blinking and automatically > scrolling text is extremely distracting to users. Indeed. To solve this, we should probably have a pref ("disable animations") which covers blinking, images, and marquee, as well as any other animation effects in future. > I've seen marquee badly abused on more sites than I've seen it used > reasonably. (I could say the same thing about animated images, but look, I > can turn them off.) XHTML has probably been abused more than <marquee>. I don't see any large movement to banish our XHTML support. > Mozilla doesn't need this. I am told by experts in i18n (both those working on Mozilla as well as those in the W3C) that declarative marquee is very much needed by the Chinese web community. Since I am not an expert in that field, I do not feel able to challenge their opinion. > This sends the wrong message. I think I disagree that the message it sends is wrong. However, I am not 100% clear on what you think the message it is giving is. timeless: > [...] Oh for crying out loud shut up, timeless. Matthew Thomas (mpt): > such a distinction seems irrelevant to Gecko, since (a) there is so an > existing standardized alternative to marquee (as used on netscape.com), There is one standardised declarative alternative to <marquee>, and that is SMIL. Unfortunately SMIL is not widely deployed, and is significantly more complicated to use than a simple <marquee> element. (It requires using XHTML, namespaces, and learning SMIL and/or SVG.) > and (b) we do so support redundant standard methods in some cases > (innerHTML). The standard-equivalent version of .innerHTML is significantly harder to use, and therefore .innerHTML counts as a convenience property, as Brendan explained. > So I am perplexed at your (and Blizzard's) claim that lack of MARQUEE is > hurting Gecko adoption in China, since no-one has offered any evidence for > that Personally, I am convinced because I have been informed of this need by people I consider field experts. Since I am not an expert on i18n issues, I am not qualified to challenge their statement. Markus Niederlechner: > I consider marquee bad, because (a) as presentational element it violates a > basic principle of HTML, Indeed, this is why the CSSWG would like to move this to CSS. But we are lacking in implementation and usage experience to do so in an educated fashion. Mozilla implementing this would go a long way towards helping with this. > (b) it has a poor usability and accessability This statement has been countered several times. > and (c) it doesn't degrade gracefully (if it did this bug would not exist!). Oddly enough, most of the "against" camp is arguing that it _does_ degrade gracefully. > ...could be simply overridden in an user stylesheet (how many people will > know about -moz-binding? I wonder how many people will fallback to > display:none or visibility:hidden to get rid of the marquees). How many people will think of changing the <marquee> element in a user stylesheet at all? We could add an example to userContent.css, next to the example showing how to turn off the <blink> element. See point 4 at the bottom of this post. ># For reasons of interoperability, authors must not "extend" HTML through the ># available SGML mechanisms (e.g., extending the DTD, adding a new set of ># entity definitions, etc.). > -- http://www.w3.org/TR/html401/appendix/notes.html#h-B.1 _Authors_ should not extend it. It doesn't say what UA implementers should do with invalid markup. Indeed, HTML is specifically undefined when it comes down to how to handle invalid documents, so per specs we are completely within our rights to do whatever we like with non-standard HTML. > The UAAG even requires browsers to allow users to protect themselves from > badly authored pages. The following guidlines and checkpoints seem to be > relevant for marquee: [...] I totally agree that we should be able to disable it. The "stop animations" should, IMHO, kill text-decoration:blink and <marquee> as well (as well as SMIL, if we supported that). > - How would marquee print? > Printing only the section of the text that is currently on screen > => People will have to time printing or print multiple pages, if the > amount of text they want would not fit into the marquee block I agree that that is a bad idea. > Printing the whole text > => The text might not fit on the page No worse than now, of course. I propose that in addition to the onmouseenter, onmouseexit, onfocus and onblur handlers I mentioned above, we also add a rule to disable marquees during printing. See point 2 at the end of this comment. > - How would text selection work? > The marquee is stopped when selecting > => How would one select more text than the marquee block can contain? Same way as you select any overflowing text -- the block will scroll if you drag past its edge. > - How would marquee interact with caret browsing or searching? Exactly the same way as a scripted scrolling animation now. (Since that's exactly what it is.) > It has been said that evangelising this would be impossible. But it surely is > a lot simpler to evangelise this than bug 22274 (dupe count 102). You'll notice we gave up evangelising that one, and have instead created a third rendering mode to handle it. > Note: I have not seen any comment about accessability on this bug. Does that > mean that Mozilla's and Netscape's accessability teams don't think marquee is > a problem, or does it mean that they aren't aware of this bug? I cannot speak for the accessibility teams, but as far as I can tell, the pref should deal with that, as well as the sample userContent.css. To summarise, I personally think we should: 1. stick marquee.xml in the same place as html.css, both in the tree and in distributions. 2. add the following to html.css: /* emulation of non-standard HTML <marquee> tag */ marquee { -moz-binding: url(marquee.xml#marquee-horizontal); } marquee[direction="up"], marquee[direction="down"] { -moz-binding: url(marquee.xml#marquee-vertical); } @media print { marquee { -moz-binding: none; } } 3. add mouse and focus handlers to the binding so that it stops while the mouse is above it or the user has it or anything inside it focussed. 4. add the following to userContent-example.css: /* * example: turn off "marquee" element * * marquee { -moz-binding: none; } * */ 5. Make a single pref control blink, marquee, and image animations. (This should be handled in a separate bug.)

>1. stick marquee.xml in the same place as html.css, both in the tree and in >distributions. will xbl work outside of chrome? Not sure, will have to test >3. add mouse and focus handlers to the binding so that it stops while the mouse >is above it or the user has it or anything inside it focussed. This would be adding stuff to the ms's marquee spec, which it allows already, but only if the website adds the appropiate event handlers. Not sure how good this would be. I still think this should be a extension, as I still believe this will hurt us (us being Netscape) outside of China.

the xbl file has to be in chrome://, else getAnonyonmousNodes doesn't work (security exception).

Why can ./ua.css link to ./html.css while ./html.css can't link to ./marquee.xml? Also, how on earth could this _hurt_ Netscape? (If that is private, I'm still under AOL NDA, so you can e-mail me ian@hixie.ch .)

Did your XPI add the marquee style rule using some other mechanism than modifying html.css or quirk.css? If so, could we see it in the form of a patch? If not, then I would think marquee stuff would be best in a directory such as layout/html/document/src/marquee/, so that a rebuild in layout/html/document/src/ would be all that is required to rebuild html.css and quirk.css.

> If so, could we see it in the form of a patch? Yes, bobj is in the processing all things together and I'll produce a patch

From Comment #76 From David Baron: > Did your XPI add the marquee style rule using some other mechanism than > modifying html.css or quirk.css? No. It appears that JS is causing the security exception when using resource (vs. chrome) URL. I don't think the other examples use JS and is probably why they work.

Ian Hickson: > we should probably have a pref ("disable animations") > which covers blinking, images, and marquee, as well as any other animation > effects in future. There are already an image pref with UI and this non-UI pref for blink (UI is bug 106462): user_pref("browser.blink_allowed", false); You could combine that pref with the new one, but since it's been around since at least NN4, that name is well established. I don't think that the blink/marquee pref(s) should be combined with the image pref, because there are quite legitimate uses for animated images as content (e. g. a world map that shows the decrease in rainforest areas), while marquee (and blink) are pure presentation. > XHTML has probably been abused more than <marquee>. I don't see any large > movement to banish our XHTML support. In what way has XHTML been more abused than HTML? In what way did that hurt the users? > The standard-equivalent version of .innerHTML is significantly harder to use, > and therefore .innerHTML counts as a convenience property, as Brendan > explained. This doesn't negate the fact that it risks interoperability. If the standards are inconvenient, the right thing to do is to get the standards changed, not to implement arbitrary methods. Otherwise you risk to get a situation like the two incompatible event models in NN and IE, causing many sleepless nights for web developers and leading to severely broken browser sniffers. Interoperability is even more important with core technologies (like HTML; the content might get inaccessible) than with optional supportive technologies (like JS or CSS; they can simply be ignored if the browser doesn't understand them). > Indeed, this is why the CSSWG would like to move this to CSS. But we are > lacking in implementation and usage experience to do so in an educated > fashion. Mozilla implementing this would go a long way towards helping with > this. In what ways would implementing this in Mozilla be better than studing the relevant MS-docs and examining pages that use marquee or some JS-variant? Even if marquee support would be required, the correct way would be to create a custom DTD with marquee (or any other experimental feature) in it (as it has been done with the HTML 3.0 Draft), as well as a specification how it would work (the last part has been done by MS already, I believe). Sites that want marquee could use those DTD and be perfectly valid and trigger strict mode without diluting the W3C-standard. Of course, Mozilla should then only render marquees in pages with those DOCTYPE, and it doesn't address the usability and accessability problems. > Oddly enough, most of the "against" camp is arguing that it _does_ degrade > gracefully. Well, I made those statement before looking at the actual sites. As I already said, most marquees do degrade gracefully in practice. I was basing that statement on the fact that marquee is a display: block; overflow: hidden element that can cause layout breaks when not supported. It is not good to force other browsers into the same problem (implementing it or having layout break). > > # For reasons of interoperability, authors must not "extend" HTML through > > # the available SGML mechanisms (e.g., extending the DTD, adding a new set > > # of entity definitions, etc.). > > -- http://www.w3.org/TR/html401/appendix/notes.html#h-B.1 > > _Authors_ should not extend it. It doesn't say what UA implementers should do > with invalid markup. Indeed, HTML is specifically undefined when it comes down > to how to handle invalid documents, so per specs we are completely within our > rights to do whatever we like with non-standard HTML. True, but it's odd that the W3C addresses the authors with that (probably because the UA implementers are part of the Consortium and the authors aren't. It's easy to point at someone else and tell him/her to fix the mess oneself has created - "We've implemented all those nice non-standard things, but don't even think to use them!"). That doesn't make the interoperability problems disappear for UA implementers. Authors seldom get the idea of extending the DTD on their own. Normally browsers implement those kind of nonsense first (under the protection of "we can do what we want and don't have to think of the consequences, it's covered by the specs" - reminds me somehow of "I can say anything I like and you can't complain, it's free speech") and authors are "only" following their lead. So if now Mozilla is forced into marquee, the web-designers say "nice, both browsers support it, let's use it" and tomorrow Opera and Konqueror face exactly the same problem as Mozilla now. Somewhere has this nightmare to end! It may be allowed, but is it a good thing to do? > > Printing the whole text > > => The text might not fit on the page > > No worse than now, of course. Excatly the same as now, I think. So 'page breaks when printing' would not be a problem for the "pro-marquee"-camp? Then why would it be a problem on screen? > > [bug 22274] > > You'll notice we gave up evangelising that one, and have instead created a > third rendering mode to handle it. Yes, but it (or document.all, if you want a case that is still being evangelised) has probably more than a thousand times the usage that marquee has and has been evangelised a long time, so I'm pretty sure evangelising this one would not be a lost cause, especially when Mozilla and Opera get more marketshare and a marquee-like CSS gets implemented. But since it's very unlikely that marquee won't be implementet in one form or another, I'd rather drop the evangelisation-arguement now. > To summarise, I personally think we should: > [...] > 5. Make a single pref control blink, marquee, and image animations. (This > should be handled in a separate bug.) I'm fine with 1-4, as long as (a) there is a seperate pref for image animations (some people would like to preserve usefull animation while turning the useless blink and marquee off) and (b) the marquee (and ideally the blink) pref defaults to _off_ in Mozilla (nearly all users dislike marquee and blink and Mozilla should have good usability/accessability by default). Those two points can be a seperate bug, but should IMHO be fixed before the next release after this goes in.

The question raised about how it will print is a valid concern. Moz currently displays marquee inline thereby breaking page layouts. If marquee isn't implemented, we should at least recognize the tag and display it as block.

Markus Niederlechner wrote: >This doesn't negate the fact that it risks interoperability. If the standards >are inconvenient, the right thing to do is to get the standards changed, not >to implement arbitrary methods. Otherwise you risk to get a situation like the >two incompatible event models in NN and IE, causing many sleepless nights for >web developers and leading to severely broken browser sniffers. IE-promulgated innerHTML is a _de facto_ standard, which is just as valid as any _de jure_ standard. The world does not improve much or often through design-by-committee, or by waiting for the standards committees to figure out, implement, debug, ship, and iterate an innovation as companies often do in the marketplace. Hixie already said the committee is stymied by lack of real world experience here. My point: there is nothing "arbitrary" in a legal sense about innerHTML just because some w3c committee didn't standardize it. JS is a _de facto_ standard that was codified with little change in ECMA-262 Edition 1, to return to my earlier example. Innovations tested in various markets were then codified by later editions. >Interoperability is even more important with core technologies (like HTML; the >content might get inaccessible) than with optional supportive technologies >(like JS or CSS; they can simply be ignored if the browser doesn't understand >them). That's at best a temporary argument (most of the web has been on a slippery slope that expands core technologies to include newer ones; can you use hotmail without JS?), and at worst a bogus argument now, today. Is CSS "core" or "supportive"? Let the flames begin! /be

Need to modify Makefile.in and makefile.win different from bobj original doc to make the html.css to get updated. We still have problem with comm.jar. (i believe included xbl-marquee needs to be included; but it's not generated by build_string)

whoops. I modified my old plan for marquee as an option. RCS file: layout/html/document/src/xbl-marquee/resources/jar.mn diff -N layout/html/document/src/xbl-marquee/resources/jar.mn --- /dev/null 1 Jan 1970 00:00:00 -0000 +xbl-marquee.jar + content/xbl-marquee/contents.rdf (content/xbl-marquee/contents.rdf) + content/xbl-marquee/xbl-marquee.xml (content/xbl-marquee/xbl-marquee.xml) Index: layout/html/document/src/xbl-marquee/resources/content/contents.rdf Try changing "xbl-marquee.jar" to "comm.jar".

the patch does NOT make sense: 1. RCS file: /cvsroot/mozilla/layout/html/document/src/Makefile.in,v ... +#DIRS=xbl-marquee ... should this be ... +DIRS=xbl-marquee ... 2. RCS file: /cvsroot/mozilla/layout/html/document/src/makefile.win,v +#DIRS=xbl-marquee should be +DIRS=xbl-marquee

Comment on attachment 92324 [details] [diff] [review] patch based on bobj's document >Index: layout/html/document/src/Makefile.in 02:55:21 -0000 >@@ -23,8 +23,10 @@ ... >+#DIRS=xbl-marquee #foo is a noop, why add it if you don't want it? >Index: layout/html/document/src/makefile.win >+#DIRS=xbl-marquee ditto >Index: layout/html/document/src/xbl-marquee/Makefile.in >=================================================================== >RCS file: layout/html/document/src/xbl-marquee/Makefile.in >diff -N layout/html/document/src/xbl-marquee/Makefile.in >--- /dev/null 1 Jan 1970 00:00:00 -0000 >+++ layout/html/document/src/xbl-marquee/Makefile.in 6 Jun 2002 17:06:05 -0000 >@@ -0,0 +1,174 @@ >+# >+# The contents of this file are subject to the Netscape Public New files should be MPL/LGPL/GPL not NPL*. This is well known policy and has been for a long time now. >+# The Original Code is mozilla.org code. what does this ^^ mean? could you perhaps say that the code is msie marquee emulation instead? it'd certainly be more useful >Index: layout/html/document/src/xbl-marquee/makefile.win >+# The contents of this file are subject to the Netscape Public again >Index: layout/html/document/src/xbl-marquee/resources/Makefile.in >+# The contents of this file are subject to the Netscape Public i probably shouldn't need to point to this anymore, at least you were consistently wrong. >Index: layout/html/document/src/xbl-marquee/resources/content/contents.rdf >+ chrome:displayName="XBL Marquee Replacement" replacement? what are we replacing? it's emulation. >+ chrome:author="Marquee de Sade" do we need humor in author fields? mozilla.org is currently trying to deal with people who complained about it in modulenames. general note, unless you're building somethimg, you might only need a jar.mn file and not *makefile* (also, nmake is going away rsn --really) >Index: layout/html/document/src/xbl-marquee/resources/content/xbl-marquee.xml >+ - The contents of this file are subject to the Mozilla Public License Version so much for being consistently wrong, here you used MPL as you should >+ - The Original Code is Netscape's XBL Marquee Replacement code. wow here you called it something useful instead of mozilla.org again, it's emulation, not replacement. but it's still better than the generic. >+ <binding id="marquee"> ... >+ <property name="scrollAmount"> >+ <getter> >+ if (this.hasAttribute('scrollamount')) >+ return this.getAttribute('scrollamount'); >+ return 6; //default value - 6 pixels can you use 'is' instead of '-'? >+ </getter> >+ <property name="scrollDelay"> >+ <getter> >+ <![CDATA[ >+ if (this.hasAttribute('scrolldelay')) >+ //marquee doesn't allow anything slower than 40 ms 1000/40=25, so marquee will update 25 times a second? are you sure you mean ms? or maybe it's the slower that got me, more later. >+ if(this.getAttribute('scrolldelay') < 40) please use if (...) to match the earlier style. >+ return 40; return before else, lose the else. >+ else return this.getAttribute('scrolldelay'); arg. silly structure >+ return 85; //default value - 85 ms try this: if (!this.hasAttribute('scrolldelay')) return 85; //default value is 85 ms var scrolldelay=this.getAttribute('scrolldelay') if (scrolldelay < 40) return 40; //marquee doesn't allow anything *shorter* than 40ms return scrolldeley; >+ ]]> there's trailing ^^ whitespace here -- lose it. and please change '-' to 'is' >+ </getter> >+ </property> >+ >+ <property name="direction"> >+ <getter> >+ if (this.hasAttribute('direction')) >+ return this.getAttribute('direction'); >+ return "left"; //default value - "left" - => is. >+ </getter> >+ </property> >+ >+ <property name="behavior"> >+ <getter> >+ if (this.hasAttribute('behavior')) >+ return this.getAttribute('behavior'); >+ return "scroll"; //default value - "scroll" ditto >+ </getter> >+ </property> >+ <property name="width"> >+ <getter> >+ <![CDATA[ >+ if (this.hasAttribute('width')) >+ return this.getAttribute('width'); return before else >+ else if (this.parentNode.offsetWidth > 0) >+ return this.parentNode.offsetWidth; return before else >+ else if (this.parentNode.parentNode.offsetWidth > 0) >+ return this.parentNode.parentNode.offsetWidth; return before else >+ else >+ return 1; >+ ]]> >+ </getter> >+ </property> >+ >+ <!-- For sniffing purposes --> >+ <field name="nsMarqueeVersion">0.9.3</field> trailing whitespace >+ trailing whitespace >+ <method name="start"> >+ <body> >+ <![CDATA[ >+ >+ this.stop(); >+ >+ if (this.scrollStarted == 0) >+ { >+ this.scrollStarted = 1; //we only want this run once "to run once" ... >+ if ( (this.dirsign == 1 && this.newPosition > this.stopAt) || random whitespace nits. ('1 &&' v. '-1 &&') >+ (this.dirsign == -1 && this.newPosition < this.stopAt) ) >+ { you don't need this brace ^^, but that's a personal pref. >+ switch(this.direction) >+ { >+ case 'up': >+ case 'down': >+ this.outerDiv.scrollTop = this.newPosition; >+ break; >+ >+ case 'left': >+ case 'right': >+ default: >+ this.outerDiv.scrollLeft = this.newPosition; >+ break; i don't see much point in this break, but that's a personal thing. >+ } ... >+ if ((this.direction != "up") && (this.direction != "down")){ >+ this.innerDiv.style.whiteSpace = "nowrap"; >+ } trailing whitespace >+ else { >+ height = 200 + 'px'; >+ this.outerDiv.style.height = height; >+ } that's kind of silly, why not: if ((this.direction == "up") || (this.direction == "down")){ height = 200 + 'px'; this.outerDiv.style.height = height; } else { this.innerDiv.style.whiteSpace = "nowrap"; } >+ //init needs to be run after the page has loaded inorder to calculate the correct "in order"

Comment #85 From timeless@mac.com > New files should be MPL/LGPL/GPL not NPL*. This is well known policy and has > been for a long time now. Yes. Good catch. My bad. I blindly cloned makefile.win and Makefile.in from another (old) directory.

Comment #85 From timeless@mac.com > >+ if ((this.direction != "up") && (this.direction != "down")){ > >+ this.innerDiv.style.whiteSpace = "nowrap"; > ... > that's kind of silly, why not: > if ((this.direction == "up") || (this.direction == "down")){ > ... direction can be up, down, left, or right. So these are not equivalent.

Nevermind my last comment #87...

Markus Niederlechner: > There are already an image pref with UI and this non-UI pref for blink (UI is > bug 106462): I am not suggesting changing the back end pref names, merely saying there should be a single pref in the UI. > I don't think that the blink/marquee pref(s) should be combined with the image > pref, because there are quite legitimate uses for animated images as content > (e. g. a world map that shows the decrease in rainforest areas), while marquee > (and blink) are pure presentation. There are valid uses of marquee-like effects too, but they are probably as rare as valid uses of animated images and therefore not worthy of a separate UI pref. > In what way has XHTML been more abused than HTML? In what way did that hurt > the users? XHTML is abused all the time by being sent as text/html without validating. I have seen many more cases of this than I have of an abused marquee tag. > In what ways would implementing this in Mozilla be better than studing the > relevant MS-docs and examining pages that use marquee or some JS-variant? It would give the Mozilla-related contributors to the CSSWG first hand experience with the issues, rather than second hand experience. > create a custom DTD [...] Sites that want marquee could use those DTD and be > perfectly valid No they wouldn't, it is invalid, per HTML, to use a custom DTD. > Mozilla should then only render marquees in pages with those DOCTYPE The problem is with existing pages, not with hypothetical pages. > Excatly the same as now, I think. So 'page breaks when printing' would not be > a problem for the "pro-marquee"-camp? Then why would it be a problem on > screen? It's hard to get a printed page to scroll. > I'm pretty sure evangelising this one would not be a lost cause Are you volunteering? Bamm Gabriana: > The question raised about how it will print is a valid concern. Moz currently > displays marquee inline thereby breaking page layouts. No, recent builds display marquee as a block-level element. Brendan asked me to restate what I think should be done, so: 1. Put marquee.xml and the relevant makefiles to edit html.css in layout/html/document/src/marquee/, so that a rebuild in layout/html/document/src/ would be all that is required to rebuild html.css and quirk.css. The marquee.xml file and html.css file should end up in the same directoy in the distribution. 2. The makefile should insert the following in html.css: /* emulation of non-standard HTML <marquee> tag */ marquee { -moz-binding: url(marquee.xml#marquee-horizontal); } marquee[direction="up"], marquee[direction="down"] { -moz-binding: url(marquee.xml#marquee-vertical); } @media print { marquee { -moz-binding: none; } } 3. The binding should have mouse and focus handlers to the binding so that it stops while the mouse is above it or the user has it or anything inside it focussed. This is needed for accessibility reasons, and is separate from allowing authors to hook into these event handlers.. 4. add the following to userContent-example.css: /* * example: turn off "marquee" element * * marquee { -moz-binding: none; } * */ 5. Make a single UI pref control blink, marquee, and image animations. (This should be handled in a separate bug.)

Let us china browser team join the hot topic! I didn't read all comments throughly. But as a browser user, I don't think <marquee> is a very important thing to me, even in chinese site. In most popular chinese sites, <marquee> is not used too often (<= 3 times), and usually didn't occupy the important place of the page. I won't feel uncomfortable if they are static. But I think mozilla at least shouldn't break page layout as Momoi said in comment 26.

Brendan Eich: > IE-promulgated innerHTML is a _de facto_ standard, which is just as valid as > any _de jure_ standard. The world does not improve much or often through > design-by-committee, or by waiting for the standards committees to figure out, > implement, debug, ship, and iterate an innovation as companies often do in the > marketplace. Well, innerHTML AFAIK doesn't conflict with anything in the de jure standard. But marquee is, as an presentational element, contrary to the current direction of that de jure standard. Also innerHTML is widely used, but marquees and marquee-like animations are as often generated with JS/Flash/Ani-GIFs as with the marquee-Element itself. So I don't think marquee is a de facto standard. > Hixie already said the committee is stymied by lack of real > world experience here. The DOM WG (as well as many other W3C committees) is mainly made up of people from the browser makers, so if they agree on implementing innerHTML, why can't they put it into the DOM? The DOM already has properties and methods for backward compability, one more (and a convenient and widely implemented/used one) wouldn't hurt much. > My point: there is nothing "arbitrary" in a legal sense about innerHTML just > because some w3c committee didn't standardize it. JS is a _de facto_ standard > that was codified with little change in ECMA-262 Edition 1, to return to my > earlier example. Innovations tested in various markets were then codified by > later editions. True, but that also led to incompatible things, like the event models. If it was standardised, that wouldn't have happened. I agree that there has to be a way to include experimental things that extend the spec, but that way has to be standardised and has to degrade gracefully (as with MIME (type/vnd.subtypes and type/x-subtypes), HTTP (X-headers) or CSS (-vendor-properties)). Just including them as if they were standardised risks interoperability. > That's at best a temporary argument (most of the web has been on a slippery > slope that expands core technologies to include newer ones; can you use > hotmail without JS?), and at worst a bogus argument now, today. According to Tim Berners-Lee in 'Weaving the Web', the core technologies of the web are (in order of decreasing importance): - URI - HTTP - HTML JS is an important supportive technology, but since not every UA can be expected to have it implemented and not every user can be expected to have turned it on, it's bad web design to make it mandatory. I've never used hotmail, but there are other freemailers out there that don't require JS. So having JS enabled is not fundamental to use free web mail, but I've yet to see a web mailer that doesn't use URI/HTTP/HTML. > Is CSS "core" or "supportive"? Let the flames begin! No flames there, because CSS is clearly defined as optional in the spec: From http://www.w3.org/TR/REC-CSS2/intro.html | Also, user agents with no CSS support will be able to display style-enhanced | documents. Of course, the stylistic enhancements made possible by CSS will not | be rendered, but all content will be presented. Ian Hickson: > XHTML is abused all the time by being sent as text/html without validating. I > have seen many more cases of this than I have of an abused marquee tag. Which (a) is excatly the same way that HTML is abused, (b) doesn't hurt users anymore than invalid HTML does and (c) has been made possible excatly by this attitude of browser implementers ("let's do arbitrary 'error correction' guesswork, since we can do what we want with invalid markup and professional web developers and the authors of tools for the non-professional ones can't be expected to know/follow the specs"). It's the browser makers putting the whole blame on the authors again (of course, the authors are guilty themselves for using those glitches, but the browser makers were the ones introducing them!) > No they wouldn't, it is invalid, per HTML, to use a custom DTD. A document claiming to be <!DOCTYPE HTML PUBLIC "-//mozilla.org//DTD Mozilla Experimental HTML 0.1//EN" "http://www.mozilla.org/dtd/exphtml01.dtd"> or <!DOCTYPE HTML SYSTEM "http://www.mozilla.org/dtd/exphtml01.dtd"> sent as text/x-mozhtml would. It's perfectly valid to create a custom application of SGML, the HTML spec doesn't apply here (it only applies for documents with DOCTYPES statet in the spec). It's invalid to extend the HTML DTD through adding a DTD subset to the DOCTYPE declaration or (worse) just using undefined elements without any formal definition. > The problem is with existing pages, not with hypothetical pages. Agreed. As I said, the problems wouldn't dissappear with this. My point is that encouraging the use of a non-standard element (therefore encouraging the breaking of the specs) is not justified for experimental purposes (like getting first-hand implementation experience). It would be probably better to implement a -moz-marquee property and not a marquee-element, to get first-hand CSS (and not HTML) implementing experience. > It's hard to get a printed page to scroll. That's a prefect reason why marquee doesn't belong into the device independent HTML, but rather into CSS. > I am not suggesting changing the back end pref names, merely saying there > should be a single pref in the UI. How would the pref UI handle different values of the individual prefs (blink false, images true in the (prefs|user).js)? > There are valid uses of marquee-like effects too, but they are probably as > rare as valid uses of animated images [...]. True, but as you said, marquee-like _effects_. If effects get disabled, not much is lost. If animations that are _content_ get not looped, it's dataloss. They may be rare, but I'm sure that there are even rarer dataloss bugs fixed. I propose two UI prefs, one for animations that can be content and one for animations that are pure presentation (maybe even animated images with empty ALT attributes). When future animation technologies arrive, I'm sure that the number of content providing animations will increase, so the user should be able to keep them on, while turning the purely presentational ones off (this should even be the default setting).

> The DOM WG (as well as many other W3C committees) is mainly made up of people > from the browser makers, so if they agree on implementing innerHTML, why can't > they put it into the DOM? The DOM is supposed to be markup-language-independent. The name "innerHTML" is not. "innerMarkup" would be.

I had to play with makefiles to make html.css to work. I'll remove DIRS=xbl-marquee from RCS file: /cvsroot/mozilla/layout/html/document/src/Makefile.in RCS file: /cvsroot/mozilla/layout/html/document/src/makefile.win

Changes in xpinstall/packager and embed-jar.mn are not included. We need little more testing on them. Meanwhile we can go ahead and start the review process for the layout timeless: can you review? jag: can you super review?

More info on the patch. The patch includes changes all changes suggested by timeless (comment #85) except for some of the personal prefs for style. Thanks As for Ian's summary at the end of comment #89: >1. Put marquee.xml and the relevant makefiles to edit html.css in > layout/html/document/src/marquee/, so that a rebuild in > layout/html/document/src/ would be all that is required to rebuild html.css > and quirk.css. The marquee.xml file and html.css file should end up in the > same directoy in the distribution. The new directory is layout/html/document/src/xbl-marquee/ marquee.xml will be added as chrome to comm.jar for Mozilla and embed.jar for Gecko-embedders. As Doron noted in comment #74, the just putting it into res/ does not work because of the security exception. >2. The makefile should insert the following in html.css: > > /* emulation of non-standard HTML <marquee> tag */ > marquee { > -moz-binding: url(marquee.xml#marquee-horizontal); > } > marquee[direction="up"], marquee[direction="down"] { > -moz-binding: url(marquee.xml#marquee-vertical); > } > @media print { > marquee { -moz-binding: none; } > } Done except for the patch uses a chrome:// URL for marquee.xml. See above about resource vs. chrome. >3. The binding should have mouse and focus handlers to the binding so that it > stops while the mouse is above it or the user has it or anything inside it > focussed. This is needed for accessibility reasons, and is separate from > allowing authors to hook into these event handlers.. Not done. Doron noted in comment #73: This would be adding stuff to the ms's marquee spec, which it allows already, but only if the website adds the appropiate event handlers. Not sure how good this would be. This thread stopped at that comment. >4. add the following to userContent-example.css: > > /* > * example: turn off "marquee" element > * > * marquee { -moz-binding: none; } > * > */ Done. >5. Make a single UI pref control blink, marquee, and image animations. (This > should be handled in a separate bug.) Out of scope for this bug. Let's file a separate bug and take the discussion there or elsewhere.

Comment on attachment 92448 [details] [diff] [review] patch against trunk tree doron's going to make a few minor changes

updating marquee.xml from doron. This inclueds eveything.

jag/brendan: please super review?

Comment on attachment 92495 [details] [diff] [review] Need to update xbl-marquee.xml carry over timeless's /r

Let's get a bona fide r= (one from the module owner or a peer), and then dbaron can sr=. /be

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending a positive sr= and Drivers' approval. Pls check this in asap, then replace "mozilla1.0.1+" with "fixed1.0.1". thanks!

i believe dbaron is out of pocket at this point in time, so we might have to have someone else sr= this one.

whichever of r/sr/moa=dveditz you need for the install script (*.jst) changes. Please don't forget to do the same in the Netscape install scripts.

dbaron commented yesterday (comment #76), he seems to be around. /be

Comment on attachment 92495 [details] [diff] [review] Need to update xbl-marquee.xml >Index: layout/html/document/src/xbl-marquee/resources/content/xbl-marquee.xml >=================================================================== >RCS file: layout/html/document/src/xbl-marquee/resources/content/xbl-marquee.xml >diff -N layout/html/document/src/xbl-marquee/resources/content/xbl-marquee.xml >--- /dev/null 1 Jan 1970 00:00:00 -0000 >+++ layout/html/document/src/xbl-marquee/resources/content/xbl-marquee.xml 24 Jul 2002 01:27:46 -0000 >+ <method name="init"> >+ <body> >+ <![CDATA[ >+ var height; >+ >+ if ((this.direction == "up") || (this.direction == "down")){ minor, but space the '{' out from the ')'. >+ <constructor> >+ <![CDATA[ >+ var myThis = this; >+ var lambda = function myScopeFunction(){myThis.init();} space this out a bit too. Looks good other than that, though I haven't actually tested it. r=bryner with those changes.

dbaron: please super review? (I'll fix the bryner's nit)

Comment on attachment 92495 [details] [diff] [review] Need to update xbl-marquee.xml sr=jst

Comment on attachment 92495 [details] [diff] [review] Need to update xbl-marquee.xml These changes are fine with me. One more nit: it's nice to terminate files with newlines: >Index: layout/html/document/src/xbl-marquee/resources/content/xbl-marquee.xml ... >+</bindings> >\ No newline at end of file One other commment: it might be good if someone somewhat familiar with potential security issues reviewed the XBL with an eye on security. Everything looks safe to me, but I'm not an expert. (jst probably is, though, and he already reviewed, and hopefully was thinking about such things.)

Yes, I did keep security issues in mind when looking through this XBL code, and I didn't see anything alarming.

This seems to have been checked in on the branch only, not on the trunk first, then branch-tagged. Also, where was the branch approval from drivers@mozilla.org? Please don't forget next time. /be

Brendan Eich: > IE-promulgated innerHTML is a _de facto_ standard, which is just as valid as > any _de jure_ standard. The world does not improve much or often through > design-by-committee, or by waiting for the standards committees to figure out, > implement, debug, ship, and iterate an innovation as companies often do in the > marketplace. Why then does this argument hold for <MARQUEE> and not for Bug 154589? Isn't it true that that bug refers to a de facto standard more widespread than either marquee or innerHTML?

marquee and innerHTML provide functionality that the standards don't (i.e. they are exensions); document.all is an alternative to the standards-preferred mechanism.

Comment on attachment 92493 [details] [diff] [review] Mac build change. r=nhotta

QA --> andreasb for reassignment. ji/yuying: can you pls verify this as fixed on the 1.0 branch. thanks!

Comment on attachment 92495 [details] [diff] [review] Need to update xbl-marquee.xml a=asa (on behalf of drivers) for checkin to 1.1

Comment on attachment 92493 [details] [diff] [review] Mac build change. a=asa (on behalf of drivers) for checkin to 1.1

Comment on attachment 92493 [details] [diff] [review] Mac build change. sr=bryner

Updated summary from: XBL emulation of marquee as a mozilla extension to: XBL emulation of marquee

*** Bug 159300 has been marked as a duplicate of this bug. ***

chak: can you review?

Comment on attachment 92815 [details] [diff] [review] opps, try again r=chak Adam should take a look too...

Comment on attachment 92815 [details] [diff] [review] opps, try again r=chak Adam should take a look too...

Removing fixed1.0.1, until the new patch is checked into the branch. after the latest patch is checked in, pls replcae "mozilla1.0.1+" with "fixed1.0.1". thanks!

Comment on attachment 92815 [details] [diff] [review] opps, try again Do you need to update embed-jar.mn as well or do the existing rules already copy the marquee stuff into embed.jar?

Adding myself to CC list... Author of http://webfx.eae.net/dhtml/xblmarquee/xblmarquee.html

Hi Adam : Looks like Roy's already added it to embed-jar.mn. Here's what i see in my embed-jar.mn(from the 1.01 branch): # Marquee stuff content/xbl-marquee, comm/content/xbl-marquee

r=adamlock. The trunk will require the change to embed-jar.mn though.

Roy will be checking in the bug fix the the trunk soon and it includes the same change to embed.jar made to the branch.

I received voicmail from Jud. a=valeski.

Clarifying previous comment #131 > I received voicmail from Jud. a=valeski. This approval is only for the branch

Roy, Check this into the branch as soon as it opens. Thx.

I'll check into the branch as soon as it _opens_. Com'on.....

Branch is opened. Checked in.

Comment on attachment 92815 [details] [diff] [review] opps, try again a=asa (on behalf of drivers) for checkin to 1.1

Everything is checked into the trunk and branch. Thanks all.

ok, now the <marquee> is in, and what do I need to say? It's full of bugs! I've added several CSS rules to get it usable. -> why to hell do we inherit the width? -> why the hell do we inherit background options? -> why the hell do we inherit borders? my Problem is, that these rules get overwritten, if they are added to the html.css. I'll attach a testcase, where these additions are added locally and can be disabled - it looks awefull without them!

ok, here comes the testcase.. I don#t want to know, how many pages out there behave like this!

From bug 159704: <MARQUEE DIRECTION="UP"> does not work <MARQUEE DIRECTION="up"> works fine. Same goes for "DOWN" / "down". Should the tag be case sensitive?

HTML and case sensitive? ;-)

jag: XML-Documents (as XHTML) are case sensitive, only oldstyle SGML/HTML isn't.

Re-opening, I bet the casesensitivity issue breaks lots of pages that use marquee, and fixing it is trivial...

I think we should restore this one as resolved. There's a new bug 159704: MARQUEE attribute values must be lower-case to work.

Ah, sorry, didn't know about the new bug. Marking as FIXED again.

I think Mozilla shouldn't see <marquee> tag because it is W3C standard. It is very important!!!

Verified marquee tag is working on 07-29 trunk build / WinXP.

xbl-marquee still doesn't work in following extraction from http://www.sohu.com: <marquee direction=up scrollamount=1 scrolldelay=100 onmouseover='this.stop()' onmouseout='this.start()' height=60> <!-- head_scrolltext --> <table width="100" border="0" cellspacing=0 cellpadding=0> <tr> <td> ¡¤<a href=http://goto.sohu.com/goto.php3?code=gdyh-0510frt target=_blank>½áʶ¹â ´óÒøÐУ¬ÏíÊÜÀí²ÆʱÉÐ</a><br><br> ¡¤<a href=http://goto.sohu.com/goto.php3?code=fulaide-0626frt target=_blank>¸£À´ µÃ×¢»á¡¢×¢ÆÀ¡¢¾­¼Ãʦ</a><br><br> ¡¤<a href=http://goto.sohu.com/goto.php3?code=goldenholiday-1217travelb target=_blank>ÁîÄúÂúÒâµÄ¹úÄÚ¹ú¼ÊÂÃÐвúÆ·¹©Ó¦ÉÌ</a><br><br> ¡¤<a href=http://goto.sohu.com/goto.php3?code=goldenholiday-1217travelb target=_blank>±±¾©ÖÁ¶«¾©Íù·µ3300Ôª</a><br><br> ¡¤<a href=http://learning.sohu.com/02/31/article202333102.shtml target=_blank>7 ÔÂ30ÈÕ19µãж«·½Ôº³¤ÔÚÏß½²ÊöÓ¢Óïѧϰ³É¹¦·½·¨</a><br><br> ¡¤<a href=http://yule.sohu.com/81/25/earticle164672581.shtml target=_blank>8ÔÂ1 ÈÕ15µã¡¶¿Õ¾µ×Ó¡·Å®Ò»ºÅÅ£Àò×ö¿ÍËѺü</a><br><br> </td> </tr> </table> <!-- end head_scrolltext --> </marquee>

Kai: I know XML documents are case sensitive. What I tried to say in my comment, without actually saying it, was that within an HTML context we should treat attribute values as case insensitive.

sohu works fine here :)

I created an html doc with the snippet from comment #148, and it WFM. Running commercial branch build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020726 Netscape/7.0

Damn, damn, I don't want wirly spinny things on sites I visit now just because of some tacky Chinese developers. Does anyone really believe that Moz will take off in China after this is implemented??? No, it just makes things worse for others. Does anyone even know that Chinese visitors like those godawful things? Maybe they hate them too. There is an xbl marquee simulation for Moz on Erik's webfx site. Chinese sites can add it to **their own pages** for their customers if they want. Or use js. Evangelize that fact. No need to add it to Mozilla whatsoever. The USA uses document.all heavily; no one is about to add that rather than evangelize the W3C DOM.

>>Additional Comment #113 >>marquee and innerHTML provide functionality that the standards don't (i.e. they are exensions); Nonsense. Marquee doesn't add anything we can't do with standard js. (Let alone binding or flash) Go to dynamicdrive.com and get a whirly spinny thing to add to your site if you want to annoy your visitors. Here's a whole page of them: http://www.dynamicdrive.com/dynamicindex2/index.html This tag is dead and dying - and for good reason - so why add it now? More sites use MS filters - going to add them? Personally I like them far more than marquee and can see a place in css for them. A handful of **** Chinese developers use this tag. Big deal. Moz will not take off in China after you add this. I see no evidence that 1) users want this, even in China - only the opposite, or 2) that adding it will actually work b/c of sniffing, etc., on sites that do use it. And if some do figure it out and it works? By next year those developers will probably have learned not to annoy their visitors, and then what? We're stuck with this garbage and a nasty deviation from what most - I hope - think Moz is all about.

*** Bug 80269 has been marked as a duplicate of this bug. ***

"This tag is dead and dying - and for good reason" - This tag is alive! More than you ever imagined. On the other hand, you have made your point: Now is the best time to re-evaluate all the bugs marked wontfix/invalid. For example Bug 29770, Bug 64019, Bug 109347, Bug 74201, Bug 130525 come to mind. We can get compatible the web as it is now. Where else would we want to go today ?

FYi - For those interested, China is now the Number 2 Market in the world for Web Traffic and PC sales (see story below). http://story.news.yahoo.com/news?tmpl=story&ncid=581&e=1&cid=581&u=/nm/20020801/tc_nm/tech_internet_china_dc_3

I think supporting non standars is OK and I support it as long as they only work as a preference. Will this mean the Marquee tag will work in Netscape 7?

So this is the browser that's for developers only and not targeted at end users. Evangelizing years on open standards and using HTML only for content, CSS for layout and scripting languages for dynamic actions. Now implementing a huge mistake in browser creation for gathering more users. Or was it for being a testbed for some workgroup? After reading this bug I still don't see any valid reason this bug for realising this functionality as anything else than an optional extension. If webdevelopers want anything to rely on it should be written standards and nothing else. But it seems like to know what to do and how there will still be only the way of trial and error and not in reading the standards paper. Should I now start to use -moz-opacity, -moz-border-radius and the like just because it's implemented? I thought that this was discouraged but I can't see the difference now. And why MARQUEE? If you say that it's because it's so much easier for webdevelopers then I'd have some examples of problems that developers have with standards that are realy hard to resolve. e.g. why does only a table cell have a vertical-align property? And why is it so difficult to give an element a size relative to the viewport? These can make developing pretty difficult if you try to use strict mode. Much more than adding a javascript library to the page as a simple replacement for MARQUEE...

From comment #157 > Will this mean the Marquee tag will work in Netscape 7? Yes.

I believe all nonstandard extensions should be lumped into a single pref: [ ] Allow nonstandard extensions This is good for evangelism, because end-users immediately know that a feature they are looking for is nonstandard, yet they see that we care enough to implement it for their sake. It is also good for developers who can now take a more liberal approach at implementing features that enhance compatibility with the current web. Pandora's box has been opened...

Bamm Gabriana: one pref for all nonstandard? Even for <td background="">? This doesn't make sense, as marquee/blink can be anoying, others normally not.

FYI: Bug 159839: Move marquee to quirks mode Bug 161049: Remove marquee support Bug 161109: Make marquee support a pref

Kai Lahmann: I wasn't talking about extensions that are already being rendered in quirks mode. Rather, I was refering to features that we want to emphasize are nonstandard so people can avoid them: marquee, blink, document.all, addFavorite, vbscript. This pref will serve as a central repository for other bugs that may become an evangelism issue. UI prefs should be constructed from a user's point of view rather than being too technical about it. My suggestion is important because of the message it sends to the potential user.

Please take the discussion out of this FIXED bug to a more appropriate forum (like the newsgroups).

I would propose this: Have a section in the "Preference", let's call it "Non-standard tags support", & provide users with an option to check & uncheck each individual non-standard tags, such as marquee, blink, etc..

I think this is a good idea. Also, we can put the known non-standard tags somewhere, such as http://www.mozilla.org/tags/non-standard, and make mozilla aware of it (also, give out the list to let users to choose to use).

marquee merchandise is now available at: http://www.cafeshops.com/cp/store.aspx?s=marqueeemporium.0

> marquee merchandise is now available LOL is there one for the BLINQUEE? :)

If it's interesting for anybody, xbl-marquee.xml can be hacked to remove autoscrolling and enable scrollbar. See bug 163048 comment 5 I have tested "hacked" xbl-marquee.xml on sites from list at comment 63, and didn't see something unwanted.

Can anyone fix the marquee up bug? Marquees where the direction is UP, don't show up.

Jamie, please file a new bug report with a testcase that demonstrates the bug.