The default bug view has changed. See this FAQ.

non-animated mode pref (disabling marquee, t-d:blink, anim gifs, mngs)

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
P3
normal
15 years ago
10 months ago

People

(Reporter: Kai Lahmann (is there, where MNG is), Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {access, helpwanted, testcase})

Trunk
access, helpwanted, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [wgate])

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

15 years ago
the (proprietary) HTML-Tags <blink> and <marquee> can be very boring for users -
we should add an option (in the GUI) to disable the effects themself (the
-moz-binding on <marquee> and the text-decoration:blink; on <blink>)
(Reporter)

Comment 1

15 years ago
gar.. ! "Prefeerenced" should be renamed to "Preferences Window"...
Assignee: ben → attinasi
Status: UNCONFIRMED → NEW
Component: Preferences → Layout
Ever confirmed: true
QA Contact: sairuh → petersen
Yes, I shouldn't have to use the Zap cheap effects bookmarklet every time I run
in to a page containing that garbage...

Comment 3

15 years ago
UI pref for blink -> bug 106462

Comment 4

15 years ago
i want to cut off those little bastard <blink>'s and <marquee>'s heads ;)
Summary: add an option to disable DHTML-Tags → add pref for disabling annoying non-standard HTML elements ("DHTML Tags")

Updated

15 years ago
Priority: -- → P3

Comment 5

15 years ago
This can go two routes-it can become a meta bug for bug 106462 and there can be
a new bug for a marquee pref (bug 161049 is for REMOVING marquee) or this can
become the bug to remove marquee.
Keywords: helpwanted

Comment 6

15 years ago
Blocking bug #24413, according to
http://www.w3.org/WAI/UA/UAAG10-TECHS/guidelines.html#tech-on-off-blinking-text
Blocks: 24413
(Reporter)

Comment 7

15 years ago
stylesheet for the "don't go on users nerves" bug for marquee:

marquee{
	-moz-binding:none;
	overflow:auto;
	display:block;
}

the display:block; is another bug waiting for checkin - and so required to test
on the current code.
doron, how do you get the height for vertical marquee? I guess we still need
that for this mode.
Created attachment 95581 [details] [diff] [review]
implementation of marquee pref

This patch implements a pref, "browser.display.enable_marquee", and sets the
default to false.
Comment on attachment 95581 [details] [diff] [review]
implementation of marquee pref

Note that this patch does not have UI for the pref.  Rather, it's a hidden pref
that distributors could set.
(Reporter)

Comment 10

15 years ago
David: I guess, that this should find friends everywhere...
Comment on attachment 95581 [details] [diff] [review]
implementation of marquee pref

I should remove the |aMedium| checks -- those were from when I was writing the
patch to work the other way around.

Comment 12

15 years ago
This should have "sec508" keyword because it blocks Section 508 requirement:

   (h) When animation is displayed, the information shall be displayable in at
   least one non-animated presentation mode at the option of the user.

I would add it myself, but I can't because someone decided to play games with my
privs.

Comment 13

15 years ago
Adding access and sec508 keywords.
Keywords: access, sec508
Taking bug.  I'll try to get this in for 1.1a...
Assignee: attinasi → dbaron
Component: Layout → Style System
Priority: P3 → P2
QA Contact: petersen → ian
Whiteboard: [patch]
Target Milestone: --- → mozilla1.2alpha
Created attachment 96164 [details] [diff] [review]
revised patch
Attachment #95581 - Attachment is obsolete: true
Why not do the pref checking in the xbl?

Comment 17

15 years ago
dbaron's patch(attachment 96164 [details] [diff] [review]) can't be applied for 1.1
on my Linux. Compiler can't find nsIPref.h.

Comment 18

15 years ago
What is the likelihood of this being put in the 1.0.x branch? Since the
<marquee> tag has slithered into there, the ability to switch the vile
thing off should be put in as well.
As I have mentioned in other bugs, if there is a UI pref for this, it should be
the same UI pref which disabled blink and animated GIFs and other things that
make for a "non-animated presentation mode". Please, don't add a gazillion prefs
for each of the various ways of animating text.

Comment 20

15 years ago
I have hacked xbl-marquee.xml to provide scrollbar instead of automatic
scrolling. This is only a "hack", but you can use it just now to disable
annoying behavior of <marquee>.

It would be nice to add user pref for this, e.g.
user_pref("browser.marquee.behavior", "autoscroll" | "block" | "scrollbars" );

Please, test it. For details see
http://bugzilla.mozilla.org/show_bug.cgi?id=163048#c5
> dbaron's patch(attachment 96164 [details] [diff] [review]) can't be applied for 1.1
> on my Linux. Compiler can't find nsIPref.h.

