Here's a demo:
http://codepen.io/raddevon/pen/ujwqA
The insertion point is not visible for this styled text input control in versions of IE below 10. The input control otherwise behaves as it should. I can enter text into it despite not being able to see the insertion point. Does anyone know how to fix this problem?
It turned out to be the text-align: right property that causes the insertion point to be invisible in older versions of IE. I override this to text-align: left in my IE stylesheet to fix the problem.
Related
We are not sure if this is an issue with React-Select or simply an issue with our styles that is causing the issue. On our website, when text is typed into any of our (react-select) search bars, the text slowly vanishes to the left as more text is added. On the page linked, in the React-Select search box where it has placeholder text Focus Conferences, we have typed Typing any text to showcase the issue, and here is how it appears. Notice text missing off to the left:
To troubleshoot this issue, we have removed the blur event listener in Chrome Dev Tools so that we can type in the field and then also inspect the field without the text being removed from the search bar. Here are the styles we are seeing on this relevant input. These are all default styles for this input from react-select:
What I've noticed is that changing the width: 100% to width: 120% seems to solve this issue, however, I am not sure how to permanently make the change to 120% in our code. There is no class on this input, which makes it difficult to grab and style from our code or from css. https://react-select.com/styles are the ways to style, but none of the innerComponents seem to be for this input element. Either way, changing the width to 120% also seems like a hacky way to resolve this issue.
What's going on here? Why is the text bleeding off to the left in all of our search bars as more text is typed? We recently upgraded to react-select 5.7, and this issue was not happening previously with version 4. Any help or input is appreciated.
I've a website based on Html KickStart and I notice an annoying problem in IE10.
The issue: when you open the web page, the text in the input field is aligned against the left hand side of the field. When you put the focus on it, and start typing, the text jumps to the right (where it is supposed to be, as you can see in other browsers). When the field looses the focus, the text jumps left again, against the side once more. The input field in question is styled.
The problem is clearly visible on the Html KickStart demo site:
http://www.99lime.com/elements/
Here you can also find the css code files etc.
I don't seem to be able to find the cause of this behaviour. Any help would be greatly appreciated.
Check out this css property : https://developer.mozilla.org/en-US/docs/Web/CSS/direction
direction effects the css declaration being used known as text-align:start
which isn't supported by IE 10
I'm using css gradients and padding to simulate buttons around an anchor tag. The problem I am running into is that firefox seems to make the button 3 pixels larger. 1 pixel on top and 2 on bottom. This seems to happen with not only the example i posted but everywhere on the page where i use the padding. I put up and example at http://wemw.net/example.php. In firefox the button top and bottom line up perfectly with the search box, but in chrome as i said its off by 1 pixel on top and 2 on bottom. I am using the w3 transitional(tried strict as well) doctype and a css reset. In the reset all anchor tags are set to padding: 0, so I'm confused as to why this extra padding is being added. Is there a workaround to this or is it just something you have to deal with when working with gecko and webkit browsers?
EDIT: So I logged over to windows and it is appearing the same in both browsers now. I'm assuming it is OS specific problems? Since no where near as many people use linux I'm going to change the padding to make it work, but in the interest of consistency can anyone offer a solution for cross-os cross-browser solutions? I do not own a mac and cannot easily test it there, but if windows/linux can have problems with the same versions of the same browsers is it safe to assume mac could also have issues i am unaware of?
It's not the padding on the anchor tag, it's the size of the text box that is inconsistent. <input> elements always caused such problems for me too, and I always found it extremely tedious to align them together nicely (you haven't yet seen it in IE8, have you?). I think that the easiest cross-browser solution here would be to remove the border from the text box and use a background image instead (or better yet, a background image on the element containing the text box) properly aligned with the button.
I want to create a search bar like one in this page http://dl.dropbox.com/u/333492/search/form.html
If you load that page with chrome, opera or safari, the search bar looks like it should (tested on mac). However, if you use firefox (tested at least with ff 3.5 and 3.6 on mac), you'll see that one extra pixel gets added on top of the text field, and thus the text field is one pixel lower than the button, which looks ugly.
I tried to remove all possible borders and paddings but the problem persists. I also noticed that it doesn't occur when the search button is not there.
Does someone have any idea on what might be causing this behavior? Or, even better, could someone alter the CSS on that page so that the problem would be fixed?
I finally found a blog post that explains the cause of the problem and proposes an answer that partially fixes the situation. Thanks #anttisykari in Twitter!
http://christophzillgens.com/en/articles/equal-height-input-and-button-elements-in-firefox-and-safari
So the correct answer is to add following lines to the CSS:
input[type="submit"]::-moz-focus-inner {border:0;} /* ff specific stuff, yuck*/
input[type="submit"]:focus {background:#333;} /* change accordingly depending on your button bg color, this fixes the focus problem when using keyboard to move betweenform elements */
However, IE8 still broke my form, so I had to add these to both input elements.
display: block;
position: relative;
float: left;
Now everything seems to be ok.
I fall into an IE bug that I don't find a way to solve
Here's the template http://codecanyon.net/item/tquery-dynamic-tables/full_screen_preview/89478
If you open with Firefox or Chrome, the table header shows correctly, no BLACK, if you use IE7 or IE8, it shows some black space. Why? I tried to change padding, margin... but that didn't work, the black space is still glued. How can I fix such bugs?
Please also, explain what tools, or methods can help fix this bug
Update: Bug Fixed!
The reason is that IE gives an arbitrary size/padding/margin to the img element when the src is undefined.
When the src attribute is defined dynamically through JavaScript, this doesn't correct it. It still undefined, so it doesn't solve the problem.
Solution: Fix a height/width for the image.
The sort image you have in the cells still takes up space - in this case, the space used by IE's default "invalid image" placeholder, because you left the src attribute empty. You can verify this using Developer Tools, and setting the height to 1 pixel.
The problem is that visibility: hidden doesn't mean "don't use any space" - it means "claim the space, but don't show anything there". Use display: none instead if you don't want it to take up any space.
You may still wonder "But why didn't I see this anywhere else?" Well, that's due to the other browsers handling the missing image differently.
One tool that can help is the IE Developer Toolbar, which wil let you look at individual elements and the CSS applied to them. Looking quickly at the real page, not the link you sent (because the IE toolbar can't go through IFRAMEs for some reason), the one thing that pops out is the TD and TH elements in your table head show hasLayout: -1. It's a custom IE property that causes all sorts of bugs. You can read about it here. A couple of quick fixes you can try: apply 'zoom: 1;' or 'position: relative;' to those elements to see if it goes way. That's not a fix, it's a hack, but it often works.