Closed Bug 765645 Opened 12 years ago Closed 12 years ago

Millions of web pages use the -moz-opacity:0.7 tag and in javascript. It's broken now since FF 13.01. Please can you "alias" it back into your main browser code. Thanks.

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Version:
13 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: YHWH, Unassigned)

References

Details

(Keywords: regression) 

User Agent: Mozilla/5.0 (Windows NT 5.2; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

Upgraded to Firefox 13.01


Actual results:

Hundreds of pages in our 16 plus domains DO NOT fade images on mouseover anymore, because the -moz-opacity:0.7 reading function is GONE.

We use this :

"-moz-opacity:0.7" onMouseover="lightup(this, 70)" onMouseout="lightup(this, 100)"

Fired by this :

<script>

function lightup(imageobject, opacity){
 if (navigator.appName.indexOf("Netscape")!=-1
  &&parseInt(navigator.appVersion)>=5)
    imageobject.style.MozOpacity=opacity/100
 else if (navigator.appName.indexOf("Microsoft")!= -1 
  &&parseInt(navigator.appVersion)>=4)
    imageobject.filters.alpha.opacity=opacity
}

</script>


Expected results:

On mouseover (BEFORE FF 13.01) the images would fade to the specified opacity.

NOW THEY DON'T....

It is a VAST AMOUNT OF WORK, to rewite every page with this failure.

Can you please consider replacing the code change for the opacity filter to INCLUDE the code that USED TO WORK ??? (perhaps using an alias function or suchlike)

Thanks very much.....

Blessings....Elijah 

www.Constellation7.org
The code shown here already fails in Safari, Chrome and Opera.
It will also fail in IE when it stops supporting the proprietary .filters. property.
According to bug 93156 .style.opacity has worked since February 2004, so the product of this bug could be changed to "Tech Evangelism" to not use code from over 8 years ago in webpages.
The alias was removed in bug 730532
CCing the devs from there for a decision here.
(In reply to Mardeg from comment #1)
> It will also fail in IE when it stops supporting the proprietary .filters.
> property.
This already happened, from http://blogs.msdn.com/b/ie/archive/2011/12/07/moving-to-standards-based-web-graphics-in-ie10.aspx
"DirectX-based Filters ... are now gone from IE10"
The point here is it was working fine until the latest FF update, which has also killed the -moz-box-shadow: property.

Surely both these properties can be retained as legacy code side by side with the new code?

The alternative is a massive overhaul of millions of web pages that maintain these properties in their code (and in Javascript)

Essentially, this is "breaking the internet" for graphic decoration smaller web-coder's sites and pages across the entire planet.

Will be posting the same legacy retaining suggestions to Opera, Chrome, Safari and IE.

What is best here - The browser code writers maintaining legacy code - OR millions of website builders being FORCED TO HAND EDIT code to recover the effects that used to work?

(OR losing them altogether??)

The situation here, quite frankly, is ABSURD...All that work down the toilet for WHAT REASON exactly?? Sorry, forgive me, but this simply "does not compute"...

There must be an equitable solution by re-editing the master browser source code ???

Otherwise (as with Safari, IE, Opera, Chrome and others) THIS IS SIMPLY GROSSLY UNFAIR on the millions of small website builders on every continent....

Thanks...
Blocks: 730532
Component: Untriaged → Style System (CSS)
Keywords: regression
OS: Windows Server 2003 → All
Product: Firefox → Core
QA Contact: untriaged → style-system
Hardware: x86 → All
If you implement browser prefix properties you should always include the non prefix version, it's common sense, all browsers at some point drop the prefix, it's happened so many times people should know better, this is nothing new or strange, it's common practice.

Working as intended.

When you write something try to future and browserproof it, add all the browser prefixes even if that browser doesn't support it currently, and without a prefix, there are tools that take non-prefix/single prefix CSS and adds the missing lines, or does it in the background like SASS/LASS.
> Surely both these properties can be retained as legacy code side by side with the new code

No, because then pages like the one you cite, which only work in some browsers but not others, won't ever get fixed...

> The alternative is a massive overhaul 

To be honest, the alternative is authors following best practices and either not using experimental features or updating their pages when the features stop being experimental or assuming that the non-experimental feature will work like the experimental one and just using the unprefixed properties.  That's when authoring originally, of course; once browser-sniffing code like what's cited above is written you're right that the only option is fixing it....

> All that work down the toilet for WHAT REASON exactly??

The reason is that the page cited didn't work correctly in any browsers other than IE (and not in IE version 10) and the Gecko-based browsers.  And if we had left the alias, you would never have realized that, I'm guessing.  Since one of Mozilla's goals is to promote user choice, including the user's ability to choose their browser as desired, we have an explicit policy of dropping prefixed properties after we have implemented the unprefixed one for some time (with a grace period in there to allow authors to update their pages as needed).  The goal being that if an author writes a page and only tests it in a Gecko-based browser and it works, then it should also work in any other standards-compliant browser.
Appreciate your thinking and comments. Nonetheless, millions of web pages have lost the box shadows and opacity effects in one fell swoop.

Certainly my thinking represents a myriad of small time web page builders that never imagined their handwritten - image by image, table by table code, would be suddenly rendered obsolete.

Are you trying to say that it is impossible for Firefox to retain the ability to read such code, whilst simultaneously ALSO implementing the new CSS standards?

Seems to me, and certainly a multitude of other people, that FF should retain such a rendering ability, as should ALL the other browsers.

It's a whole lot easier for the browser code writers to to this, than forcing site owners to scour hundreds of pages and javascript and try and find a manual fix.

Respectfully, this is very selfish of the browser code authorities to do this.

The end result is the same - the effects are GONE and it represents an aggregate loss of hundreds of hours of work (in our case and OTHERS), that needn't have happened.

Why CAN'T FF retain legacy coding to support such pages?
> Why CAN'T FF retain legacy coding to support such pages?

It _can_, but doing so would be harmful to the future development of the web, so we have deliberately chosen to drop the prefixed properties after a grace period.  That's what I tried to explain in comment 7....
Understand this....However, how about the vast amount of work now forced on people that have had such pages running perfectly for years?

What's the big deal here? 

Sure, FUTURE pages can implement new methods - agreed, NO SWEAT.

It's the millions of other pages that have to be entirely rewritten that is the CORE of this issue.

How about tweaking the code for FF 13.02 and allow it to MAINTAIN the ability.

Truly, if you did this, Firefox would be the NUMBER ONE BROWSER for web page builders....

Hey, you guys could even set a precedent that maybe the others might even emulate.

It's NOT a big deal for Mozilla - IT IS FOR MULTITUDES OF PEOPLE LIKE ME.....

HONESTLY, it's just plain senseless destruction of a set of attractive visual effects that should be ALLOWED to be seen....

Think about this please....thanks..
Marking wontfix for reasons stated in comment 7.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You set out to NOT be like Microsoft and open the internet up to fair choice.

Power corrupts absolutely.

The response to this BIG issue, proves SELFISHNESS, POWER-MONGERING and a manifest LACK of care and consideration for the multitudes of smaller people hosting millions of websites, WITHOUT the time nor resources to DO WHAT YOU ASK...

You leave us bitter and resentful at your poor lack of judgment; just like you once were agains MS & IE...Same same....

SHAME ON YOU !!!

† Acts 2 : 38 †

Then Peter said unto them, "Repent, and be baptized every one of you
in the name of Jesus Christ for the remission of sins, 
and ye shall receive the gift of the Holy Ghost."
Just be patient - HAVE A SOLUTION TO THIS PROBLEM.

Will be issuing Mozilla and Microsoft an invoice for ALL THE TIME i will personally have to spend RE-WRITING the opacity and box shadow codes on EVERY SINGLE PAGE in our entire network, just because you guys REFUSE to include a simple legacy-alias line in the master browser code.

Estimate this to be around 100 hours of time, as it has to be done manually in text files for every single instance of the code, whereby the opacity and box shadow values vary from image to image, table to table and div to div.

My hourly rate as CEO of this Corporation is HK$1900 or US$247.00 per hour.

Think that with a discount, US$18,000 should be sufficient to cover all my time related costs, fixing ALL code instances, for ALL the aforestated reasons...

Invoices will be issued shortly.

If the Mozilla invoice is NOT paid - OR THE WEB BROWSER MASTER CODE remains unchanged, then will Apply to Collect the amount in Court.

Have your comments as evidence that you DELIBERATELY REFUSE to be accommodating, as does MS.

Should be sufficient to PROVE this 100% in my favour in Court, if needs be....

Thanks a bunch for being SO HELPFUL !!!

† Mark 16 : 15 - 16 †

"And he said unto them, Go ye into all the world, and preach the gospel to every creature.
He that believeth and is baptized shall be saved; but he that believeth not shall be damned."
YVMH, please respect the etiquette when you use Bugzilla:
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Please honour the request to allow FF to read the code....

You honestly have NO idea the trouble this is causing...

SO MUCH WORK to align millions of pages....

Read here :

http://www.google.com/search?num=100&hl=en&lr=&newwindow=1&as_qdr=all&sa=X&ei=x93hT6edJdGziQfJ59n6Dg&ved=0CAcQBSgA&q=moz-opacity%3A+moz-box-shadow%3A&spell=1&biw=1024&bih=584
> SO MUCH WORK to align millions of pages....

The thing is... we actually have data on how many pages are using '-moz-opacity' but not 'opacity'.  It's a pretty small number of pages.  There was some discussion about this in bug 413141 when we dropped the declarative (non-scripted) alias back in late 2008.

Note that we have supported 'opacity' without prefix since 2004 or so.  So have other UAs.  The vast majority of pages trying to use opacity are using it unprefixed.
And in javascript? 

Point is FF was the best browser. It's not the new pages that are suffering, it's the old ones...

Graphic designer pages and special effect menu pages, with a myriad of small time webmasters, RIGHT NOW, are doscivering all their past work is currently rendered useless.

For my part the work to update is massive and daunting....

PLUS, i feel personally VERY ANGRY to be forced to do all this extra work to get the pages back looking like they used to in FF.

Over 40% of hits are FF.

It's radically unfair of the big developers NOT to support the coding AND the new CSS standard.

Ideally, ALL browsers SHOULD support ALL extensions, 

The principle of changing the way the browser reads html and javascript is grossly unfair to the small guys.

Ater all, what IS the big deal in being ALL ENCOMPASSING???

Anyhow, why was this SUDDENLY DONE in June 2012 with FF 13 ??

FF 12 did not have any issues in this context.
(In reply to YHWH from comment #13)
> Have your comments as evidence that you DELIBERATELY REFUSE to be
> accommodating, as does MS.
> 
> Should be sufficient to PROVE this 100% in my favour in Court, if needs
> be....

I'm not affiliated with Mozilla, but I understand where this decision comes from. -moz-opacity is a function that has been noted to be removed at any time. Leaving it after it's finalized would be a poor decision on Mozilla's part, considering that widespread usage would have a poor impact on the web's future development. It's not part of the W3C specifications, and now deprecated.

I don't believe the parameters haven't been changed for the new function. You can use the Find & Replace function in your editor to make this change painless.

And lastly, Bugzilla isn't the place for this discussion.
Understand all this. They should STILL have left it AS IS.

How would we know the function is going to be removed?

We just create visually appealing, informative and Evangelical websites since AD 1997.

We are NOT alone in this GRIPE.

In our view this IS A BUG to be fixed. 

The simple word ALIAS, dispenses with ALL the needless editing that EVERYONE EVENTUALLY has to do to FIX the -moz- tags in their code and javascript.

This is ILLOGICAL : Same Same for -webkit- / -khmtl- / filter: alpha: and -ms-filter:

ALL BROWSERS COULD "alias" these and THEN the visual effects of older pages remain undisturbed, and ALSO then ALL Browsers read the same - AMEN.

It must ALWAYS be about "backwards compatibility" to be all embracing.

This philosophy is eminently way more expedient for BOTH the Web, and the older and less professional page builders.

INSTEAD, they change the master code and FORCE millions of edits and a whole WASTE OF TIME for smaller web builders who want to concentrate on visual content and stability.

It's like Vista vs XP...

We are just pawns in this stupid game...

Will take the Invoice Issuance Solution under Advisement.

Thanks for commenting....

Elijah

† Proverbs 9 : 10 †

"The fear of the LORD is the beginning of wisdom: 
and the knowledge of the holy is understanding."
for the record, "search and replace", many editors offer it, some even offer it across files and folders. That will save you the "thousands of hours" on your pages.

If you need a pointer at a free cross-OS editor that does offer it, KomodoEdit at www.activestate.com
find . -name "*.js" -o -name "*.html" -print | xargs sed --in-place -e "s/MozOpacity/opacity/"

Or something like that.  I'd take a little more care with a live webserver...  But this is totally automatible. 

5 or 10 or 30 seconds later, you're done.  :-)
I can't believe I'm replying to this... but

"How would we know the function is going to be removed?"

Well, https://developer.mozilla.org/en/CSS/CSS_Reference/Mozilla_Extensions is the canonical reference of Mozilla-extensions to CSS.  Third paragraph on the page:

"Once standardized, and the support for the un-prefixed variant added, the prefixed properties are dropped."
You should be aware that the time you spent complaining here (as well as research time in your bible), you could have written something that fixes this automatically across all your code. http://sed.sourceforge.net/sed1line.txt

And before you start complaining how that could potentially break something, you probably should check out diff functionality of a VCS like Git. Not to forget about test coverage of software re-engineering to confirm your changes.

So, please... Stop living in the past! :)
It makes NO DIFFERENCE what anybody says.

The REAL TRUTH is simple. It is the browser code that needs to be modified, NOT the web pages, when they USED TO BE READ JUST FINE, without manual OR auto-batch editing, JUST BECAUSE the browser reading functions have changed (for WHATEVER REASONS).

A simple "alias" function (in multiple simple cases) takes the burden AWAY from web builders, and allows ALL browsers to READ ALL CODE, both old and NEW.

This applies TO ALL WEB BROWSERS. 

What is ACTUALLY happening however, is that the web browser folk responsible for the master coding are FORCING web builders to EDIT pages, FOR NO REASON; when, IN REALITY, this can be done seamlessly inside the browser reading Master Code.

THIS IS THE REAL CRUX OF THE ISSUE....and hence this COMPLAINT....

GOOD BYE...

† 2 Timothy 4 : 5 †
"But watch thou in all things, endure afflictions, 
do the work of an evangelist, make full proof of thy ministry."

http://www.Constellation7.org
(In reply to YHWH from comment #24)
> It makes NO DIFFERENCE what anybody says.
> 
> The REAL TRUTH is simple. It is the browser code that needs to be modified,
> NOT the web pages, when they USED TO BE READ JUST FINE, without manual OR
> auto-batch editing, JUST BECAUSE the browser reading functions have changed
> (for WHATEVER REASONS).
> 
> A simple "alias" function (in multiple simple cases) takes the burden AWAY
> from web builders, and allows ALL browsers to READ ALL CODE, both old and
> NEW.
> 
> This applies TO ALL WEB BROWSERS. 
> 
> What is ACTUALLY happening however, is that the web browser folk responsible
> for the master coding are FORCING web builders to EDIT pages, FOR NO REASON;
> when, IN REALITY, this can be done seamlessly inside the browser reading
> Master Code.
> 
> THIS IS THE REAL CRUX OF THE ISSUE....and hence this COMPLAINT....
> 
> GOOD BYE...
> 
> † 2 Timothy 4 : 5 †
> "But watch thou in all things, endure afflictions, 
> do the work of an evangelist, make full proof of thy ministry."
> 
> http://www.Constellation7.org

Listen, you have been told the reason for the change multiple times. The Mozilla Wiki documentation has the warning in place. The -moz prefix is only used for Mozilla's specific implementation. Leaving it in forces your viewers to use Mozilla browsers, which ultimately harms the uniformity of the web. Asking all web vendors to implement the implementations of other browsers (-ms, -o, -webkit) is bad practice, and wasted resources when the official W3C implementation is done.

It's not being about being too lazy to add a -moz alias, it's about protecting the web's portability and uniformity. Several posters have even offered an easy Find/Replace solution to your problem.

These are my words, and I am not affiliated with Mozilla.
Thanks for your comment - Fixed the problems some 12-14 days ago after 3-5 days of work searching the entire Network (16 web domains) and then MANUALLY locating the correct search, find and replace items for each individual page. (still have some to do)...

NOT AS EASY as you would think.

PS : For the bigger sites, because of several difference between Mozilla and IE, we have two versions, user browser-sniffing redirection, so it's NOT about "forcing people to use Mozilla".

There are some cool functions in IE that FF / Chrome / Netscape / Safari / Opera et al haven't emulated yet, and vice versa...

Don't buy into the "web portability / uniformity" doctrine - it's pie in the sky, UNLESS all web-browsers implement the best of each other, with historical backwards compatibility.

Again, it comes back to the same gripe (and i AINT ALONE HERE) keep ALL the old reading functions; CARRY ON WITH WIKI-NOTICES or whatever...AND BUILD ALL EMBRACING, PERFECT WEB-BROWSERS, to leave the internet AS IS for older sites and pages.

Understand this is NOT "policy" - BUT, by NOT being "policy" it is FORCING smaller, long standing and older web page builders to return to OLD PAGES and do a host of UNNECESSARY EDITING.

This is RUDE and INTRUSIVE & AVOIDABLE...
It certainly is avoidable, by not using any vendor prefixed properties in your pages. The moment you do, you are accepting that these properties are non-standard and experimental, and may change or disappear at some point in the future. That is why they were given a -moz- prefix in the first place.

Don't like that? Don't use those properties. This is a basic rule of web development, and if you don't understand it, then you're going to keep running into problems like this, and now amount of ranting WITH randomly CAPITALIZED words will change it.
Until VERY recently, (NOT being a "professional website builder") i was TOTALLY UNAWARE that the -moz- prefix was NOT standard, OBVIOUSLY....

Multitudes of people are likewise. We just publish visually exciting, subject specific Web-Content.

We don't have the TIME nor the RESOURCES to LEARN all about the changing dynamics & mechanics of web-browser master code; we just TRUST the web-browser code writers...

We drive the cars, we don't build them.

Anyhow, like you RIGHTLY SAY, nothing is going to change...BUT it is my RIGHT to record the Observations herein....

DONE...
If you make a website, then you are choosing to build the car, not drive it. The right way to do so is widely documented, for amateur and professional developers alike to study. If you lack the time or resources to do so, then either refrain from making websites, get someone else to do so for you, or accept that you will make mistakes, such as a relying on non-standard properties that later disappear.

Understand also that the web is fundamentally a dynamic, living thing. As such, it is changeable over time in a way that a more traditional medium, like print, is not. This dynamism is its greatest advantage, but it also has the consequence that nothing is completely fixed and permanent. Browser makers will take reasonable steps to protect you from these changes, but they also have to ensure that the web  does not degrade into a morass of unstandardised features and backwards-compatibility hacks.
Your post intrigued me and I am an avid purveyor of such sites, so I decided to dig.

I believe I found all your 16 domains, and across them (and a few were just redirects to several existing domains) you have approximately 788 pages.  You've got a fair amount of link rot and inconsistency in your links as a result of mixed case.

Of your pages: the word "lightup" is on:

www.beyond-eden.org\TheTragedyOfRebelliousPride.htm
www.beyond-eden.org\TheYearEra-Of-JESUS-Return-Amen.htm
www.constellation7.org\Constellation-Seven\Church-7.htm
www.constellation7.org\Constellation-Seven\Church.htm
www.constellation7.org\Constellation-Seven\Creation7.htm
www.constellation7.org\Constellation-Seven\Creation777.htm
www.constellation7.org\Constellation-Seven\Evidence-7.htm
www.constellation7.org\Constellation-Seven\Evidence.htm
www.constellation7.org\Constellation-Seven\Flood.htm
www.constellation7.org\Constellation-Seven\Hell.htm
www.constellation7.org\Constellation-Seven\Home.htm
www.constellation7.org\Constellation-Seven\Josiah\Church-7.htm
www.constellation7.org\Constellation-Seven\Josiah\Church.htm
www.constellation7.org\Constellation-Seven\Josiah\Evidence-7.htm
www.constellation7.org\Constellation-Seven\Josiah\Evidence.htm
www.constellation7.org\Constellation-Seven\Josiah\Flood.htm
www.constellation7.org\Constellation-Seven\Josiah\Hell.htm
www.constellation7.org\Constellation-Seven\Josiah\Home.htm
www.constellation7.org\Constellation-Seven\Josiah\Prophecy-7.htm
www.constellation7.org\Constellation-Seven\Josiah\Prophecy.htm
www.constellation7.org\Constellation-Seven\Josiah\Salvation7.htm
www.constellation7.org\Constellation-Seven\Josiah\Salvation777.htm
www.constellation7.org\Constellation-Seven\Josiah\Sin.htm
www.constellation7.org\Constellation-Seven\Josiah\Solutions-7.htm
www.constellation7.org\Constellation-Seven\Josiah\Solutions.htm
www.constellation7.org\Constellation-Seven\Josiah\Testimony-7.htm
www.constellation7.org\Constellation-Seven\Josiah\Testimony.htm
www.constellation7.org\Constellation-Seven\Josiah\home-2.htm
www.constellation7.org\Constellation-Seven\Prophecy-7.htm
www.constellation7.org\Constellation-Seven\Prophecy.htm
www.constellation7.org\Constellation-Seven\Salvation7.htm
www.constellation7.org\Constellation-Seven\Salvation777.htm
www.constellation7.org\Constellation-Seven\Sin.htm
www.constellation7.org\Constellation-Seven\Solutions-7.htm
www.constellation7.org\Constellation-Seven\Solutions.htm
www.constellation7.org\Constellation-Seven\Testimony-7.htm
www.constellation7.org\Constellation-Seven\Testimony.htm
www.constellation7.org\Constellation-Seven\home-2.htm
www.constellation7.org\Elijah-Saatori\ELIJAH-2.HTM
www.constellation7.org\Elijah-Saatori\ELIJAH-3.htm
www.constellation7.org\Elijah-Saatori\ELIJAH.htm
www.constellation7.org\Elijah-Saatori\index-2.html
www.constellation7.org\Elijah-Saatori\index.html
www.constellation7.org\TheMazzarothMission\index.html
www.galaxion.com\index.html
www.mazzarothvisions.org\index.html
www.thelivingwordofgod.net\index.html
www.theophiramfoundation.org\index.html
www.theseventhunders.org\Genesis\index.html
www.theseventhunders.org\index.html
www.theseventhunders.org\index8bb8.html
www.zion-corp.net\index.html

These are the 52 pages where the word "lightup" appears, if I've done my task correctly.  Not nearly as bad as "hundreds" as you stated before.

For future reference: look into externalizing your scripts/css into a separate file and referencing that instead of copying and pasting to every page.

The folks here have been *very* nice in helping you.  The best thing now is to get some sleep and re-read this thread.  There really has been a lot of helpful advice, and even I learned something new.  If you are a windows user, Notepad++ can be a huge help with hand editing your documents. Plenty of good advice here.

Goodnight!
~Mick
Dear Jon....very nicely written comment.

Like the style a lot.

It's just that i DON'T AGREE with the underlying concept and principle.

EACH to their own...

===================================

Hi Mick...there are a whole lot more pages than you have managed to eke out by your search, and it's NOT just the light-up function that went down the toilet, it was also -moz-box-shadow that vanished overnight in FF 13.

Also, some of the pages you have found don't exist and MOST ALL are .htm

The issue is pretty much a closed book now, as FF code writers wouldn't tweak the master code and MADE ME do all that work...still haven't checked how much more tweaking is necessary to restore ALL back as it was in FF 12...

Yup, i WAS annoyed by it all....(still am)....

AND yes, most folks here have been polite....and that's good....Amen

NEVERTHELESS, i still had to do ALL THAT EDITING, and it DID TAKE quite some time, because i wrote most of the special effects code by hand using notepad...so the tag positions varied a lot.

Yes, external CSS style sheets ARE BETTER..just haven't had the time to even CONSIDER doing this yet...

Will look out for Notepad++ though - THANKS for the tip....

STILL, all said and done, the REAL POINT REMAINS, that when you add up ALL THE TIME everyone on the planet COMBINED has to put in to update OLD pages, it's NOT really fair...WHEN the master browser code COULD handle the whole deal...

Enough said - God Bless you ALL In JESUS - Amen

Elijah

† Romans 1 : 20 - 21 †

"For the invisible things of him from 
the creation of the world are clearly seen, 
being understood by the things that are made, 
even his eternal power and Godhead; 
so that they are without excuse: Because that, 
when they knew God, they glorified him not as God, 
neither were thankful; but became vain in their imaginations, 
and their foolish heart was darkened."

http://www.constellation7.org/TheSimplePrayerOfFaith.htm
> when they USED TO BE READ JUST FINE

You know... back in the days... people wrote their stuff on stone, and then they used to pass that stone around. But really, I don't see why we should still be supporting stone these days to get the whole planet to see that stone. I mean, trying to get that piece of stone to everyone is extremely though, if not impossible; thus writing on stone to get everyone to see it really was a bad idea.

The -moz-box-shadow feature was provided back in 3.5 - 4.0 and was specific to Firefox back then for a long while, furthermore, it's not standardized in anyway. If you don't write according to standards as a web developer, which means actually chceking up with W3C (NOT w3schools) and WhatWG, then you shouldn't be surprised that your code is beaking. Because really, the worst idea on earth would be if all browsers had to maintain support for such UNSUPPORTED feature, while there are standardized features in place as well. Hence, it's time to stop holding -moz-box-shadow's hand and leave it were it was; back in the past.

Onec again, if you have kept up to the standards, you wouldn't have the need to complain.

It's not Mozilla that is wasting your time, but rather you yourself. They are actually sparing out time by no longer supporting this feature, but just supporting CSS 2.1, CSS 3 et al instead. Which means you don't have to defer from reading the standards, which is the main cause people get code that doesn't work. Their code is non-standard because they don't follow the standard, which causes those people to stay behind... 

If you were to use box-shadow in the first place, you wouldn't had to write this thread. And even when you went down the wrong path, I'd rather prefer to use something like s/\b-moz-box-shadow\b/box-shadow/gi

“You can spend minutes, hours, days, weeks, or even months over-analyzing a situation; trying to put the pieces together, justifying what could've, would've happened... or you can just leave the pieces on the floor and move on.”
― T. Shakur

[redacted quote to meet etiquette]
Hi all, this is not the place for this discussion. Please stop piling on the OP, the point has been made. Unfortunately it looks like MDN no longer has forums so I'm not sure where to suggest to move the discussion. If anyone really wants to keep talking about it please provide a link and move it there.
Thanks Lucy - ALL concluded now. 

BUT, there is one LAST question / observation for the tech gurus with Firefox looking in on this discussion - REGARDING FF GRAPHICS.

When the home page menu at the left of http://www.Constellation7.org opens in IE 8 on Windows Server 2003 and you MOUSEOVER a Menu Label, animated graphics change and RUN SMOOTHLY - no problems.

BUT, try this in Firefox 13+ and the animations STOP WORKING on the Mouseover...at least in Win 2003 Server they do...

DOES THIS HAPPEN FOR YOU ALSO ?  If so, why is this ? - And again, (IF SO) is this a FF BUG ??

Thanks and Blessings...

Elijah

† 1 Timothy 1 : 17 †

"Now unto the King eternal, immortal, invisible, 
the only wise God, be honour and glory for ever and ever. Amen."
YHWH,

I checked out your page and I mean this with all respect, but it's no wonder that your animation isn't working. The code you are using is very old and it's going to break sooner or later as browsers get updated. I know you claim you aren't a professional web developer, but you cannot continue to rely on the browser manufacturers to maintain their code to fit your pages; rather, you need to update your code to fit what the browser manufacturers create. Most of this code that they create is agreed upon by higher level committees and is then implemented, so they're not just doing it willy-nilly. 

Here is a specific case: -moz-box-shadow. One of the recommendations since I've been using this css rule was to do the following:

-moz-box-shadow: stuff
-webkit-box-shadow: stuff
box-shadow: stuff

Even when box-shadow wasn't fully supported, it was there for the coming day when it would be used. Now, I'll keep the old rules to support my users with older browsers for a time, and then I'll get rid of it as I see my users upgrade (based on web stat reports).

So, to wrap it up, I think you need to examine how you are programming your site and read up on what the current and coming techniques are. Asking if this is a bug and if that needs to be changed to fit with the way things were done isn't going to work for you moving forward. It's just the way of the world, especially the tech world.
Normal Opacity has been available since at least FF 2.0 if nor earlier. You have been using an old css value for many many years.
Just for the record, the ANIMATED GIF BUG was fixed today in the new release of FF 14+.

Notes here : https://bugzilla.mozilla.org/show_bug.cgi?id=743598

Many thanks...

Blessings...

Elijah

† Psalm 68:11 †

"The Lord gave the word: great was the company of those that published it."
Call me silly, but wouldn't some regex magic that runs on all site files do the trick? You don't have root access? You can do it via PHP script.
Just do a search on all your files and then click "Replace All", and then stop using vendor prefixes that are long due - problem solved.
You need to log in before you can comment on or make changes to this bug.