That's because the patch for bug 71257 changed the REQUIRES line in the
relevant Makefile.in.
nsIPref.idl says:

 47 /*
 48  * This entire interface is deprecated and should not be used.
 49  * See nsIPrefService and nsIPrefBranch for the new implementations.
 50  */

I strongly second that sentiment... Please switch to nsIPrefService.  Though
that _does_ force you to implement nsIObserver instead of just using a static
callback...

+    if (aRuleData->mDisplayData->mDisplay.GetUnit() == eCSSUnit_Null)
+      aRuleData->mDisplayData->mBinding = nsCSSValue(eCSSUnit_None);

Shouldn't you be checking mBinding's unit?

+  tag = getter_AddRefs(NS_NewAtom("MarqueeDisableRule"));

I always get confused when I see this usage of getter_AddRefs... maybe use
dont_AddRef?  Either way, though.

+PR_STATIC_CALLBACK(int)

PRInt32?

You don't seem to release mMarqueeDisableRule anywhere...  is there really a
reason not to have that be an nsCOMPtr<nsIStyleRule> ?

Changing the pref won't dynamically restyle the documents that are already
loaded, right?  Is that what we want?

Comment 19 does not apply to this bug so far, since this is all back end, no UI.
 I agree that there should only be one front-end checkbox, but separate back-end
prefs (the checkbox will toggle multiple prefs at once).  That gives embeddors
the flexibility to ship whatever UI and default settings they want.

Comment 23

15 years ago
Can I read user prefs within XBL method? If yes, we could choose desirable
behavior of <marquee> directly in xbl-marquee.xml.

Updated

15 years ago
Blocks: 106462, 163048
you should beable to check prefs from xbl

Comment 25

15 years ago
Doron, unfortunately attempt to access prefs in XBL causes exception
"enablePrivilege not granted".

See bug 163048 comment 8 for more details. I'll be indebted to you for any
suggestions.

Updated

15 years ago
Blocks: 92997

Comment 26

15 years ago
Created attachment 98333 [details]
Testcase

Comment 27

15 years ago
Jacek, I has tested your testcase on my XBL which provide scrollbar for
<marquee> instead of autoscroll (see bug 163048).

Because of this emerges a question: my XBL generates a horizontal scrollbar
although width of marquee area is <= than width if container; so scrollbar is
unusable. On the other hand, nevertheless, this scrollbar signifies that
<marquee> tag is present at HTML code, this might be helpful for some users.

I would ask participants of discussion, which alternative should be better in
this case.

Comment 28

15 years ago
Just give me a UI and a pref to turn off BLINK and MARQUEE.  Both.
Target Milestone: mozilla1.2alpha → mozilla1.2beta

Updated

15 years ago
Keywords: testcase
Created attachment 102724 [details] [diff] [review]
revised patch for backend of marquee pref
Attachment #96164 - Attachment is obsolete: true
Comment on attachment 102724 [details] [diff] [review]
revised patch for backend of marquee pref

> +  nsCOMPtr<nsIAtom> tag;
> +  tag = getter_AddRefs(NS_NewAtom("MarqueeDisableRule"));

do_GetAtom, perhaps?

> +MarqueePrefObserver::MarqueePrefObserver() { NS_INIT_ISUPPORTS(); }

Add an assertion that gHaveMarqueePref is null?

r/sr=bzbarsky with that.
Attachment #102724 - Flags: superreview+
Created attachment 102728 [details] [diff] [review]
patch for backend of marquee pref

Revised per bzbarsky's comments.  I made the atom change in a number of other
places where the same pattern occurs.
Attachment #102724 - Attachment is obsolete: true
Comment on attachment 102728 [details] [diff] [review]
patch for backend of marquee pref

Transferring sr.
Attachment #102728 - Flags: superreview+
Comment on attachment 102728 [details] [diff] [review]
patch for backend of marquee pref

>Index: modules/libpref/src/init/all.js
>===================================================================
>+pref("browser.display.enable_marquee",      false);

Cool :)  After all the debate though in the original "support marquee" bug,
please make sure that distributors know about this.  A release note may be a
good idea.


