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-shadowproperty - Firefox 3.x doesn’t support the
box-shadowproperty, except when using the proprietary prefix-moz- - Firefox 3.x doesn’t support the
box-sizingproperty, 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-imageproperty, 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-infor thedisplayproperty - Firefox doesn’t support the
::selectionpseudo-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.
home
Info
sitemap



