CSS Bugs and Inconsistencies in Firefox 3.x

There aren’t many articles covering incompatibilities, or CSS differences in Firefox alone — and for good reason.

Firefox has always done an excellent good job of supporting both CSS and JavaScript in a standards-compliant manner without too many awkward bugs.

There are, however, a few CSS properties and selectors that aren’t supported by one or more of the versions released since version 3.0., which I will cover here.

This article will cover bugs, inconsistencies, and nonsupport. So, if you’re having trouble with a CSS property or selector in Firefox and it’s not listed here, then you’ll probably have to rethink your layout and reconsider what the culprit might be.

Since Firefox 2 is virtually non-existent, I won’t be considering that version specifically, but this information will generally apply to that version by default.

And I should note that the material for this post was taken primarily from the newly-updated SitePoint CSS reference, which is hands-down the best and most comprehensive CSS reference available anywhere.

 

The Outline Overflow Bug

In Firefox 3.x, when an element overflows the border of a parent that has the outline property set, the outline will stretch to fit the containing element, as shown in the screen capture below:

The correct implementation is shown in the next screen capture taken from Chrome:

As shown above, the outline should encompass the element that is being outlined, and should not be affected by any overflowing elements. To ensure there’s no confusion, note that this is a bug in the implementation of the outline property, not the border property.

Reference: SitePoint CSS Reference: outline Property

 

Tables with Collapsed Borders

In Firefox, when a table has its borders set to collapse using the border-collapse property, the table’s top and left margins in relation to nearby elements is 1 pixel off. This is shown in a zoomed-in screenshot in the image below, which displays the bottom border of a block-level element (red) touching the top border of a collapsed table (blue):

Here is the correct implementation of this property/value pair, as shown in Chrome:

As shown above, because the borders are “collapsed”, and because the table is not a block element, there should be a slight offset in the left margin, and the top margin should be even with the bottom border of the element above it.

Reference: SitePoint CSS Reference: border-collapse Property

 

Empty Cells in Table Rows

This is a property value that is not implemented properly by any browser, including Firefox. When a table row has no visible content and all its cells have their empty-cells property set to hide, the entire row should behave as if it were set to “display: none”, with no borders or backgrounds visible.

No browser handles this correctly, so the table row is still visible, as shown in the image below.

Reference: SitePoint CSS Reference: empty-cells Property

 

Word Spacing on Inline Elements

In Firefox 3.x, a negative value on the word-spacing property will be treated as zero on adjacent inline elements. The negative value should cause the inline elements to overlap one another, as would be the case with text, but this doesn’t happen. Instead, the elements are just given zero white space separation with no overlap.

The image below displays both the correct and incorrect implementations:

In the examples shown above, the three words “Fruits”, “Vegetables” and “Other Foods” are individually wrapped in <span> elements, while the paragraph that wraps them has its word-spacing property set to a negative value.

The second example (Firefox) fails to apply the negative word spacing, except between the last two words because those words are not individually wrapped by spans but are natural text elements.

As a side point, this bug occurs similarly in IE8, but not in previous versions of IE.

Reference: SitePoint CSS Reference: word-spacing Property

 

Text Decoration on Floating Descendants

When an element has a text-decoration value set, that value should not be inherited by floating descendants. In Firefox 3.x, floating descendants are given the same text-decoration values as their parent, even though this should not be the case.

In the image above, the first line is a screenshot from IE8, displaying a <span> element floated inside of an anchor. The text inside the <span> does not have a visible text decoration, which is the correct way to display it. In Firefox (shown in the second example), the text-decoration is incorrectly applied to the floating <span>.

You may have noticed this bug in Firefox when trying to remove the text-decoration from floated images inside of anchors.

Reference: SitePoint CSS Reference: text-decoration Property

 

pre-line & pre-wrap for the white-space property in FF 3.0

Using the white-space property in Firefox 3.5, you can specify whether multiple space characters should be collapsed down to a single space or not. By default, HTML documents will collapse multiple spaces down to a single space. In some instances, you can apply white-space: pre to prevent white space from being collapsed, which is similar to the use of the <pre> HTML tag. Subsequently, you may want to remove that setting using white-space: pre-line (to collapse white space).

Firefox 3.0 does not support this value, so the white space will be retained. Firefox 3.5 collapses the space correctly. The image below shows both examples:

Similarly, when a paragraph of text is set to white-space: pre-wrap, this should preserve white spaces between words, but should naturally include line breaks. Firefox 3.0 fails to implement this correctly, while later versions (and all other browsers) include the natural line breaks. Both examples are shown below.

Keep in mind that the outer element is given white-space: pre while an inner <span> is attempting to override the lack of line breaks using pre-wrap. On its own, pre-wrap would not have any effect.

