Browser bugs I’ve found

A list and links to test cases of browser bugs I’ve come across. If there are any work arounds they are indicted. I expect this list to grow, but, since so many people are ahead of me on this there might not be that many left to find.

Bugs in multiple browsers §

Browser support for list counter styling is highly variable

The css ::marker pseudo element is defined in the CSS Lists Module Level 3 which was initially published in 2011. While it is still an ‘Editor’s Draft’ as of May 2020 better support in browsers would be welcomed.

I have made a test case to test support for the ::marker pseudo element,list-style: symbols() function and the @counter-style rule.

Simple test case

css featureSafari 17.6Firefox 76Chrome 125
list-style: symbols()NoYesNo


Browser don’t implement font-variant-ligatures. The css Fonts Module Level 3 defines the font-variant-ligatures property to specify which ligatures should be used. Currently no browser fully supports all values of this property. §

Update: When I wrote the test case in June 2018 it was true. Now support is much better with only historic ligature support not working as expected …

Test case for font-variant-ligatures

font-variant-ligatures: Chrome 63 > Firefox 126 > ie 8 ie 9 Opera 11 Safari 11 >
normal yes yes no no no yes
inherit no no no no no no
common-ligatures yes yes no no no yes
no-common-ligatures yes yes no no no yes
discretionary-ligatures yes yes no no no yes
no-discretionary-ligatures yes yes no no no yes
historical-ligatures no no no no no no
no-historical-ligatures no no no no no no

Styling tables §

Browsers style tables poorly. Browser support for multiple css properties relating to tables — most notably the col, colgroup and the tr elements — is poor.

The table lists browses and properties. The row headings link to the test case for that property. Where a browser rendering is incorrect notes are after the table.

Css poperty Firefox 2 – 35 Opera 9 Safari 3 – 9 & Chrome ie 6 ie 7 ie 8 ie 9
border on colgroup & col yes buggy* yes no no yes yes
border on tr yes yes yes no no yes yes
border on tbody yes yes yes no no yes yes
border on thead & tfoot yes yes yes no no yes yes
border-style: hidden on tr yes yes yes no no buggy yes
border-style: hidden on colgroup yes yes yes no no buggy yes
border-style: hidden on td yes yes yes no no yes yes
visibility: collapse on td & th yes yes yes no no yes yes
visibility: collapse on tr yes buggy buggy no no yes yes
visibility: collapse on colgroup buggy buggy no no no yes yes
visibility: collapse on col buggy buggy no no no yes yes

Notes — I have not included properties that work in all the browsers tested so, background-color, color, borders on the td element and padding, since these all seem to work reliably.

Outline property the affecting layout — Firefox 1.5, 2.0, 3 and Opera 90.1 (fixed in opera 9.5) allow the outline property to affect the layout of blocks. Accourding to the ccs 2.1 spec the outline property should have no affect on layout. In Firefox 1.5 and Opera 9.1 this is not so. In both if the containing element is set to overflow: auto then the outline is taken into account when positioning the block, while in Opera it affects the calculated width of the block but not its position.

The test case demonstrates the bug, there should be no scroll bars and no red should be visible.

Simple test case.

Styling legend tags §

Recently I was trying to position legend tags and got nowhere — so I’ve put together a small grid of what works and what doesn’t. To be honest not a lot does, see the table below. I have also made a few test cases and notes.

Browser position: set float:
absolute relative fixed margins* width left right
Firefox 8 & 9 yes no yes yes yes yes yes
Firefox 5 yes yes yes yes yes yes yes
Firefox 1.5, 2.0 & 3 no no no yes no no no
Opera 8.5 buggy yes buggy no no yes yes
Opera 9 yes yes yes yes yes yes yes
Safari 2.03 – 5 yes yes yes yes yes yes yes
ie 9 yes yes yes yes yes yes yes
ie 8 yes yes yes yes yes yes yes
ie 7 buggy buggy yes buggy buggy yes yes
ie 6 buggy buggy no buggy no yes yes
ie 5.5 buggy buggy no buggy no yes yes

General notes on the table — styling the legend tag is at best hit and miss, Safari seems to do the best job of it, while Firefox seems not to even try. Interestingly Firefox 1 seemed to do more than Firefox 1.5, although I didn’t add it to the table since it is no longer current.

Firefox §

When applying styles using :first-line and :first-letter and using classes applied using javascript’s className method the styles are not applied. §