>Index: content/html/style/src/nsHTMLStyleSheet.cpp
>===================================================================
> nsresult
> HTMLStyleSheetImpl::Init()
> {
>+  if (!gHaveMarqueePref) {
>+    gHaveMarqueePref = PR_TRUE;

Don't you want to wait on setting gHaveMarqueePref until after we know we can
get the pref?

>+    nsresult rv;
>+    nsCOMPtr<nsIPrefService> prefService = do_GetService(kPrefServiceCID, &rv);
>+    if (NS_SUCCEEDED(rv)) {
>+      nsCOMPtr<nsIPrefBranch> branch;
>+      rv = prefService->GetBranch(kMarqueePrefBranch, getter_AddRefs(branch));
>+      if (NS_SUCCEEDED(rv) && branch) {
>+        branch->GetBoolPref(kMarqueePrefName, &gEnableMarquee);
>+        nsCOMPtr<nsIPrefBranchInternal> branchInternal
>+            = do_QueryInterface(branch);
>+        if (branchInternal) {
>+          nsCOMPtr<nsIObserver> observer = new MarqueePrefObserver();
>+          if (observer) {
>+            branchInternal->AddObserver(kMarqueePrefName, observer, PR_FALSE);
>+          }
>+        }
>+      }
>+    }
>+  }


r=caillon otherwise.
Attachment #102728 - Flags: review+
I am planning to announce this to the API-changes list.  The reason I set
gHaveMarqueePref early was that if we are for some reason running in a pref-less
installation or one where prefs are broken in some way, we don't go to the
service manager every single time.
Ah.  Makes sense.  Wanna comment that?
I added the comment in my tree:

    // Set |gHaveMarqueePref| now, so we don't recheck if something fails.
Doron, BobJ:  Is this OK with you?  The patch makes a marquee pref that's
disabled by default, so anyone who wants to distribute a marquee-enabled Mozilla
would need to add

pref("browser.display.enable_marquee", true);

to their default preferences.
fine with me, we can turn on the pref for commercial.

Comment 39

15 years ago
Nice, but I would see 3 choices for marquee behavior: autoscroll, block and
scrollbars. Cite from bug 163048:

AFAIK <marquee> support was introduced mainly for Chinese users - see test pages at:
http://bugzilla.mozilla.org/show_bug.cgi?id=156979#c63

And if we'll parse <marquee> just as <div>, appearance of these pages will be
violently distorted. <marquee> has attributes WIDTH and HEIGHT, parsing as
simple <div> causes incorrect rendering width and height of <marquee> block and,
therefore, destroying page layout.

I tried to find method for displaying <marquee> which doesn't destroy appearance
and preserve usability.

But literally following W3C standards, we must render <marquee> as unknown tag,
i.e. simple ignore it and render even not as <div>, but as <span>.

As a result we have 4 alternatives to render <marquee>:
1. As inline element (conforms to standard, but completelly destroies page layout);
2. As <div> (better corresponds meaning of this tag, but causes layout problems);
3. With autoscrolling (exactly as MS Internet Explorer, preserves page layout,
but annoies users and causes usability problems);
4. With scrollbar (preserves page layout, saves usability and doesn't annoy).

I think, all 4 alternatives could be embodied in preferences, but it seems to me
that scrollbar might be a better choice.

Draft XBL for scrollbar emulation of marquee is available at:
http://bugzilla.mozilla.org/attachment.cgi?id=97516&action=view
one question - will this break people who use a external xbl file for <marquee>?
 That is valid...
No, it  should only override user or ua level styles.  (I haven't actually
tested, though.  Do you have a testcase?)

Comment 42

15 years ago
Is the ability to disable <marquee> by editing userContent.css,
insufficient?  The lines needed are already there as comments which
a user or distributor, could easily un-comment.  See
http://lxr.mozilla.org/seamonkey/source/profile/defaults/chrome/userContent-example.css
 25 /*
 26  * example: turn off "marquee" element
 27  *
 28  * marquee { -moz-binding: none; }
 29  *
 30  */

If this is done, I believe mozilla will resort to the old behavior
and treat the unknown marquee tag as a <div>.  We could default
it the other direction for mozilla and change it for commercial.

However, see previous comments about layout problems associated
with treating marquee as a div.  I like the scrollbar suggestion
that would preserve the page layout.

For whatever we do, make sure our testcases include both
horizontal and vertical marquees.
Bob, in theory that would work, but it doesn't because of the way XBL works. 
Once you load a binding, there is no way to unload it currently.  See bug 119078
and bug 163023 which look like dupes of each other.
a=rjesup@wgate.com for trunk checkin.  We at Wgate want this too.

Added 119078 and 163023 as dependencies, since I think the -moz-binding: none
solution would be preferable to a pref (unless we wanted to go for a fancier
solution with multiple ways to handle <marquee>).
Depends on: 119078, 163023
Whiteboard: [patch] → [patch][wgate]

Updated

15 years ago
Attachment #102728 - Flags: approval+
http://bugscape.mcom.com/show_bug.cgi?id=20559 filed to track this for embedding
(Reporter)

Comment 46

15 years ago
is it possible to set this userContent.css stuff over UI?
Comment on attachment 102728 [details] [diff] [review]
patch for backend of marquee pref

Fix checked in to trunk, 2002-10-14 17:06/07 PDT.

Leaving bug open for other work.
Attachment #102728 - Attachment is obsolete: true
Comment on attachment 102728 [details] [diff] [review]
patch for backend of marquee pref

I've changed my mind about this, and decided that I want to back this out.  See
my comments in bug 156979 comment 30.

Comment 49

15 years ago
David, do you agree that scrollbar might be reasonable compromise?

Comment 50

15 years ago
David: If you won't cooperate and rid us of the evil marquee, someone will
eventually back out your backout. :)

This bug is not an issue of compatibility, it's an accessibility issue. We're
violating section 508 requirements as well as numerous other accessibility
documents. I can't understand why the <MARQUEE> tag means more to you than that.
The section 508 requirement in question can't be enforced for pages using the
DOM and JavaScript, so I don't see why it's relevant to MARQUEE.  In fact, I
don't see any reason MARQUEE is any worse for accessibility than the ability to
use script on web pages.  In fact, it's probably not as bad since it can be
styled in userContent.css.
As I said over a month ago, the UI for this pref should be the same UI which 
disables blink and animated GIFs and other things that make for a "non-animated 
presentation mode". That's what's needed for the sec508 problem.
Incidentally, a=asa r=hixie on the backout to re-enable <marquee> on the trunk.

Comment 54

15 years ago
I'm really disappointed. IMHO, the only sense for supporting marquee is
preservation of page layout, because usually marquee are advertizing text which
only annoies and distract user from useful content on page.

Support of marquee as prolate MSIE extension is certainly attractive challenge
for Mozilla hackers and I'm amazing this accurate XBL emulation.

But we make our browser not only for our delight, but for end users. I consider
that scrollbar emulates marquee by more user-friendly method, and I would hear
serious arguments for autoscrolling against scrollbar.

Comment 55

15 years ago
Autoscrolling:  Perfect MSIE emulation.  Great for ad companies.
Scrollbar:  Better for readability via many screen readers for blind, etc...
Disble:  Less annoyance, period.

Make everyone happy.  Just put it in as a tri-state pref and tell me what the
pref is.  

Comment 56

15 years ago
Wasn't the idea to have one front-end checkbox (as Hixie said in comment 52)
that would set the seperate backend prefs for marquee, blink and all those other
annoyances?
Why would that require backing out this pref? Or if all these annoyances really
should be controlled by one pref, could we at least wait with removing _this_
one until someone has created that unified pref?
I agree with Hixie, a general accessibility should turn off marquee.
I would like to clarify that this bug is *not* for discussing marquee, *nor* for
discussing how to make marquee look prettier.

This bug is there for accessibility and usability reasons. The enhancement to be
worked on in this bug is supposed to be a GUI pref called something like "Ignore
annoying HTML elements" and should change the behaviour of tags such as
<marquee> or <blink> *at once*.

Comment 59

15 years ago
>The section 508 requirement in question can't be enforced for pages using the
>DOM and JavaScript, so I don't see why it's relevant to MARQUEE.

Yes, it can. If a user encounters a page with JavaScript animations they can
turn it off in Preferences. We need the same accessibility for marquee.

Even if you *do* think that for some reason Mozilla has an obligation to those
flickering Chinese sites that [mis]use marquees, there's absolutely no reason we
can't at least have access to a pref to turn it off! Especially since the code
already exists (a simple change to all.js would make it be enabled by default)!
And when there are accessibility documents that *mandate* that there be a way to
turn animations off, there really is no excuse for you to be backing out this pref.

No longer can you say "if you want it so bad, write a patch" because the patch
already exists, and you created it yourself! Now you're backing it out like a
fool. I suggest you think about what you're doing here.
Part of the reason I want to back the patch out is that it's too much code for
such a simple pref, and I don't like the design of it.  I'd rather see this pref
be part of a larger architecture for a auto-written user-stylesheet.

That said, we do provide a way to disable marquee.  You can edit
userContent.css.  That will do anything that this pref does.
(Why did I write a patch I didn't like?  Because I felt under pressure from
people who were threatening to quit in order to get their way.  That's a bad
precedent to set, and that's why I want to back the patch out entirely.)
> That said, we do provide a way to disable marquee.  You can edit userContent.css.

David, can you provide a rule that actually works then?

  marquee { -moz-binding: none }

does not, as I pointed out in comment 43.
  marquee { -moz-binding: none }

...really _should_ work, if it doesn't then we have an error in the cascade.
That doesn't remove the binding, it should prevent the binding from being set in
the first place.

If it really doesn't work please file a bug.

Comment 64

15 years ago
I think, the best choice might be reading user prefs directly in XBL, see
comment 23. This could spare us C++ code for this pref (David, is it what you
want?) and add flexibility for further similar issues (for example, to turn off
<blink> via XBL).

But unfortunately XBL is executing in current page context and can't read user
prefs (comment 25). Can we allow chrome XBLs (not XBLs from Web page, of course)
to read prefs? And what we must do for it?
Re comment 62: I just added the rule:

marquee { -moz-binding: none; }

to my userContent.css and marquees stopped animating.  I have no idea where this
myth about -moz-binding came from, but it's determined by the cascade just like
any other property.
Backed out.
See news://news.mozilla.org:119/slrnarvt66.k63.dbaron@is02.fas.harvard.edu for
an explanation of my reasons.

Comment 68

15 years ago
When was marquee originally checked in? After 1.1? We should mention the
-moz-binding CSS to disable it in the release notes if we're going to mention
the addition of support for an IE extention (and an annoying one at that).

Is marquee disabled in Strict?

Comment 69

15 years ago
David, I have read your explanation, but I can't agree with your reasons.

> Having forks in the code hurts testing and development.
Yes, 100% yes. But editing userContent.css to disable marquee is wrong method as
compared with preferences GUI. Reasonable solution might be reading user prefs
directly in XBL.

>Having an implementation of marquee improves our compatibility with the web,
>and we are a web browser.
Maybe, maybe...
But does this mean that we must support _all_ MSIE extensions _exactly_ as MSIE?
We don't support <bgsound> (one of favorite backdoor for e-mail viruses in
Outlook), VBscript or ActiveX - and must we support it in future?

I can't see any advantage for autoscrolling against scrollbar (for example).
Marquee in 99% cases is being used for advertizing - and the fact that you
prefer the most annoying implementation for marquee denotes that you more like
ad companies than end users.

>Much of the opposition to marquee is related to marquee being
>nonstandard, yet few people have objected to the many nonstandard
>things we do because Netscape 4.x, and in some cases also MSIE for
>Windows, do them.  Nor do people object to all the tiny details of
>layout that we imitate despite that they are not described in any
>standard
I don't argue, MSIE have some non-standart, but very useful extensions, such as
innerHTML and offsetWidth properties or transformNode method.

But marquee isn't useful for webserfers. Layout problems can be solved with
scrollbar. Another problems? I don't see it, maybe, you do?

>From an accessibility perspective, marquee is not nearly as bad
>as the equivalent script
Yes, but I always can turn off annoying scripts via prefs - both wholesale (all
JS) and by retail (pop-ups, reading cookies, substitution of status bar etc.).
But thanks to your diligence we lose pref for marquee.

Summing up: you tell reasonable things. But in this case your arguments miss
beside the mark.

My propositions:
1. Allow reading user prefs from chrome XBLs. I don't know how to do it, but, I
hope, this isn't a hard work. I have opened bug 177660 for this issue.

2. Create XBL for marquee with tree alternates (block, scrollbar, autoscroll).
with scrollbar as default. If reading user prefs within XBLs will be allowed, I
engage myself to write this XBL soon.
Depends on: 177660

Comment 70

15 years ago
Related: Bug 159704 (some fixes for marquee)
> Reasonable solution might be reading user prefs directly in XBL.

That adds extra bloat and performance loss to our XBL loading just for this
trifle of all tags that is used highly infrequently.  If you mean from with the
XBL content as opposed to the backend, then you are still incurring a
performance hit as opposed to the userContent.css method, because you have
already paid the cost for the binding at that point.

> does this mean that we must support _all_ MSIE extensions _exactly_ as MSIE?

No.  We don't even support marquee exactly as MSIE does.  We support it
partially, so that 99% of the sites that use marquee work.  To get the other 1%
to work, we would have to do an insane amount of work, which is not feasible. 
We support this because it was easy to support what we did, and because there
are sites that require it.  Go look at some of the other bugs where Bob Clary
posted the links to sites that need this.

> Marquee in 99% cases is being used for advertizing

Marquee in 99% of cases isn't even used.  I find it hard to believe that this
annoys this many users as often as wolf is being cried.  What I do when I visit
sites that annoy me is *gasp* stop visiting them.

> I always can turn off annoying scripts via prefs

You totally missed the point.  If you force authors to write JS, then their
content is in (generally) the JS:

  |var textToShow = "Sniper Caught!  Rifle Found in Car is Tied to Killings";|

If you disable JS, you lose that content completely and have no idea that the
sniper is caught.  However if you just disable the binding, you still are able
to see the content, and access its linked text if there is a link embodying it.

Comment 72

15 years ago
>That adds extra bloat and performance loss to our XBL loading just for
>this trifle of all tags that is used highly infrequently.
Almost 2 month ago I wrote a draft XBL to provide three alternates. Its size was
14K against 11K of original XBL. Is this a bloat?

Perfomance loss isn't a problem because execution time would be increased only
by time to switch statement - code for another choices isn't being executed
anyway. More serious problem is performance loss during autoscrolling - and
ability to turn off marquee or scrollbar emulation of it saves this time.

>We support this because it was easy to support what we did,
>and because there are sites that require it
Your arguments against scrollbar emulation?

>However if you just disable the binding, you still are able
>to see the content, and access its linked text if there is
>a link embodying it.
Why I must edit some files in my profile manually to tune up my browser? What is
an conceptual reason to deny turn off marquee via preferences dialog?
>I can't see any advantage for autoscrolling against scrollbar (for example).
>Marquee in 99% cases is being used for advertizing - and the fact that you
>prefer the most annoying implementation for marquee denotes that you more like
>ad companies than end users.

We support JavaScript and Image, which are mostly used for ads.  So should we
turn those off too?

Get real, how many here have encountered a site using marquee in daily
websurfing? I haven't and I wrote the original impl. 

You who hate marquee should be happy we implement it - this will make sites go
from hacked up javascript/flash/java tickers to <marquee>, and then you can
disable them all at once with some css changes.

Comment 74

15 years ago
>We support JavaScript and Image, which are mostly used for ads.
>So should we turn those off too?
We have very flexible prefs to control JS and images which allow turn off
annoying ones without affect to necessary scripts/images.

And we haven't any prefs to control marquee without profile hacking. Is it correct?

>Get real, how many here have encountered a site using marquee
>in daily websurfing?
Alas yes, practically daily. Furthermore, webmasters get to know that marquee
now works in Gecko browsers and this evil extends more and more.

Fortunately I use my own XBL which provides scrollbar ;))) and I want users to
be enabled choose desired behavior: I consider they to have this right firmly.