Firefox 3.x also treats the some of the white-space values differently from other browsers when those values are applied to the <textarea> element. For example, applying white-space: nowrap should cause all typed text in a <textarea> to form one line, but Firefox 3.x does not do this.

Reference: SitePoint CSS Reference: white-space Property

 

Page Break Properties

CSS allows developers to specify where page breaks should or shouldn’t occur using the three properties page-break-before, page-break-inside, and page-break-after. Opera is the only browser that fully supports these properties, while other browsers offer partial support or no support.

The page-break-inside property specifies whether or not a page break can occur inside a single block-level element. Firefox does not provide support for this property. Using the syntax page-break-inside: avoid, you can prevent an element from being divided during printing. The image below, from a print preview in Opera 10, shows how this property can prevent an unordered list from being split over two pages:

By contrast, look at the image below, taken from the print preview option in Firefox 3.5:

Reference: SitePoint CSS Reference: Paged Media Properties

 

Orphans and Widows on Printable Pages

The orphans and widows CSS properties are supported only by Internet Explorer 8 and Opera since version 9. This property is used to specify the minimum number of lines from a single paragraph that can occur on a printed page, either at the bottom (orphans) or the top (widows). Depending on the number chosen, lines will be moved from one page to the next (or previous) in order to prevent a single line from being printed at the top or bottom of a page.

Even with the orphans property set to a value of “3”, as shown in the image below, Firefox’s print preview shows a single line at the bottom of one of the printable pages:

Similar to the page-break-inside property, Firefox also fails to support the values avoid, left, and right for both the page-break-before and page-break-after properties.

References: SitePoint CSS Reference: orphans Property | SitePoint CSS Reference: widows Property

 

The :first-line Pseudo-Element Bug

The :first-line pseudo-element allows the first line of any given text block to have different formatting from the rest of the text. For example, the first line of a paragraph of text can be changed to uppercase or to a different color. For this CSS element to work in a practical manner, it should allow for the possibility of nested block-level elements. For example, a <div> element that contains a <p> element should allow the :first-line pseudo-element to change the styling of the first line of text inside the <div>. In Firefox (and in many other browsers), this is not possible unless the pseudo-element specifically targets the child paragraph.

Internet Explorer 8, Chrome, and Safari implement this feature correctly, preventing nesting of block elements from breaking the styling, as shown in the image below:

In the paragraph above, the text is inside of a <p> element, which resides inside of a <div>. The <p> has the :first-line pseudo-element set to color: blue, which fails in Firefox because of the nesting of the paragraph inside the <div>.

Reference: SitePoint CSS Reference: first-line Pseudo-Element

 

CSS3 Support in Firefox 3.x

Firefox has gradually added better support for CSS3 since the release of version 3.0. Below is a description of how Firefox handles different features of CSS3. Some of these may still be in the working draft or candidate recommendation stage, therefore we can’t be dogmatic about what should and shouldn’t be supported until they have reached the recommendation stage.

  • Firefox 3.0 doesn’t support the text-shadow property
  • Firefox 3.x doesn’t support the box-shadow property, except when using the proprietary prefix -moz-
  • Firefox 3.x doesn’t support the box-sizing property, except when using the proprietary prefix -moz-
  • Firefox 3.x doesn’t support multiple columns unless the proprietary prefix -moz- is used
  • Firefox 3.0 and 3.5 do not support CSS3 gradients and multiple backgrounds (both of these were recently added in 3.6)
  • Firefox 3.0 doesn’t support the border-image property, but 3.5 supports it using the -moz- proprietary prefix
  • Firefox 3.0 doesn’t support a number of CSS3 pseudo-classes (:nth-child, :nth-last-child, :nth-of-type, etc.)
  • Firefox 3.0 doesn’t support CSS transforms
  • Firefox 3.x doesn’t support CSS transitions
  • Firefox 3.x doesn’t support CSS animations

 

Other CSS Features Not Supported

Some of the more significant bugs and incompatibilities were discussed above, but there are a few others worth noting.

  • Firefox up to version 3.5 doesn’t support the value run-in for the display property
  • Firefox doesn’t support the ::selection pseudo-element
  • The @page at-rule is not supported by Firefox
  • The @font-face at-rule is not supported by Firefox 3.0

 

Conclusion

After going through this material, you can clearly see that lack of support of CSS features in Firefox is minimal, and in many cases quite irrelevant since many of the properties discussed here are not very commonly used.

Nonetheless, I hope this will provide a decent reference for the most significant bugs and inconsistencies in Firefox. If you are having problems with a particular feature of CSS in Firefox that isn’t listed here, chances are you’re doing something wrong or may not fully understand certain CSS concepts and principles.

So, in that respect, this reference should work well as a reverse-reference, since those not listed here can be trusted to work fine if they are implemented correctly with proper syntax.

