There aren’t many articles covering incompatibilities, or CSS differences in Firefox alone — and for good reason.
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 outlineproperty 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.
In Firefox, when a table has its borders set to collapse using the border-collapseproperty, 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.
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.
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.
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.
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.
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:
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.
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>.
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
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.