>I haven't and I wrote the original impl.
Great work, really. I'm not programmer, only webmaster and I'm amazing. If bug
177660 will be fixed, I shall consider for honour to bring the modest
contribution to your work.

Another argument in favour of scrollbar: autoscrolling causes usability problems
even if you like content of marquee.

Assuming that you see page with marquee. Two troubles are possible.

First case: text or link that would interest you, is placed far in the tail. You
must wait a long time to see it - and probably you simply willn't wait until it
will appear on screen and therefore you willn't notice it.

Second case: interesting link appears in first place, you notice it, but while
you read remaining content at page, the link is crept away. And agonizing
suspense again...

Scrollbar easily solves both problems, gives instant access to any passage in
marquee and doesn't annoy. And it saves main advantage of marquee - preserves
page layout. I use scrollbar XBL about 2 months and to me never there came an
idea to return to an autoscrolling. Simple test it - and I hope, you will agree
with me.

Finally - let user to choose how he want to see marquee. Let not consider, that
we it is cleverer than him.

Comment 75

15 years ago
Doron, disabling marquee with some css changes is only feasible for the elite
few.  If Mozilla is to continue to expand market share, we must not frustrate
our userbase with a feature that a significant percentage feel negative about,
unless we give them a way to disable that feature within the realm of their
understanding and ability. Adding a marquee to a site using the marquee tag is a
lot easier than doing so with JavaScript or Flash. The importance of this bug
will only grow over time. The bottom line is, we need a pref with UI for
disabling marquee. 