Of course, if there’s anything I’ve missed, or any errors, please comment and I’ll do my best to make any necessary corrections and additions.

 

Further References


Firefox Image provided by Rakaz

This post was written exclusively for Webdesigner Depot by Louis Lazaris, a freelance writer and web developer. Louis runs Impressive Webs where he posts articles and tutorials on web design. You can follow Louis on Twitter or get in touch with him through his website.


0 shares
  • http://resourcehive.com JC

    Great article…like you said there aren’t many articles on Firefox CSS problems b/c there aren’t that many. But when they do come up it’s nice to know why.

  • http://qikon.me Qikon

    Great post! Now I know why I love chrome :P

    Just wanted to add something: apparently, Firefox doesn’t support the background-position -x and -y css properties. It only allows the use of background-position.

    • http://www.impressivewebs.com Louis

      “background-position-x” and “background-position-y” are not standard properties. If my quick research is correct, they’re Microsoft-only proprietary properties, and I would be surprised if IE8 supported them. SitePoint’s reference doesn’t even mention them, not even in the proprietary section, so it seems they’re very old and obsolete.

  • http://elizawhat.com Elizabeth Kaylene

    I recently designed a print stylesheet for a client and used the page-break-after property. When I went to print preview in Firefox, it ignored it, leaving me with a big question mark hanging over my head. I haven’t actually tried printing it yet, so I wonder if my printer will recognize it or if printing it in any other browser than Opera will still ignore it. Sounds like an experiment!

  • http://www.evelt.com/ joel k.

    thanks Louis

    as you said, the problems are minimal but not irrelevant, Firefox allays came around at the end and even exceeded “web-kit”.

    support for CSS animations is one of the biggest challenges for the gecko rendering engine, but Mozilla is working overtime for that.

    over all is Firefox the most versatile browser out there, not only for developers.

    thanks for the post

  • http://savedelete.com Jaspal

    gr8 article .. didn’t knew that Firefox also had some bugs and fixes

  • http://www.khwebdesign.net Kent

    Thanks for the detailed article! I wish we could just blame everything on IE but as this article points out, nobody’s perfect.

  • http://www.bahiastudio.net/ Diego A. Peralta

    Another problem is the height in the text inputs, I don’t know why but Firefox 3.6 use the height of the input like a line-height for the text.

    • http://twe4ked.com twe4ked

      This is the most annoying bug imo.

  • http://www.vagrantradio.com Jason

    Great article, I have noticed the page break properties bug before. Sure was fun that day!

  • http://www.christopherleedesign.com Chris

    I have been fairly disappointed with recent versions of Firefox 3.5x, this article gives more more reason to start moving towards Chrome for my browser of choice.

  • http://www.iphoneclub.nl Jean-Paul Horn

    Excellent article! I was looking for this info last week when analyzing FireFox version usage and trying to figure out the CSS differences across the 3.x version range (although usage of FireFox 3.0 is declining rapidly towards the <2% range)

  • http://www.squiders.com Web Design Maidstone

    I have noticed a few of these, one day it will be one set of code for all platforms… keep dreaming!

  • http://www.zirro.se Magne Andersson

    Great list, well-worth a second look. But, Gecko/Firefox has supported the ::selection pseudo-element for very long, but technically more correctly, by the name “::-moz-selection”. This is more correct due to the fact that it was never in a spec that was even close to stable. It should also be noted that ::selection has not been in the CSS3-spec since 2005.
    Otherwise, perhaps you should be a bit clearer on what is supported after 3.0, where it might seem in some places, that newer Firefox versions doesn’t support some features that 3.0 didn’t (3.5 added lots).

    Good work, still.

  • jason

    Have you noticed that there are some rendering inconsistancies between FF 3.6 for Windows and FF 3.6 for Mac. I ran into one the other day where all was well on the Mac side and when I went to test in windows the header had a 50px margin added to it.

    • http://www.evelt.com/ joel k.

      hi
      can you provide a demo of the problem
      please.

      it will be greatly appreciated by all.

  • http://prairiefiredesign.com jaso

    If I recall correctly, there seems to be an issue with attaching the background to the bottom of the body, maybe even positioning the background in the center/middle. I think you can get around it by adding a height of 100% with CSS to the body, but it annoys me because every other browser seems to support it.

    • http://www.impressivewebs.com Louis

      jaso,

      I don’t think Firefox has a problem with that. That’s why I mentioned in that article that if users are having a problem with a specific property, then chances are they’re doing something wrong, and it’s not the browser’s fault, although it may seem that way.

      Most likely, your problem with the background is something to do with the fact that you’re floating elements inside the container, and the container is collapsing, which is normal. Sometimes IE will expand the container when Firefox will not, so when you add height to the container, that obviously will fix the issue. But that’s not a bug, but is in fact the correct way for the browser to handle floated child elements.

  • http://www.pushpinderbagga.com/blog/ pushpinder

    This foolish change will not only effect the internet but also the life of the web programmers. Till when will we be subjected and forced to make separate styles for all browsers.

    The W3 needs to set a particular convention for the browsers to follow minimum set of criterion ensuring equal compatibility of any website all over the browsers.

    The Internet is now owned by Firefox of IE or Opera – its ruled by its users!

  • http://www.simonday.com Simon Day

    Very nice post. One to keep bookmarked if I come across any FF bugs :)

  • http://jeremie.patonnier.net/ Jeremie

    Nice list, very useful.

    Do you have any list of the Mozilla Bugs open in Bugzilla about those bugs ?

  • http://magentoua.wordpress.com/ Magentoua

    FF3 border-collapse bug makes me nuts! I have spent 2 hours two weeks ago trying to fix my table styling. Thanks for the post guys!

  • http://lava360.com lava360blog

    be careful, Firefox add is running on ur sidebar :)
    any ways i am sure that Firefox is working to fix them out. but these css bugs are telling me that web developers and designers are little bit in trouble so far :)

  • Wil

    Glad to see this article, as most tend to concentrate on IE. All browser companies are guilty, as there is not one single browser that is 100% compliant with the standards that have been available for many years. They are all guilty of interpreting the standards in their own proprietary way and this will not change until we have software engineers who can actually follow the standards that are in place and not make it their own little pet project to do as they please.

    Engineers, no matter what industry, seem to live in their own isolated world, oblivious to the real world.

  • http://www.jordanwalker.net Jordan Walker

    I do not like bugs in browser display, takes way too long to figure out the problem.

  • http://www.benstokesmarketing.co.uk ben

    Nice article thank you for the CSS concepts and principles. This will certainly help out with de-bugging in the future.

  • http://www.dharne.com/website_design.php Jane Cooke

    That is a nice list of bugs to be careful about when using CSS. This is the challenge for website designers. Browser compatibility is a major factor in good website design.

  • phil

    Funny – I encountered the text-decoration bug a few minutes ago and couldn’t figure out what I was doing wrong. And now I’m reading (by accident!) that it’s a bug. What a relief ;-)

    Great article.

  • Cat Esposito

    Really cool post. Keep up the great work!

  • Stevie Lee

    After all these years, why are we still fighting with browser compatibility? Hopefully, one day each browser will handle an extended set of css properties consistently.

    Thanks for your work Louis

  • http://jwilkinson.ca James Wilkinson

    So Sad to see firefox becoming Internet Explorer. We recently upgraded to 3.6 and our website went straight to hell. We had to go through all of our CSS and make sure everything was exactly how they wanted. A ROYAL pain.

    • http://www.impressivewebs.com Louis

      I wouldn’t go that far. Most of the stuff discussed in this article is used sparingly in CSS, if at all. Any problems you had were likely due to bad coding habits passed down from older versions that were more forgiving. Firefox 3.6 is more standards-compliant, and therefore will be less forgiving in many respects, giving the appearance of causing sites to go “straight to hell”, as you put it.

      • DesEinstein

        I agree with Louis.

        Your code really needs to be in order.

        I have no problems with any of my sites in firefox and I adhere to strict XHTML policy. I also constantly check my CSS for validation.

  • http://creativenuts.com Creative Nuts

    we even have been face these bugs.

  • http://www.alejandroperazzo.com Punta del Este Real Estate

    chrome post? does any one uses chrome? i usualy use it becouse it opens very fast its very light

  • http://various Paul

    Mozilla has let down its loyal, very long time, fans with ghastly FF 3.64.

    My buttons have disappeared but only sometimes on some screens. Its a nightmare. The lack of consistent CSS behaviour on different web pages using precisely the same code is terrible and very, very, annoying.

    I don’t want to abandon Linux and return to coding on Win98SE with FF 2.0.9.

    Paul
    England
    EU.

  • http://itpastorn.blogspot.com/ Lars Gunther

    Do you have links to test cases? I’d like to see what progress has been made in Firefox 4. Also, I’d like to check out Bugzilla on these. That’s a lot easier with test cases.

  • http://geekersmagazine.com geekers magazine

    I have seen the page break thing earlier. had to use a website then to see the pr .

  • pauP

    hi,
    I have an application made using ADF ,If I run my application in IE it runs fine but for firefox ,when I click on right-click menus it stays there on the page,it is not collapsing/disappearing
    after the use.I don’t understand if same code is working fine in IE then what is the problem with FF.

    Any help would be highly appreciated.

    thanks,
    Pau

  • http://www.mentorlog.com mentorlog

    Great post..It depends on browser..I am not able to figure out few things stil