Closed Bug 156979 Opened 22 years ago Closed 22 years ago

XBL emulation of marquee

Categories

(SeaMonkey :: Build Config, enhancement, P1)

Product:
SeaMonkey
Component:
Build Config
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.1beta

People

(Reporter: bobj, Assigned: tetsuroy)

References

(
URL
)

Details

(Keywords: topembed, Whiteboard: [adt2 RTM] [ETA 07/27])

Attachments

(4 files, 7 obsolete files)

Mac build change.
943 bytes, patch
nhottanscp
: review+
bryner
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Need to update xbl-marquee.xml
27.60 KB, patch
tetsuroy
: review+
jst
: superreview+
asa
: approval+
Details | Diff | Splinter Review
opps, try again
656 bytes, patch
adamlock
: review+
asa
: approval+
Details | Diff | Splinter Review
testcase
1.13 KB, text/html
Details 
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.
Summary: XBL emulation of marquee → XBL emulation of marquee as a mozilla extension
-> build config
Assignee: Matti → seawood
Component: Browser-General → Build Config
QA Contact: asa → granrose
topembed.  Assigned to yokoyama.  Cc'ed momoi.
Assignee: seawood → yokoyama
Keywords: topembed
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.
Severity: major → enhancement
OS: Windows 2000 → All
Hardware: PC → All
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
Status: NEW → ASSIGNED
Attached file doron's latest contents.rdf (obsolete) — 
doron's latest contents.rdf
Attached file doron's latest marquee.xml (obsolete) — 
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.
Attached file latest marquee.xml (obsolete) — 
fixes some whitespace and removes commented out code
Attachment #91117 - Attachment is obsolete: true
Blocks: 143047, 154896
Keywords: nsbeta1+
Whiteboard: [adt2 RTM] [ETA 07/15]
Target Milestone: --- → mozilla1.0.1
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.
Target Milestone: mozilla1.0.1 → ---
setting the priority and the milestone.
Priority: -- → P1
Target Milestone: --- → mozilla1.1beta
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?
URL: http://msdn.microsoft.com/workshop/au...
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
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.
Keywords: approval, mozilla1.0.1
Whiteboard: [adt2 RTM] [ETA 07/15] → [adt2 RTM] [ETA 07/23]
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 .)
Alias: marquee
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
Whiteboard: [adt2 RTM] [ETA 07/23] → [adt2 RTM] [ETA 07/24]
Attached patch patch based on bobj's document (obsolete) — — Splinter Review 
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)
Attachment #91116 - Attachment is obsolete: true
Attachment #91145 - Attachment is obsolete: true
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
Attached patch patch against trunk tree (obsolete) — — Splinter Review 
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?
Attachment #92324 - Attachment is obsolete: true
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
Attachment #92448 - Flags: review+
Attachment #92448 - Flags: needs-work+
Attached patch Latest (obsolete) — — Splinter Review 
updating marquee.xml from doron. 
This inclueds eveything.
Attachment #92448 - Attachment is obsolete: true

    
    

    
  


  
jag/brendan: please super review?

        Attachment #92480 -
        Attachment is obsolete: true

    
    

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

carry over timeless's /r

        Attachment #92495 -
        Flags: review+

    
    

    
  
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!
Keywords: adt1.0.1+

    
    

    
  
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

        Attachment #92495 -
        Flags: superreview+

    
    

    
  
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.

    
  
Keywords: adt1.0.1+ → fixed1.0.1

    
    

    
  
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

        Attachment #92493 -
        Flags: review+

    
  
Keywords: mozilla1.0.1 → mozilla1.0.1+

    
    

    
  
QA --> andreasb for reassignment.

ji/yuying: can you pls verify this as fixed on the 1.0 branch. thanks!
QA Contact: granrose → andreasb

    
    

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

a=asa (on behalf of drivers) for checkin to 1.1

        Attachment #92495 -
        Flags: approval+

    
    

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

a=asa (on behalf of drivers) for checkin to 1.1

        Attachment #92493 -
        Flags: approval+

    
    

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

sr=bryner

        Attachment #92493 -
        Flags: superreview+

    
    

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

    
    

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

    
    

    
  


  
chak: can you review?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        opps, try again
        — 
          — Splinter Review
      

    


  

        Attachment #92814 -
        Attachment is obsolete: true

    
    

    
  
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!
Keywords: fixed1.0.1 → adt1.0.1+
Whiteboard: [adt2 RTM] [ETA 07/24] → [adt2 RTM] [ETA 07/26]

    
    

    
  
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?

        Attachment #92815 -
        Flags: review+

    
    

    
  
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.

    
  
Keywords: mozilla1.1
Whiteboard: [adt2 RTM] [ETA 07/26] → [adt2 RTM] [ETA 07/27] [needs sr=]

    
    

    
  
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.



    
  
Keywords: mozilla1.0.1+ → fixed1.0.1

    
    

    
  
Comment on attachment 92815 [details] [diff] [review]
opps, try again

a=asa (on behalf of drivers) for checkin to 1.1

        Attachment #92815 -
        Flags: approval+

    
    

    
  
Everything is checked into the trunk and branch.
Thanks all.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: [adt2 RTM] [ETA 07/27] [needs sr=] → [adt2 RTM] [ETA 07/27]

    
  
QA Contact: andreasb → ylong

    
    

    
  
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!

    
    

    
  

      
      
      
      

        Attached file
          
        testcase
        — 
      

    


  
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...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED

    
    

    
  
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.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.1 → verified1.0.1

    
    

    
  
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).

    
  
Blocks: blinquee

    
    

    
  
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

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.
Product: Browser → Seamonkey

    
    

    
  
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.

    
    

    
  
A pox on these aliases! Users may want to check which bugs address marquees, and safety fixes to protect users against marquees.


Alias: marquee

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: