http://jsfiddle.net/CtaBe/
I've tested this in FF, Chrome and IE. Only FF shows the intended behavior (or at least what I think is the intended behavior). Chrome and IE show the same behavior: when you first focus on the input, the cursor doesn't indent. After you type somehing, delete it, and re-focus, it indents properly.
How can I fix this? Because I want to display an image at that indented space.
Quick disclaimer: this message outlines a solid example of why a person would choose to use text-indent on an input field rather than padding. It does not answer "how to fix IE handle text-indent on input fields"
The thing about padding-left is that it alters the width of your input field, which can be undesirable.
Imagine a scenario where you wish to show a background-image icon for the following states of your inputs' data:
required field
invalid input
missed required field
password strength
In such a scenario, we'd need to nudge the text away from the left border to display the icon (which is a much simpler feat than going for the right side, but that's a whole other discussion. If we use padding, the width of the input field changes. That's not ideal, since the various "states" can change.
For instance, maybe a field is only required based on the value of another field. When that field "becomes" required the field "grows" according whatever padding we apply to move the text away from the icon, via relevant class. That's far from elegant, especially when other fields are floated next to it.
Furthermore, in the case of textareas, we wouldn't want to pad the entire side - the first line would suffice.
That's exactly where using text-indent comes into play. And it works great - except in Internet explorer. Which is what has led me here, as I search for other ideas or solutions. I have a few ideas in mind but hopefully there's something simpler that I haven't thought of.
In Chrome, this is a known issue. Please star it :)
'text-indent' applies to block-level elements, table cells and inline blocks. I hope you are using it on a not block-level element.
Related
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 trying to modify a default select box using CSS. I've already done it. But, some problems are happened at firefox. What I've done still now:
It's the perfect result on all browser except firefox and IE
At firefox, there are the problems:
(1) There are an unexpected border on the right side of the select box
(2) Padding of text of select box is much bigger than other input field.
At IE, same problem happened. There are unexpected and much clear box at the right of the select box:
How can I remove that unexpected line/box from firefox and IE. Also, what can be responsible for the padding problem at firefox?
Well, I've used this tutorial's concept to customize the select box using CSS only. And I've put my code at
jsfiddle.net/w9kFc/1/
(I can't add the select-icon image at jsfiddle from external link. So, I've taken the screenshot locally. But, I've given the image's link at the jsfiddle code. )
This seems to work in IE10: jsFiddle
Added a label around the select.
Replaced the text-indent with padding.
I'm redesigning the skin and layout of a user info form. Initially it was done using a table, but I really don't want to use a table for the layout. My code is here http://jsfiddle.net/Chris22/eNqrM/ I've tested my code in all browsers, Opera 11.x, FF 12.x, Chrome 18.x, Safari 5.1.x and the form looks great. My problem is IE9.
Please take a look at the code in IE9 and see if anyone can figure out what I've mis-coded as to why the form elements don't line up and some have a different text treatment. I just can't seem to figure it out.
Here is the original table-layout if any one wants to compare. http://jsfiddle.net/Chris22/q3sCb/3/ Both sets of code have java spring form tags, so it was a little difficult for me as well to figure it as I am a FED (front-end dev). Maybe I've got something mixed up here. I don't know.
Thanks!!
P.S. If modifying the original table-layout is the better way to do this, I'd appreciate some help on how to begin to code that... I haven't used tables for layout in a while.
IE9:
I fixed this. May not be the best way, but I wrapped the input elements in the label tag and added a rule float:right to the input tag within it. Thanks for everyone's feedback
I've got the same problem with a relatively straightforward form that has inputs with a value attribute. Not sure if that's actually an answer, but it may help to know that you are not alone in seeing a misalignment. I'm slightly baffled as to why some people are NOT seeing a misalignment. The fact that float:right gives a fix is useful to me and may have something to do with the mysterious hasLayout property that has long been a 'feature' of IE. Floating, left or right, induces 'hasLayout' but may have other consequences. A common fix for not 'having layout' is to give everything a zoom:1 in CSS - this induces 'having layout' and usually without any visual change, because zooming with a factor of 1 doesn't resize anything.
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.
I'm working now on a page that has a column of boxes styled with sexy shadows and corners and whatnot using the example here. I have to admit, I don't fully understand how that CSS works, but it looks great.
Inside the topmost box is a text-type input used for searching. That search box is wired up to a YUI autocomplete widget.
Everything works fine in Firefox3 on Mac, FF2 on Windows, Safari on Mac. In IE7 on WinXP, the autocomplete suggestions render underneath the round-cornered boxes, making all but the first one unreadable (although you can still see enough peeking out between boxes that I'm comfortable IE7 really is getting more than one suggestion).
Where could I start looking to correct the problem?
Here's what success looks like in FF2 on WinXP:
And here's what failure looks like in IE7:
Jeremy,
Sorry for this being so late, but hopefully the answer will be of use to you in a future project.
The problem here is that IE creates a new stacking order anytime there is an element with position:relative, meaning that z-index itself is not the only controlling factor. You can read more about this here:
http://therealcrisp.xs4all.nl/meuk/IE-zindexbug.html
To solve the problem, if I'm understanding your problem correctly, apply position:relative to the container that wraps your whole autocomplete implementation (and then position:absolute to your results container). That should create an independent stacking order in IE for those elements that allows them to float over the other position:relative stacks that appear later in the page.
Regards,
Eric
The working solution I finally implemented was based on reading this explanation over and over again.
In the underlying HTML, all of the blue rounded corner elements are DIVs, and they're all siblings (all children of the same DIV).
The z-index of the autocomplete div itself (which is the great-great-grandchild of the rounded corner container div) can be arbitrarily high, and it won't fix this issue, because IE was essentially rendering the entire contents of the search box below the entire contents of the "Vital Stats" box, because both had default z-index, and Vital Stats was later in the HTML.
The trick was to give each of these sibling DIVs (the blue rounded corner containers) descending z-indexes, and mark all of them position:relative. So the blue div that contains the search box is z-index:60, the "Vital Stats" box is z-index:50, "Tags" is z-index:40, and so on.
So, more generally, find the common ancestor of both the element that is getting overlapped and the element that is overlapping. On the immediate children of the common ancestor, apply z-indexes in the order you want content to show up.
I'm not totally understanding the setup that's leading to the problem, but you might want to explore the useIFrame property of the YUI Autocomplete object -- it layers an iframe object beneath the autocomplete field, which allows the field to then float above the objects that are obscuring it in IE's buggy layout.
http://developer.yahoo.com/yui/docs/YAHOO.widget.AutoComplete.html#property_useIFrame
But the docs say that this matters in 5.5 < IE < 7, so this might not be the issue you're experiencing. So again, without totally understanding the setup you're working with, you might also want to try to experiment with various z-index values for the autocomplete field and the surrounding block-level elements.
Make sure the z-index of the auto-complete div is a larger number than the divs that constitute the rounded corner box. Microsoft puts the z-index of the top elements to 20000 or 100000 I believe. Might be wise to do the same.
I had a similar problem to this, I fixed it by basically just changing z-index for the different divs. Just setting higher number for each div in the order it should display.