Leaving marquee on as a default is not a problem, as long as there is UI
available to turn it off.
Whiteboard: [patch][wgate] → [wgate]
>Doron, disabling marquee with some css changes is only feasible for the elite
>few.  If Mozilla is to continue to expand market share, we must not frustrate
>our userbase with a feature that a significant percentage feel negative about,
>unless we give them a way to disable that feature within the realm of their
>understanding and ability.

So Internet Explorer, which has marquee, owns the market.  I fail to see why
people would not move to mozilla because of marquee.  I see no diemarquee.org
movement trying to get rid of it in IE.

If there is a pref that would help accessible users (not sure how they are
actually called), and if that pref by chance also gets rid of annoyances, then
that sounds fine.  Just targetting marquee is plain childish, our market share
increased a bit even during the period we added it.

If you really want to make the browser better, then create one pref that rules
them all, not one pref for each minor kingdom that wants something...
Why do I feel like I am repeating myself. This pref's UI should be the same UI 
which disables blink and animated GIFs and other things that make for a 
"non-animated presentation mode". That's what's needed for the sec508 problem.
Summary: add pref for disabling annoying non-standard HTML elements ("DHTML Tags") → non-animated mode pref (disabling marquee, t-d:blink, anim gifs, mngs)

Comment 78

15 years ago
I can't agree with global "non-animated" pref. Animated gifs (and particularly
MNGs) often contain essential information. I use animated gifs occasionally, for
example, I have used it to demonstrate new design of combustion engine. If user
will turn off animation, he willn't see how this engine works. Of course, I
could use AVI or Java applet in this case, but animated gif appears as the most
compact and compatible solution.

