I have this site and for some reason in IE7 I can't click in the search field on the top right. Every other browser is fine. I have not been able to check other versions of IE but I presume they are failing as well. What is going on?
Hard to say for sure since I don't have access to IE7 at the moment, but you might want to look into setting the z-index of the input or its container.
Also, when I looked at your HTML it looked like something was malformed because I saw the attribute "value" without a value. Double check all the HTML is correct.
Your link is password protected, but in addition to checking CSS z-index issues, you may want to try using the position: relative; and zoom: 1; properties in an IE7-conditional stylesheet — a combination of the two tends to fix a good portion of IE7 issues. If you don't have the IE Developer Toolbar, it's invaluable for resolving display and functional issues.
Related
NOTE: This is the intrinsic (built-in) autocomplete that comes with Firefox. I remember the fix having something to with a setting in Firefox's about:config page if that helps.
I had a fix for this involving changing a configuration setting but now I forget how to do it. This is it:
What is it? It's a simple about:config fix, perhaps something to do with acceleration of some kind. Thanks.
Based on the picture, I would assume that the container element of the autocomplete field needs to be set to position:relative. That is the best guess I can give without code.
Originally the question was tagged css and did not mention that autocomplete is the built-in one. Keeping answer for the JavaScript + CSS (e.g. jQuery UI autocomplete) case for future visitors.
Built-in autocomplete
Page contents (even CSS and JavaScript) do not influence the built-in autocomplete functionality, AFAIK. Page author can use just the autocomplete attribute in HTML5 and the requestAutocomplete API in Chromium.
The only thing that could influence the built-in autocomplete is browser settings. Bad suggestions list position is definitely a browser bug. You are just looking for a work-around, for a configuration that does not trigger the bug. Firefox configuration is accessible in about:config, so you can be right that you need to change something there.
The only thing that came to my mind regarding UI display is hardware acceleration, which tends to cause trouble. That can be tweaked (and turned off) via about:config. Search for layers. You said that it does not solve your problem; I’m stucked as I have no other idea.
JavaScript autocomplete
The issue is probably caused by absolute positioning and bad choice of the coordinate system in this case. For more info see containing block and absolute positioning in the spec.
Try changing the position property of the enclosing box to relative.
#mailinput {
position: relative;
}
#mailinput #mail_autocomplete {
position: absolute;
top: 1.5em;
}
I'm putting together a page, and am really struggling with backgrounds across browsers.
The page uses a number of alpha-blended backgrounds, box shadows and border-radii and it is composited almost entirely using inline styles (essentially there are few/no CSS classes used).
IE9 is my primary browser, and in it, the page looks great. However, on Chrome (and I'm told Firefox), most of my alpha-blended backgrounds render either not-at-all (transparent), or as solid colors! I'm using Standards Mode with an HTML5 !DOCTYPE declaration, so it's not as though I'm leveraging IE quirks or anything!
Clearly on IE versions before 9, the backgrounds (and other things are problematic). But I'm not concerned with supporting ancient software, and those users get a browsing experience that they deserve.
The common refrain for years has been that "transparency on IE sucks!", so I was comfortable in expecting that if I got it to work adequately on IE (typically the worst platform), then the others would just fall in line, but here I am struggling in the opposite direction! I'm using the standard "rgba(r,g,b,a);" directive on the "background-Color" attribute so I'm not using any radical DirectX filters or other magic, nevertheless, on (NOT Internet Explorer 9+) browsers, I'm getting some non-alpha-blended results (sometimes it works, sometimes it doesn't).
The site can be previewed at: https://net-xpert.com/ -- All of the pull-down menus are supposed to have translucent backgrounds, and so too the hovering link-bar at the bottom of the page. Also if you go to the "Ask us a Question" page, the dialog there should have tinted backgrounds on all of the input fields...
Oh, lastly, I am ENTIRELY LOATHE to implement ANY b/s, browser/platform-specific, 'experimental' style-codes! Anything in CSS2/3 is fine, but I simply REFUSE to use any kind of "-browser-some-quirky-CSSAttribute" styles! (I wish more developers would do this too! -- then browser manufacturers would be under greater pressure to adopt these STANDARDS and our lives would be SO MUCH EASIER, but I digress...)
Anyway, any insight on a standards-compliant solution would be greatly appreciated (even if it's just a communal acknowledgement that "ya, Chrome et al is currently not implementing this correctly...", at least then I'll know there's nothing to be done about it...)
Thanks!
Well, this is a very late answer, but maybe this'll still be of use to you (your site still seems to be up and running).
I have a should-work-for-you solution, assuming that you can modify one of your stylesheets. As to WHY you've encountered this problem ..? I can only speculate, because I don't know how to recreate your exact configuration.
The fix;
div[id^=mainMenuOverDiv] {
background-color: rgba(128,128,128,0.9) !important;
}
I'm not a fan of using !important unecessarily, and you may be able to remove that by using greater specificity. I've tested this in Firefox, though and it seems to work - obviously, you'll want to substitute the actual rgba(x,x,x,x) values with your own.
You seem to be using some JavaScript (I'm assuming) which randomizes the DIV ID every time you hover over the menu - but the beginning remains consistent (i.e. one time it will be #mainMenuOverDivjkhasdfsd89f9f9sdfl3l4l34lfdbvbc, then the next, it'll be #mainMenuOverDivLSDklsdkmlzxncbzmxnc90234xcvassf). Using the 'starts with' CSS selector (as provided in the example), you can still isolate the menu despite this potential spanner in the works.
It's interesting (and probably insightful) that this even works, given that inline CSS usually can't be overridden.
As for why this is happening, one possibility is that some JavaScript generated code is not correctly porting over to the non-IE browsers. Alternatively, if you're using it anywhere, code minification may also break some functionality (and vary between browsers) - many minification plugins need to be tweaked for individual setups to ensure that everything continues to work fine as one size does not necessarily fit all. For example, you might find that on one site you can minify everything except the JavaScript, while on another site, JavaScript is fine, but you can't minify inline CSS, etc. Google Analytics code sometimes falls victim to this.
So to my eye, the issue possibly isn't to do with IE/Chrome/Firefox or Safari - transparency is working fine on all of them - I think it's most likely the way your code is being manipulated or delivered to the browser.
Hope that helps in some way. Let me know if you can't use an external stylesheet and I'll try to find an alternative.
To start with, I have examples and code here (a site I keep to play with stuff). This is the actual link just in case: http://www.williamrosmus.com/examples/calendar1_wf.html
This is an issue I am having specifically with Firefox (I'm using v3.6), and am wondering what is going on. Requonc displays reasonably and IE8 perfectly.
For a learning exercise I manually created a calendar in xhtml using CSS tables rather than traditional html tags. I set the height and width for the cells to be 100px by 100px. However the top and bottom rows, where some of the cells are empty display way too high in Firefox.
Any suggestions or comments on how to fix this to display correctly or what is going on with Firefox?
Regards,
BillR
Further to this, as per the suggestion by Robin, I logged this as a bug on mozilla.org. Someone just confirmed it there. In case anyone is interested:
https://bugzilla.mozilla.org/show_bug.cgi?id=634489
Just stick inside the empty cells?
I just tested, and this fixes it in Firefox.
I found a page which talks a little more about the problem you're having.
It suggests a CSS alternative; table { empty-cells: show }, see:
https://developer.mozilla.org/en/CSS/empty-cells
However, this doesn't seem to help in Firefox with your <div> tags with display: table-cell.
See discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=634489 and https://bugzilla.mozilla.org/show_bug.cgi?id=569645 for further details. (Using 'vertical-align:top' or 'vertical-align: bottom' on all the table cells should be a reasonable workaround, though.)
I believe this is a bug in Gecko. I trawled through Bugzilla (https://bugzilla.mozilla.org/) but couldn’t find any other people reporting this. It’s probably worth filing a bug with a reduced testcase (or just link in your current one) to see what the devs over there make of it.
Regarding a specific workaround, thirtydot’s suggestion of an is probably your best bet.
When i changed your display of the div.calendar_day to "inline-block" or "block" instead of table-cell and added float:left the height was rendered properly.
I am working on a big form and it contains a lot of buttons all over the form, therefore I am trying to get working input[type="button"] in my main css file so it would catch all buttons with out having to add a class to every single one, for some reason this is not working on IE7, after checking on the web it says that IE7 should be supporting this.
Also it has to be type="button" and not type="submit" as not all buttons will submit the form.
Could anybody give a hint what am I doing wrong?
input[type="button"] {
text-align:center;
}
I have also tried input[type=button]
I was struggling getting input[type=button] selectors working in IE7 or IE8. The problem turned out to be that the HTML Pages were missing a "!DOCTYPE" declaration. Once I added
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Then everything worked fine. You can obviously use a different "!DOCTYPE" declaration to suit your requirements.
input[type="button"]{ text-align:center; }
What do you expect that to do? The text in an <input type="button"> is already centered by default.
If you want to align the button itself within the parent, you have to set text-align on the parent element, not the button.
Attribute selectors — with or without quotes — do work on IE7. It's IE6 that's the problem browser there.
I've had no problems getting css statements like that working in IE7; IE6 is always the problem but I believe this CSS would work in there as well. So I don't think IE7 is the problem.
The first thing is that your CSS sample will only affect buttons, it will not affect submit buttons. But that's an easy fix; change your css to:
input[type="submit"], input[Type="button"]
{ text-align: center; }
Second, as Manolo Santos said, could you have another CSS statement that is overriding the text-align setting? A setting on just input elements? It's probably worth using a developer tool like Firebug or the developer components built into Chrome or IE8 to help find the CSS problem.
Attribute selectors are, unfortunately, not yet well implemented in all major browsers, because it is CSS3 and not 2.1, the current standard. Because the guys over at W3C are not that quick in making decisions, you better not set your hopes too high, because we won't be able to use css3 any time soon. Some aspects of it are already implemented, but this one isn't (surely not in IE6).
So, as you already said yourself, it would be much better to provide all of your inputs with a class, and make it a habit to do so every time you create a form. It's always handy and not a lot of work when you are already programming the form.
When I create a form, I always add the type of an input as a class, e.g.:
Especially the last two will come in handy in a lot of cases, because you don't háve to style the .button and .submit separately, but you cóuld if you would like to do so.
They work for me in IE7 (both forms, with and without quotes).
Maybe there's another selector that is masking yours. You could try making your selector more specific in order to give it more priority, e.g.:
body form input[type="button"] {
background: red;
}
I am pretty sure everybody is aware of the fact that the solution of adding a !DockType to the header isn't a possibility all the time.
For instance, I develop in DotNetNuke (DNN) environment which the developer doesn't have an access to the header. Then it makes it almost impossible to add !DocType.
In this case you don’t have too much of an option except relating a CssClass to the button and referring to it, explicitly, in the CSS module.
This question is old but if someone have a related problem.. I spend a few minutes trying to solve a similiar problem
input[type="Submit"] doesn't work on IE7 (despite of IE assigning the style correctly to the input as I saw in dev tools).
SOLUTION: I switched from Submit to submit and it worked!
I posted this here because it may help someone when debugging.
For whatever reason, there are times when attribute selectors will not apply before the page is displayed in IE7. This actually just happened to me. My selector was table[bgColor="#c0c0c0"] and would not apply on page load. Since I was using IE9 (Browser Mode: IE7, Document Mode: IE7 Standards), I was able to use F12 Developer Tools to look at my CSS file. I unchecked the selector and then checked it again. The attributes applied after that. This is reproducible exactly in good ol' IE7, so I'm going to have to find a work-around. (Note: Neither using single, double, or no quotes nor making variations in capitalization make an impact here.)
Generally, what's the best way to tackle a layout bug in IE6? What are the most common bugs or problems that one should look for when trying to figure out why your page suddenly looks like a monkey coded it?
First Things First
Get yourself the Internet Explorer Developer Toolbar. It's a life saver and works great with IE6 and/or IE7. It's no replacement for Web Developer Toolbar or Firebug for Firefox, but it's better than nothing.
Know Thy Enemy
Read up on the quirks of IE — particularly hasLayout and overflow and the like. There are also many CSS niceties that you'll have to either do without or find alternatives. Look into how many of the popular JavaScript toolkits/frameworks/libraries get around different issues.
Rome Wasn't Built in a Day
The more you have to work with it, the more you'll remember off hand and won't have to lookup as often. There's just no replacement for experience in this. As several have pointed out, though, there are great resources out there on the net. Position Is Everything is certainly up there.
http://www.positioniseverything.net/ will certainly address your problem.
It provides comprehensive and in-depth descriptions of browser bugs along with options to work around them. A must read, in my opinion,
One good way to start learning about how IE happens to be mangling the page is to turn on red borders on different elements with CSS (border: 1px solid red;). This will immediately tell you whether it's a margin problem or a padding problem, how wide the element really is, etc.
The box model is usually the culprit. Basically what this means is that any div you are trying to position and use unsupported CSS with will cause this problem.
You may find it happens if you are using min-{width,height} or max-{width,height}.
this provides a great reference for checking compadibility with different versions.
http://www.aptana.com/reference/html/api/CSS.index.html
Noticed that Marc's post is at a -2 =D. He's only saying "resort to tables" even though they blow, because in sucky browsers like IE6, some of the broken CSS commands work in tables only (who know's why... dam you Bill Gates!!!). Here's a good reference to see what works and doesn't work as far as CSS goes. http://www.quirksmode.org/css/contents.html . It's a great reference to check on what cool effects work/don't work with various, widely used browsers. Also, always have a go-to plan for users who browse with IE6 (even though it's just about as old as mechanical dirt) as many businesses still use older browsers (including non-profits/3rd world countries etc.) So by all means, create the bugged out drop-down menu that looks WAY better than a standard horizontal menu, but create a secondary one specifically for IE6 that becomes the default when the page receives a request from an IE6 browser.
how do you define layout bug? the most frustrating layout implementation (i don't know if this should be defined as bug) in IE is we need to always specify style="display:inline" in the HTML <form> tag so that a blank line won't appear to disturb the form layout.
This question I believe has far too much scope.
Validate your code, and if pain persists, well, good luck.
The only real solutions, as with any other ballpark bug type are to google for a solution, or ask somebody who knows, ( ie: give the exact problem to us here at stackoverflow ).
You can use the IE Dev toolbar to glean an Idea, but many of the bugs are random, inexplicable, and esoteric. IE: the guillotine bug, the random item duplication bug, etc etc, the list goes on, and you can spend hours literally goofing with stupid variables everywhere and achieve nothing.
I have a simple strategy that works every time.
First, I develop the site using commonly accepted CSS to look good in Safari and Firefox 3. See w3schools.com for details on browser support.
Then, I go into IE6 and IE7 and alter the CSS using conditional includes.
This is hack free and lets you handle different browsers (IE6 and IE7 have separate issues).
Most of the issues you'll find come from unsupported features in IE (like min-width), errors in the box model (IE adds unseen extra padding (3px) to some boxes), or positioning issues. Go for those first as they are often the issue.
A common problem is padding not getting added to the width of a block element. So for layout div's, avoid using padding and instead use elements within them to define the padding.
I use Rafel Lima's Browser Selector when I need to tweak differences between IE/Standards browsers. It greatly reduces using "hacks" in your HTML to solve common problems.
You can target CSS statements for different browsers, or even different versions of browsers (Hello IE 6). It's very simple to implement, but requires the user has JavaScript turned on (most do).
.thing { ....}
.ie .thing { ....}
.ie6 .thing { ....}
We had a floating div issue that was only evident in a particular version of IE6. It was fixed by downloading the latest service pack.
In theory, use CSS compatible with IE6 layout bugs, utilise only well known workarounds (css and html filters) and code for them in a way that wont break forward compatibility, test for quirks/strict mode.
In reality, resort to tables.