A test case which illustrates the bug using the following code:

  <meta http-equiv="content-type"
    content="text/html; charset=utf-8">
    <title>Test case for applying styles with
    pseudo elements</title>
    <style type="text/css">
      width: 300px
      color: green
      color: green


  <script type="text/javascript">
    function dropCap()  {

  <p>When you click the link the first letter should

become Green</p>
  <p>When you click the link the first line of this paragraph
    should become green.</p>
  <p><a href="#" onclick="dropCap();return false">Apply
     the style</a></p>


overflow: auto on list items (fixed in Firefox 1.5). When an li element is set to overflow: auto Firefox creates a horizontal scroll bar in most cases. Short entries not containing block level tags don’t suffer from this problem. §

Simple test case.

The work around is to wrap the content of a list item in a div and set the overflow on the div instead.

styling ::first-letter is limited §

According to there are a large number css properties that Firefox does not apply such as: hight, width, min-width, max-width, min-hight, max-height, line-height and text-decoration. This is problematic as it makes cross platform usage unreliable. I have made a test case

Styling of form elements in Firefox is frustratingly limited. §

In Firefox the ability to style form elements is surprisingly limited. The following elements ignore line-hight:

The button element has 1px of padding top and bottom and 3px on the left and right which cannot be removed. Test case.

Internet Explorer §

ie6, ie7, ie8 & ie 9 have 4095 upper limit on the number of selectors in a css file. Is this a bug? I’m not sure it might be better called a limitation. I’ve not found anything in the css specs mandating infintly large style sheets and in fairness if you have got over 4095 selectors in your css file then you probably have other problems to worry about. §

This is quite a well know bug, but, I couldn’t find a test case for it anywhere so I’ve written a simple test case.

ie 7, 8 & 9 :hover is buggy. When :hover is applied to an element the styling should still be applied when the mouse is over one of the children of that element. In ie 7 and 8 under certain conditions the styling is lost, specifically when hovering over input elements. The bug is slightly tricky to trigger so I have made a screen recording to demonstrate. The video shows ie7, ie8 exhibits the same behaviour but the bug is easier to trigger. I have also created a test case. §

Not only is this bug still present in ie 9 it is worse, easier to trigger and flashes in a vomit inducingly fast way.

The key element to triggering the bug is the speed of the mouse pointer, it needs to be moving quite fast when entering the input, although not as fast over input type=text for some reason. View the source to see the details, it is simple markup a div containing three input tags: type = submit, text and button. The div is styled to have a green background on :hover and should stay green the entire time the mouse is inside its area. This does not happen constantly in ie 7 and 8.

Test case and recorded demonstration.

ie 5.5 and 6 Incorrectly sets the left origin of the positioning coordinates to the edge of the content of the first element of the containing block, instead of the edge of the relatively positioned containing block.

This occurs whether the preceding element has its left margin or left padding set. Strangely ie behaves correctly if the position is set relative to the right edge. It also behaves correctly if the containing block is positioned absolutely

I think the bug is explained by On having layout in the section Containing block, what containing block?

Simple test case.

ie 5, 5.5, 6 and 7 move an unfloated element to the position as though they had been floated. This only affects the element immediately following the float. §

Simple test case.

Incorrect positions when using right and bottom ie 5, 5.5 and 6. If the height of a relatively positioned block is an an even number or the width an odd number, any element that’s positioned absolutely inside that block and use bottom or right will be 1px out. They will be either 1px too high or 1px to the left of their correct position. This depends on the width or height of the containing block. If both occur the positioned element will be incorrectly positioned on both axes. §

Simple test case and an unstyled version for those with standards compliant browsers so you can read the explanation.

Opera §

Containing floats inside overflow:auto (fixed in Opera 8). When a block set to, overflow: auto, contains floats Opera does not contain the floats correctly. See Super simple clearing floats at Anne’s Weblog for an explanation of why this is useful and see css 2 spec as to why it should work. §

Simple test case.

Opera not recognising &rsquo; and &lsquo; (fixed in Opera 8). When using a xhtml doc type Opera does not display anything. The numeric references &#8216; and &#8217; work fine. §

Safari §

Safari defaults span attribute to 0 (fixed in Safari 3). When the colgroup element does not have any child col elements and the span attribute is not set Safari defaults the value to 0. The span attribute should default to 1. §

Simple test case.

Safari crashes when the hover pseudo-class is used to generate content (fixed as of at least version 2.0.4 (419.3)). In an experiment with generated content, I discovered that attempting to use position: absolute will crash Safari when the user hovers over the element. §

Since css 2 does not really cover positioning generated content this technique is of limited use, but it does work in Opera.

Simple test case.

If a stylesheet specifies a font that the user has installed locally but is not part of the Apple supplied fonts Safari will not use it. To use a font that is not part of the standard OS install on a website the font must be loaded using an @font-face rule.

This is quite tricky to make a test case for, but, here goes go get the Robotto font from google. Install it then load the test case in your browser, and it won’t use the locally installed font. Bug or feature? It is probbaly a feature, as part of the Apple’s intelligent tracking prevention. But it would be nice to have a document about it, which, if it exsits, I couldn’t find it.