But marquee animation doesn't contain additional information besides it content.

>So Internet Explorer, which has marquee, owns the market.  I fail to see
>why people would not move to mozilla because of marquee.
>I see no diemarquee.org movement trying to get rid of it in IE.
>our market share increased a bit even during the period we added it
Rather, exactly rather. Millions of users make mass demonstration and scan:
"Give us marquee! Give us marquee!".

And they install Mozilla instead of MSIE not thanks to it security, standards
compliance and usability but exclusively being inspired marquee support...

"I don't believe" - said Stanislavsky in similar cases. I consider that marquee
support doesn't affect to user choice or even affects negatively. And
overwhelming majority of my friends and coworkers consider same.

The only benefit of marquee (according bug 156979 comment 63) is preserving of
page layout. Scrollbar solves this problem by more considerate way. Your
arguments against?
I am baffled as to why you care _so_ _much_ about <marquee> but make so little
fuss about MNGs, our non-standard DOM support, our screwed up non-standard
inline box model, <blink>, and the myrad or other potentially annoying features.

The fact is that while _you_ find <marquee> annoying, a number of our users
(primarily in the Chinese market) like it, and find that many of their sites are
significantly better because of it.

If you are so irritated my this feature then either disable it or avoud sites
that use it. The fact of the matter is that most of our users don't even know
<marquee> when they see it, and have even less against it. A pref just for that
feature would simply complicate our UI while providing little tangible benefit
to the majority of our users.

