Every CSS developer has probably come across the double-margin float bug, the three-pixel text jog bug or the duplicate character bug at one stage or another. However all of these bugs revolve around Internet Explorer. I would like to know what are the most common bugs you experience on other browsers such as Safari, Firefox and Opera.
Over to you.
Posted at November 30, 2005 7:18 PM
One terrible Safari bug that I run into often is the “Safari background repeat bug”. If you set a background not to repeat with no-repeat and it has negative positioning it will still be repeated.
There is a fix for it (not a hack, just an image manipulation) that takes care of it in most situations, but this is by far my most irritating Safari bug.
However, it’s not common to the three you’re asking about. ;)
I’ve always found the “rounding error bug” in Firefox most annoying as it leaves extra 1px lines all over the place, but apparently it has been fixed in Firefox 1.5…
The double-margin bug must be the most annoying. I have not actually found any others in the browsers mentioned. Just IE.
The more glaring problem with Safari right now is its inability to use any of the WYSIWYG text editors out there (e.g. FCK Editor, TinyMCE). Safari is the only browser which doesn’t support this stuff yet. I forget what the actual bug is right now, but according to developers it has something to do with the inability to dynamically load scripts.
I like to call this one the “absolute-positioning-visibility-flicker” bug for Firefox/Win. Check out the following link in Firefox/Win, http://www.nnsa.doe.gov/siteoffices.htm and you will notice that the box on the right flickers when you switch the information by clicking on a location on the map. The best documentation I can find is that it’s only on Windows and at one point it only flickered when it was in any other tab as opposed to the first tab (no other tabs being utilized). Let me know if you experience the same thing.
Thanks,
Jason
A couple more irritating Safari CSS bugs are that 1) overflow:auto doesn’t work right. The scrollbar that appears obscures the text. This is shoddy rendering on Safari’s part. The other is that border-collapse:collapse doesn’t work for tables.
And lest I forget, when you use list-style-position:inside, the contents of the < li > overlap the numbers. Not good.
The “Safari background repeat bug� was fixed in version 1.3/2.0, I think.
Safari) Combining numeral and named values; background repeating.
Opera) Vanishing background image in certain constructions; font sizing.
Firefox) Vanishing caret when a fixed element is positioned under a textarea/input; inline-block “support”.
@Jay: As far as I can tell, border-collapse works fine in Safari.
An annoying thing which I’m not sure if it’s a bug is that Firefox and Safari treat table margins differently when a caption is involved. Giving a table that has a caption a top margin makes Firefox push the caption away from the rest of the table. Safari and Opera don’t do that, which to me seems like the correct behaviour.
Two Safari annoyances:
1) FOUC. Seems to be associated with Google ads, but it’s not consistent.
2) Safari doesn’t always correctly calculate the height of boxes that have nothing but floated elements in them, requiring a clearing element.
Pick any browser : now try to style a legend element. Try positioning it. Try image replacement. You can’t get it working right in any browser I’ve tried, let alone cross browser consistent.
I want that fixing. There is no reason for Legend to be such a major pain in the ass. It’s just another element generating a box, so let me style it like any other element. That goes for anything on the page, anywhere. There’s no reason any HTML element should be any more or less configurable in CSS than any other element. Including form elements. I’m looking at you Safari.
Clearing of elements within which everything has been floated : safari, opera. (the overflow : hidden; and/or height : 1%; tricks aren’t always viable, nor does it make any sense that they fix the issue)
Consistent styling abilities for Caption and other rarely used HTML elements : Opera, Safari, Firefox.
Opera : The complete inability to ever hide button text BUT still being able to make that text utterly unreadable.
Firefox, Safari, IE : Browsers apparent inability to handel CSS generated content after form elements. Opera can do it.
Safari, Opera : Try adding a background graphic on a THEAD element. You will see it repeated on each TH within the THEAD.
I wouldn’t know if I’ve run into a CSS bug with Firefox. They mostly rely within the DOM upon frequent style manipulation with JavaScript.
Elements don’t inherit their style rules quite right when doing so after a few times…
I think it’s important that we remember that not all of the so-called “bugs” are really bugs, but rather differences in the handling of display defaults. I wrote on my blog recently about how there is no spec for what display defaults browsers should use when it comes to size, margins, padding, and more (http://jeffcroft.com/blog/archives/2005/11/question_who_re.php). It’s a real problem. Because there is no spec, we aren’t able to rely on the defaults at all, meaning that if we really want to be sure our elements display the same in all modern browsers, we needs to explicitly specify every CSS attribute. In other words, we probably should really be putting the following in our CSS files:
p {
display: block;
margin: 1em 0;
text-align: left;
}
Etcetra. We assume these things are going t be the defaults, but based on what? Certainly not based on any spec that’s out there.
The relation to CSS “bugs” in modern browsers is this: people often say things like, “Safari has a CSS bug in which is applies a top margin to a form, whereas Firefox does not (I totally made this one up, it’s probably not accurate).” In fact, that wouldn’t be a big at all — it would simply be a difference in the way the two browser decided to display the defaults. And, since there is no spec, browser makers are well within their rights to make these decisions.
I recently came across a bug while building my own standards-compliant editor. In it I have some drop-downs appearing over the iframe. Every other browser (even IE!) renders it fine but in Safari, the anchors within the drop-down are no longer clickable.
Ultimately, I determined that links absolutely-positioned on top of an iframe are not clickable. Instead, it’s as if they weren’t even there. You see them, but the cursor behaves as if you’re selecting the text within the iframe behind them.
I’m not aware of a workaround and would love if it someone pointed one out.
Fieldsets in Opera seem to have issues, especially when floated, and it would be really nice if forms were styled consistently across browsers. Not really a bug, just a lack of communication and agreed practice.
I’ve got some other problems with CSS IME at http://bleurgh.co.uk/blog/archives/5-Features-CSS-needs.html
very good topic, though not as urgent as IE bugs, since these only happen in minority browser market share used by people who are very forgiving of the faults.
Opera 8 has an annoying bug for absolutely positioned elements: percentages for dimensions are computed relative to the parent element rather than the containing block. It will also get the ‘right’ property wrong if the parent element is not the containing block.
It also has an odd bug where, if you float the first child of an LI element to the right, it will also float the list marker to the right.
I don’t know if these issues have been fixed in Opera 9TP1.
Gecko browsers have some odd bugs when you use the overflow property, especially on tables. Maybe it’s been fixed in FF 1.5, I don’t know.
Safari 1.3 and up have an odd thing about floated elements with negative margins, where it will occasionally make links in such a container unclickable. The workaround is to set position:relative, but why that works I don’t know.
Hey! Why do you create a mailto link if one specifies the email address in the contact details? Please edit my previous post and remove that, I get enough spam as it is! :(
Publishing people’s email addresses on a public page where spambots can harvest them is not very polite.
Firefox : the CSS3 opacity property.
Try playing for instance with an image set to 50% opacity and turning to full opacity (100%) on mouseover. Setting the opacity property to 1.0 will cause a flicker effect in Firefox (don’t know if this is still the case in 1.5).
Setting opacity to 0.99 instead of 1.0 will make the flicker effect disappear.
Too bad I didn’t read Tommy Olsson’s second comment before posting my e-mail address for all spammers to see.
Perhaps you should specify a URI too ?
I’m currently tripping over the different sized rendering of form elements - floated in [li] there’s overflow in Opera 8.51 where I don’t want it…
Interesting. There are lots of comments, but most of the bugs people mention seem to be real edge cases. Stuff that will only happen is a set or rather unusual circumstances occur.
This makes a lot of sense as these three browsers are continuously being updated, so any common bugs get found and fixed in the next update. Of course constant updates have their problems as well, as you never know if people are using the latest version or one of many buggier versions.
Mike D: Funnily enough, I’ve always seen the inability to use any of these WYSIWYG editors is Safari as a plus not a minus. Nut that’s my own personal jaded opinion about WYSIWYG editors.
Jay Jones: I’ve never had any problems with the border collapse property in Safari. Maybe you could show us a demo of the problem.
Tim Murtaugh: The Safari FOUC is annoying. I’ve only noticed it recently so I believe it’s a relatively new bug. I also believe that it has been fixed in the next build of Safari, although I may have just made that up.
On the subject of boxes containing floats, what do you mean about Safari not getting the height right? Because floated elements are taken out of the flow of the document, they have no effect on adjacent block-boxes. As such the parent box is supposed to behave as though it had no content. this is actually the correct behaviour. Unless of course I’m not understanding your comment correctly.
Matt Wilcox: Legend styling is a pain. However the spec doesn’t give any guidence on the default styling of elements, so it’s not really a bug per-se. Just a different approach. Still a pain.
Matt Wilcox: Never come across the Safari background on thead issue before, but it’s an interesting one.
Tommy Olsson: Can’t seem to replicate a problem in Safari with links not being clickable in floated elements with a negative margin. Do you have a test-case? p.s. Sorry about the email thing. It’s the default MT behaviour and I never got round to changing it.
We discovered it on the office site (http://www.bolagsverket.se/), and Roger Johansson was kind enough to find the solution.
I don’t have a test case, but without the position:relative, the links in the left-hand column do not respond to clicks in Safari 1.3+.
a lot of diferences between IE and FF. and all this are to…. details (the details who can make an design intresting)
(focus is not working in IE, but in IE is posibile to modify scroll bars)
As a translator from English (mostly W3C Recommendations) to French, I’m quite bothered by the fact that Safari as well as IE implement unproperly, or not at all, generated contents - ie, quotes and content properties .
Quoting rules are very much specific to a language and ignoring them is not a option.
So I use CSS rules as exemplified in section 12.4.2 of above URI to automatically generate quotes where appropriate.
It’s just a pity that these properties do not raise much concerns from Apple and Microsoft.
Hope this is appropriate comment,
JJS.
Jason: The website you talk about doesn’t seem to flicker when using the image map in FF 1.5 / Win XP.
The flickering when changing an element’s opacity is also present in Flash. Setting Alpha values to 1% or 99% is a very common workaround.
Being that it’s present in the most advanced rendering engines as well as in the Flash engine I suspect it’s a broader problem.
Safari’s text fields have very weird behaviours… like pasting stuff at the end of the field’s content but not where your insertion point is. Nothing to do with CSS, but still annoying when building an advanced web app.
Hi Andy,
It’d be really helpful and neat to have a comprehensive list of all known bugs in the various browsers - not being a web developer I usually try to fix things by trial and error. Finally understanding what caused the issue, googling for it and finding out that it’s a well know big - super! Such a list would really be handy.
What helps me to double check my code, which I’m sure you know already , is: http://www.browsercam.com/ , a great way to see how your design does on other browsers…
It appears that the border-collapse:collapse issue and the list-style-position:inside isse have been fixed in the newer Safari release, but I still have random issues with overflow:auto rendering the scrollbar overtop of some content.
The background-repeat bug still seems to be a problem as well… not fixed as of Safari 2.0.2
Not being able to float generated content in Firefox is annoying as it works fine in Safari and Opera. Safari’s inability to style form elements, whilst not really a bug, is insanely irritating. Fine, whoopy, you’ve passed Acid2; now, what about the basics including FOUC problems? Oh, and it would be lovely if all browser manufacturers would agree on how form elements should be styled.
I’ve got a Firefox issue on my site that I couldn’t explain or fix - the carat cursor was appearing several pixels below the input areas on my contact form.
It corrected itself with FF 1.5.
Hooray!
Safari: Haven’t had the chance to run Safari yet, so I really can’t say
FF: There have been a few headscratchers, but nothing so terrible that I was cussing the authors.
Opera: They tend to defy my expectations more often than any other browser, though I don’t cuss at it like I do IE 6 (4 years, and we’ve STILL got nearly useless button tags).
First, there’s the problem with figuring out exactly where the mouse is if you’ve been minimizing the top margin/border. Major pain if you’ve got one designer handling the js coding, and another one the page markup.
Second, if I tell something to inherit it’s cursor from its parent, I mean it. I don’t care if anyone else thinks that it shouldn’t inherit because it has different cursor behavior than it’s parent.
Third, if I change the cursor of the element the mouse is over, I do expect the cursor to change now, not when the mouse pointer transitions to another element.
Can you tell I’m winding down from writing an interactive dom/javascript based picture editing tool?
Mikey D:
Safari does have WYSIWYG support, it’s just that most editors already have a hell of a time getting the code to work between Firefox and IE, and they haven’t had the time to get it working in Safari. I’m currently in the process of udpating widgEditor to work with Safari (and a bit more robust).
Jason: That bug has been fixed in FF1.5/Win as far as I know.
I’ve encountered only one bug in Firefox as far as I can remember: It had something to do with a container styled with overflow:auto whose right padding doubled when I had a floated element (to the right) in it. That’s when I stopped using overflow to clear floats and started using the P.I.E. method.
Paul and Ryan: You are both correct; I just installed 1.5 after I posted this and noticed the bug was fixed.
Andy, you may find them marginal, but the ones I stated are often hit by me or colleagues :)
Hi Jan,
I didn’t mean to belittle the problems you were having. Even the most obscure bug can turn out to be a major pain in the arse if you get hit by it.
I just though it was interesting that the variety of bugs was so wide. By comparision, a recent post about common bugs in general surfaced the same 3-4 IE bugs time and time again. This is a good thing as it means bugs are getting fixed in Safari, Firefox and Opera before they become “common”.
Automatic linebreak on hyphens in Firefox for example “Versicherungs-beauftragter”.
Opera and IE break automatically on the hyphen and Firefox doesn’t. I haven’t been able to find control for this and it is a major pain for sidebars!
Charlie
Firefox has some rounding errors that only occur when you change an elements style uplon hover.
Say you have a pre element with a 1px border, and on hover its border will change to another colour, Firefox often moves either the top or bottom border by 1 pixel: the content doesn’t move.
Even more disturbingly it changes depending on where you have scrolled to on the page.
I have been working away trying to make a simple flash site compatilbe in every browser. I have already got past the flash embed validation issues (satay, hixie, gillay methods), but now I still seem to be having a slight problem with css horizontal centering. I have got it to work in all browsers (PC/Mac), only my login form won’t stay centered in Opera8 mac. I don’t know about Opera on the PC because I don’t have access to it. My site is www.danielbickley.com if anyone has a spare moment to have a look. The form just shifts down and to the right everytime you drag the window out. I know, it is probably just a simple tweak to fix, but I am pretty new to CSS. Finals are coming up soon so I don’t have a whole lot of time for trial and error right now. So, if this sounds like a familiar problem, or you have a moment to point me in the right direction that would be awesome.
Thanks.
Oh no Andy, I understood it as you wrote, I felt no depreciation. I just intended to say that even minor problems may appear reguralry, if someone is used to write in some style and use similar constructions.
I think we may have discovered a problem using a negative text-indent for image replacement and anchor text. Most browsers draw a dotted outline around active anchor elements. Firefox 1.5 seems to draw the outline all the way offscreen around the negatively indented text.
The good news is that FF 1.5 also supports the outline property. Currently, I can set outline:0; and that turns the whole thing off. It’s great for a quick network-wide fix, but I’m sure a better solution exists (because active outlines are a good thing and we generally want to keep them.)
I need to spend a little time reinvestigating image replacement techniques.
Andrew,
line-height: 0; font-size: 0;
or
overflow: hidden;
might help too.
The worst bug in Firefox is overflow: auto or overflow: anything other than none. It will cause the page to flicker on load, and if you try to dynamically move the DIV it is in with javascript, the contents of the div will NOT MOVE until you grab the corner of the browser and force it to.
I think PPK has a list or two on http://www.quirksmode.org/bugreports/index.html”>Quirksmode already…
The two I’m constantly coming across may not be all that complex, but they’re ever-present pains in the ass. I’ve been searching for a while and can’t seem to find any real explanations…
First off, if you create a relatively positioned DIV container to center a page within a browser window, and have a background image in that DIV - the background image ‘disappears’ if you place absolutely positioned DIV containers inside the original centering container.
Next up has to do with adding a centered background image to the body of a page. I have an instance where - when the viewing area is 800px wide (give or take) - the background image of the page lines up perfectly with graphics inside of a 700px wide centering DIV container. However, when you resize the window to a size smaller than the centering DIV, the page’s centered background image behaves differently depending on what browser I test in.
In Safari, the background of the page remains aligned with the centering DIV container - or relative to the full size of the page (as defined by the centering DIV), including vertical scroll. Switching over to Firefox and Camino, the page’s background image centers itself relative to the visible window - ignoring any vertical scroll (the ‘full’ size of the page), thereby throwing off the visual alignment. Mostly, for this one, I’m just wondering which of the two behaviors is considered ‘correct’.
Then there’s Opera (8.5) and it’s non-existent vertical scroll bars on resized windows… and accompanying ‘compression’ of absolutely positioned elements within a relatively centered DIV container to ‘fit’ everything in the visible space. But that’s another story, I think.
Vanishing caret in firefox/mozilla (1.0 and 1.5) when you place a TEXTAREA or INPUT TYPE=TEXT over an IFRAME.
… or a fixed box.
Here’s a ‘bug’ that bothered me for a while. In Firefox and Opera, ‘Object’ tag retains a line height by default, causing an un-wanted space underneath my dynamically loaded flash content. Setting the line-height of the surrounding div container to 0 fixed the problem for me.
I think if this is a bug with Safari and its way of handling text (negative top):
http://im.digitalhymn.com/?x=cms&fx=article&id=307
…and maybe, any idea to solve it?
Is this a known Safari ‘bug’ with the form input box formatting? Is it so that the font-size cannot be adjusted (inside the input box). The input box borders also look different, like it’s ignoring the formatting.
These are the properties I’m using:
border-color:#ffffff #003300 #003300 #009900;
border-style:solid;
border-width:1px;
text-decoration:none;
font-size:90%;
font-family:Arial;
background-color:#114411;
color:#ffff00;
These properties work on all other browsers and platforms. Only the background color for the box seems to stick.
In FF for Mac OS X, overflow scrollbars show though backgrounds of layers positioned above (along the z-axis). Bugzilla indicates that this is a Mac OS X chrome problem. Nonetheless, version 1.5 didn’t seem to have fixed it.
May 2006 resolve all these issues magically!
While the magic’s brewing, I have an issue with Opera 8.5 and FF 1.5 (Mac Tiger and I’m assuming WIN as well), where vertical centering of a background image on the body causes the background to center around the top of the body (hence top of the screen). This basically ruins my entire page design . Is this the definitive end of vertical centering with CSS?
FF 1.x did not do this. Any suggestions?
Just found the workaround to previous post: the body element no longer fills your screen, so the background image should be applied to the HTML element. In addition, you need to specify a height of 100% for it to center, otherwise it will remain centered at the top edge of the screen. I don’t follow the logic, but it seems to be working in all browsers.
Well, i’ve just stumbled upon:
input.button {
border: 1px solid #000000;
padding: 2px;
background-color: silver;
margin: 0px;
}
which rendered almost correctly, but firefox 1.5 thought it had to extend the lines over the border. don’t know why. opera and ie did render it correctly. funny ^^
FireFox 1.5 has a bug, where it ignores a top margin, on a relative div. Opera 7.5 and 8, Safari and IE6 do show the margin.
This is with validated markup and css, and using the doctype:
<!DOCTYPE HTML PUBLIC ”-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
Ok I am building a Web site in CSS at the moment and have come across a peculiar flaw.
I want it so that when the text link is clicked, it stays white, rather then grey.
so I put:
[quote]
a:link {
text-decoration: none;
color:#666666;
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 10px;
font-style: normal;
font-weight: bold;
font-variant: normal;
}
a:visited {
text-decoration: none;
color:#666666;
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 10px;
font-style: normal;
font-weight: bold;
font-variant: normal;
}
a:hover {
text-decoration: none;
color:#ffffff;
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 10px;
font-style: normal;
font-weight: bold;
font-variant: normal;
}
a:active {
text-decoration: none;
color:#ffffff;
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 10px;
font-style: normal;
font-weight: bold;
font-variant: normal;
}
[/quote]
Now here is the fun part, it only works in IE, it doesn’t work in Firefox no matter what I try.
That should count.
I’ve just stumbled across one with Opera 8.5. The standard position:absolute within a position:relative div does not appear to work. (Works fine in other Opera versions)
Toya …
if you want the text to stay white, the visited property, not the active property, should be set to #FFFFFF. the active state is triggered only when mousing-down on a link.
if you got it to work in ie as with the code you’ve posted here, then i think you’ve stumbled into another IE bug!!
Yeah, IE may be a shitty browser regarding security but firefox definitely isn’t doing any better in other departments.
For example borders around input fields are calculated around the width and height of the element. If you try to fix your input fields to fit into a certain space you go nuts. Opera, Konqueror and IE render it perfectly, Firefox fails miserably because it always ends up 2 pixels higher then the others. With the introduction of Firefox 1.5 I hoped these problems would dissapear but in fact they got worse.
Auto-Line-Breaking in div elements doesn’t work properly anymore. It is almost impossible to stay cross-browser compatible on a heavily styled portal with a lot of different pages and their unique features.
Sometimes I wish back the days when you only had to deal with the shortcomings of ONE browser (IE).
Safari seems to be one of the more challenging browsers. As all the IE bugs are quite well documented (www.positioniseverything.net/explorer.html), these don’t pose too many difficulties. Firefox doesn’t have many bugs (can’t think of any since they fixed the rounding bug).
Safari OTOH creates quite a few problems:
* Form support for legend tag
* Inconsistent floating handling
* Background images with large negative offsets (more than 512px)
Have a look at http://www.snook.ca/archives/000335.php for a nice Safari bug (which still affects version 2.0.3 on MacOS 10.4.5). The float position is different in Safari compared with the others.
Glenn
In Opera 8.5 on pc an absolutely positioned element that is given both a top and bottom property does not stretch to fit. It only accepts the top property. Css standards say that height should be implied if both top and bottom properties are specified.
trovster said on November 30, 2005 7:51 PM
Damn, I was expecting an existing list, which would have been interesting…