Comment 80

15 years ago
OK, our dispute can be solved only by one way. Let chinese users (unfortunately
I know no one from China, maybe you do?) test scrollbar XBL and then share their
impressions in this thread.

Comment 81

15 years ago
> I am baffled as to why you care _so_ _much_ about <marquee> but make so little
> fuss about MNGs, our non-standard DOM support, our screwed up non-standard
> inline box model, <blink>, and the myrad or other potentially annoying features.

Nobody uses MNGs yet, DHTML animations are uncommon because it would take a
significant amount of programming to annoy the user, the box model doesn't
particularly bother me as a web surfer (I might gripe about it if it comes up
when I'm developing), and BLINK has a hidden pref (bug 106462 to put it in the UI).

The only annoyances that appear with any regularity, because of their easy use,
are BLINK tags and MARQUEE tags. They are dangerously popular on auction sites
(and you really can't "avoud [sic] sites that use it" because there may only be
one auction for the item you want).

As for the argument that there are no sites protesting Marquees... A simple web
search found me this site:

<http://mozilla.weebeastie.net/marquee.shtml> - The fix no longer works thanks
to David's actions. His complaint (a valid one) is that he cannot read scrolling
text on his passive matrix LCD screen.
Editing userContent.css still works.
"DHTML animations are uncommon because it would take a significant amount of
programming to annoy the user"

yet there are move dhtml marquees that <marquee> on the web...
*** Bug 106462 has been marked as a duplicate of this bug. ***

Comment 85

15 years ago
Again: editing userContent.css is too complicated for unexperienced users.

Usability problems with marquee aren't far-fetched (see comment 74 and comment 81).

Many users wannot see marquee animation. I have asked 41 user in our company, 32
are against marquee autoscrolling, 7 think indifferently and only 2 are pro -
they are sales managers ;)

If you refer to chinese users to like marquee, please, let me hear them here or
communicate with them directly.

I still consider that the most constructive and convenient way to solve this
issue is fixing bug 177660.

And, please, do not combine in one preference disabling marquee and animated
images. Marquee and blink might be combined, but it willn't be sufficient if bug
177660 will be fixed.
Internal prefs and UI prefs need not map 1:1.

Comment 87

15 years ago
I know :) but there is a lot of pref tweakers and toolbars at mozdev.org ;)
Give us a pref in prefs.js, and we make the rest.
You have a pref, it's in userContent.css. :-)

Comment 89

15 years ago
It isn't a pref, alas. Pref is string in prefs.js, afair ;)

Concerning blink - if bug 177660 will be fixed, we could remove C++ code for
browser.blink_allowed pref (is it what David Baron wants in comment 67?) and
make <blink>-binded XBL to read user pref and allow/suppress blinking.
No, a blink pref couldn't be implemented in XBL because we need to turn of
'text-decoration: blink' in addition to HTML's BLINK element.

Comment 91

15 years ago
Of course, but there are two similar, but different things relating blink.
text-decoration:blink is a valid CSS property, but <blink> is non-standard
extension from older Netscape browsers. Enabling CSS blinking and suppressing
<blink> tag might be an allowable choice, especially in strict HTML/XHTML mode.

Comment 92

15 years ago
Why does this have to be so much more complicated than it actually is?

* A pref in the UI to turn off scrolling marquees.
* A pref in the UI to turn off blinking text.

Why entangle all this political correctness, quirks vs. standards, and tedious
workarounds? In the time we've spent debating it in this bug, someone could've
written a patch to add those two options to the UI and this would be done.
Instead we have to do everything "my" way, with the "my" referring to each of
the people who has added comments to this bug. If anyone can just get the change
made, everyone can mark the checkbox the way they want it and be happy!

Comment 93

15 years ago
Skewer, I agree with you, but problem is slightly deeper.  We all have an
intention to solve this bug, we discuss how to do it. David justly consider that
superfluous forks in C++ code complicate developing and debugging.

If you really want to help us, please pay attention to bug 177660. If we'll fix
this and write XBL with fork depending of marquee pref, corresponding UI is
that'll come.
I disagree that allowing prefs to be read from XBL and complicating the XBL is
the right solution.  I think the right solution is coming up with a better
mechanism for generating a stylesheet from preferences.

Comment 95

15 years ago
Maybe, you're right... but my reason is this:

I still consider scrollbar to be the most adequate emulation for <marquee> tag.
But if we'll accept your proposal, we should write two XBLs separately for
autoscrolling and for scrollbar. These XBLs will be very similar, differences
will be present only in three CSS parameters and in autoscrolling module. See
"durty hack" at http://bugzilla.mozilla.org/attachment.cgi?id=97516&action=view

Fork in united XBL might economize our work and reduce overall number and size
of files.

More, in the future this opportunity (reading prefs from binded XBL) might be
useful for another cases. For example, I sometimes think about adding in Mozilla
ability to support WML (markup for cellular phones) through binding XSL
transformation to <wml> tag.

And, finally, giving to XBL binded by html.css permission to read user prefs is
probably simpler and eleganter than implementing interface for preferences
dialog to edit userContent.css. I don't know what is a security bug 177639 (bug
177660 was marked as it dupe), but I hope that work at 177639 will have fixing
177660 as a collateral result.
btw, we had a Accessibility fair on Campus and the tools they showed us did the
following:

 - converting a page of text to one line of scrolling text (in big letters)
 - making the blinking cursor even bigger

:)

Updated

15 years ago
Keywords: mozilla1.4, nsbeta1, nsCatFood
*** Bug 189004 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Blocks: 119597

Comment 98

14 years ago
This bug appears to have been abandoned. Meanwhile Mozilla is still violating
Section 508 and the User Agent Accessibility Guidelines by not providing a
mechanism to the end user to turn off marquee. Can anyone else take this bug?

Comment 99

14 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 100

14 years ago
Renominating for nsbeta1 because:

Mozilla (and Netscape) violates Section 508 and UAAG because of this bug.

Users with epilepsy and vision impairment will be unable to use the browser
because of this bug.

A critical user satisfaction issue is introduced when irritating animation
effects like blinking and scrolling text are enabled and mandatory.

A patch exists for this bug.

If marking nsbeta1- again please explain your reason for disputing these
problems caused by this bug.
Keywords: nsbeta1- → nsbeta1
skewer: there is no patch that i can see.

Comment 102

14 years ago
A pref for this will do no good until plugin manager is enhanced to easily
toggle on and off things like Flash. Preferably "click-to-launch" mode for
objects would be implemented as well.

Ted Mielczarek created a prototype of that at
http://ted.mielczarek.org/code/mozilla/ but it only hides them, the plugin still
loads (a big problem for Java, where startup can drain a disgusting amount of
system resources).

Also I see his page now links to bug 169330.

Plugin click-to-view could DEFINITELY be a "can't go back to IE" feature. It's a
beautiful solution to flash ads (annoying) and java ads (annoying, and major
perf). When did it become acceptable for advertisers to appropriate our plugins?
don't touch netscape keywords
Keywords: nsbeta1 → nsbeta1-

Comment 104

14 years ago
Flash isn't our problem. If a user doesn't want Flash animation to appear he can
uninstall the plugin.

Comment 105

14 years ago
*** Bug 209949 has been marked as a duplicate of this bug. ***

Updated

14 years ago
No longer depends on: 177660

Updated

14 years ago
Depends on: 59701

Updated

13 years ago
Keywords: sec508

Comment 106

13 years ago
*** Bug 270838 has been marked as a duplicate of this bug. ***
Assignee: dbaron → nobody
QA Contact: ian → style-system

Updated

9 years ago
Blocks: 438848
Priority: P2 → P3
Target Milestone: mozilla1.2beta → ---
You need to log in before you can comment on or make changes to this bug.