check this page out: http://jsbin.com/itufix with IE (page automatically enables IE7 mode).
Here you'll find examples how inline elements (input and span) are rendered as with display block. All elements margins and padding is set to 0.
If you use Developer tools for IE (IE8-9) you could have noticed that input shows offset: 1.
Can anyone explain what is actually happening and how to fix this?
NOTES
Adding float to input fix this, but this is not an option. I need to get this done without float.
Input/span and its div parents property hasLayout value is true!
Any info related to this bug is welcome.
UPDATE:
Here are more examples of how styles are used: http://jsbin.com/itufix/13. Each field can have description under it, plus the whole div.form-item may float (in case I need more than one field in line)
If you can't float the input (why?) then you could do this:
*+html input {
margin-top: -1px;
margin-bottom: -1px;
}
http://jsbin.com/itufix/5
That's using a CSS hack so the workaround is only applied in IE7.
Looking at your CSS, I see the following:
div.form-item{
padding: 0 1px;
}
Changing this to padding:0; seems to remove all padding on the form fields to my eyes. See:
http://jsbin.com/ojeros/2/
Or am I missing something?
Related
I've come across some IE10 wierdness regarding padding in a right aligned inputfield.
Check this fiddle http://jsfiddle.net/fhWhn/
::-ms-clear, ::-ms-clear{
display: none;
}
This removes the "IE10 icons" but what do I do if I want to keep these and keep my padding?
Is there another, smarter, way of keeping the padding after onblur?
I ran in to this same problem. To get padding back, just set the value of the textbox on blur.
My simple solution:
$("input[type='text']").blur(function (evt){
var $element = $(this);
$element.val($element.val());
});
A possible workaround is to use the style direction: rtl; on your input, which will move the × to the left-hand side of the element. However, the behavior of using right-to-left may not be ideal for your case.
JustinStolle's answer is the best approach, I think.
Example:
input[type="text"].field-al-right{
text-align:right;
direction:rtl;
}
Edit: Eric's solution worked for me and is much nicer, but I'm leaving this answer here in case some future version of IE needs a different fix
New IE, New IE-specific rendering issues...
I've been debugging the same behaviour. The only thing I've found that works so far is:
Removing focus from the input (even explicitly setting the “padding-right” per element has no effect while it has focus)
Setting the padding-right value to a different value to the correct value (setting it to the correct value triggers no change, presumably because the layout system knows the computed CSS value hasn’t changed so decides no re-draw is necessary)
Waiting for a re-draw (instantly – or even after a timeout of 1 or 2 milliseconds - setting the property again to the correct value results in no change, presumably because no re-draw has taken place as per above)
Setting the property to the correct value (e.g. using $this.css("padding-right", ""), which removes any per-element value and allows the computed CSS value to take over).
However this is of course undesirable as it involves removing focus from the input when the user may be in the middle of typing.
have you try adding 'box-sizing' to your css?
* {
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
padding: 0;
margin: 0;
}
I just finished my portfolio site, which is my first attempt with html5 and it looks great in Chrome. But when I tested it in IE and FF, exept IE9, there are some major differences that all occur in the header. I think this is because the header has a fixed position. I did this because of the menu. I created a one pager and if I didn't set the position on fixed, the menu disappeared when you clicked on a menu item.
A second error is that with IE all the images get a blue border, which doesn't appear on Chrome.
And a third error is the font in the header is also different with IE. I used an #font-face font for it.
My HTML and CSs code validates on W3C.
You can find the website at www.nathaliedehertogh.be
Can someone please help me out with this one.
All you need to do is add clear:both to #menu, and border:0 to img.
The blue outline is default in some browsers to show that the images are links.
You need a clear in your header to allow the content to flow as wanted after.
The blue border for IE simply needs a CSS setting:
img {
border: 0;
}
As for the font, some fonts don't read correctly in IE. The error I get is:
#font-face failed OpenType embedding permission check. Permission must be Installable.
You don't have a height defined in your div 'kopregel'.. this is causing an issue since you have elements with heights defined inside it.
NOTE: I see it all broken in FF, stuff is being smooshed to the right.
The problem with your header is you need the clear function in your css.
Here is the new and edited code.
#content, hr {
clear: left;
margin-left: auto;
margin-right: auto;
width: 80%;
}
No issue with fixed positions this is just a common issue, hope this helps let me know!
Another major Difference Chrome vs IE check this out
http://technofizzle.blogspot.in/2013/04/chrome-and-ie-display-image-completely.html
This hadn't hit me until now (and this is not only in webkit browsers). On all texts in like p tags, h1 tags etc... there's an extra space over and below the text.
In chrome I found this:
user agent stylesheet
-webkit-margin-before: 1em;
-webkit-margin-after: 1em;
-webkit-margin-start: 0px;
-webkit-margin-end: 0px;
This makes the alignment wrong in some places. And yes I'm using a reset stylesheet and no padding or margin are added. Pretty much a basic setup. Why is this and how do I solve it?
You can also directly modify those attributes like so:
-webkit-margin-before:0em;
-webkit-margin-after:0em;
Works for me in Chrome/Safari. Hope that helps!
These -webkit-margin(s) are overwritten by margin: 0; padding: 0;. Do not worry about them.
Extra space? Maybe you've set line-height:?
I had the same issue. Displaying correctly in Firefox but not Chrome.
I had a closer look at http://meyerweb.com/eric/tools/css/reset/ and found that I hadn't declared a general line-height for the body tag in my stylesheet. Set it to 1.2 and that recreated the correct layout in both browsers.
Just remove the whitespace between tags e.g.
<p id="one"></p>
<p id="two"></p>
becomes:
<p id="one"></p><p id="two"></p>
I had a same problem. Extra space between menu links. None of the above solutions worked. What worked for me, was negative margin.
Just do something like this:
margin: 0 -2px;
NEW EDIT:
This has nothing to do with -webkit-margins. Most likely your problem occurs with inline elements. This happens because you have spaces or line breaks between your inline elements. To fix this, you have many options:
remove all spaces and line-breaks between inline elements
skip element closing tag - for example </li> (HTML5 does not care)
negative margin (as stated above - problems with IE6/7 - who cares, upgrade ;)
set font-size: 0; to problematic inline element container (has issues with android and if font-sizing with ems)
give up inline and use float (this way you loose text-align:center)
Explained more specifically and examples by CHRIS COYIER
I was having this same problem with my <h3> tag. I tried setting margin:0;, but it didn't work.
I found that I was habitually commenting out lines in my css by using //. I never noticed it because it hadn't caused any problems before. But when I used // in the line before declaring <h3>, it caused the browser to skip the declaration completely. When I traded out // for /**/ I was able to adjust the margin.
Moral of this story: Always use proper commenting syntax!
For me, the picture was:
* {margin:0;padding:0;}
Firefox (FF) and Google Chrome both put 0.67em margins regardless.
FF showed its default margin, but crossed out, but applied it anyway.
GC showed its default margin (-webkit-margin-before...) uncrossed.
I applied
* {margin:0;padding:0; -webkit-margin-before: 0; -webkit-margin-after: 0;}
but to no avail, although GC now showed its default margin crossed.
I found out, that I can apply either
line-height: 0;
or
font-size: 0;
to achieve the desired effect.
This makes sense, if one assumes, that the margin is of the .67em - type.
If anybody could give an explanation, why browsers make our lives miserable by applying a line-height dependent, non-removable margin, i would be really grateful.
For me in Chrome it was some 40px padding-start that was causing this. I did the following that worked:
ul {
-webkit-padding-start: 0em;
}
-webkit-margin-before: 0em;
-webkit-padding-start: 0;
-webkit-margin-after: 0em;
This solved it for me when I was having this exact problem.
In your css file add the following.
* {
-webkit-margin-before: 0em !important;
-webkit-margin-after: 0em !important;
}
'*' selects all css elements and overrides the webkit-margin.
Modern properties
The following properties should be used instead.
margin-block-start: 0;
margin-block-end: 0;
It's very rare to need to use these at all, but the following can be useful to avoid extra space after the last paragraph in a series.
p:last-child
{
margin-block-end: 0;
}
I also found that even in Chrome you can trigger the 'ghost margin' by setting margin to inherit in some cases.
https://developer.mozilla.org/en-US/docs/Web/CSS/margin-block-start
I had the same problem. Suddenly one out of my three table cells containing data its header was moved down a little bit. My problem was simply solved by adding this:
table td
{
vertical-align: top;
}
Seems like some other element in a 'higher' style sheet was telling my data to center itself in the cell, instead of just staying on top.
I guess its just stupid, and wasnt really a problem... but the next person to read this topic might have the same stupid error as i did :)
Take care!
If user agent stylesheet is kicking in, it is because the tag property was not properly defined in your css stylesheet.
Chances are that a typo, forgotten bracket or semicolon is breaking up your stylesheet BEFORE reaching the tag property settings your page later refers to or "needs".
Run your CSS thru error checking, like CSS LINT and fix whichever errors are eventually detected.
I have inserted content using the :before pseudo-element for a class. I was trying to position this content using margin-top but firefox is simply ignoring the property. The code follows:
.bef {
line-height: 2em;
white-space: nowrap;
font-size:24px;
display: block;
}
.bef:before {
display: block;
margin-top:2em;
padding: 0;
color: #666666;
content:"Hello";
}
Does anybody know why Firefox may be ignoring the margin-top property?
EDIT: Although margin-top is being totally ignored, margin-bottom:-Xem is working and I am able to move the :before element around
It appears that Darko Z is right.
http://jquery.nodnod.net/cases/577
Hypothetically, the first two test cases (separated by <hr>) should render identically, which they do in Gecko (via FF3.5/Mac), but Webkit (via Safari4/Mac) renders the :before and :after segments as inline. The third test case seems to imply that Webkit currently requires the triggering element to be block in order for the generated content to be block.
The spec isn't clear on what the correct behavior is. It may be worth raising a question on www-style to see which rendering engine's behavior is correct, then filing a bug with the incorrect rendering engine to get it fixed in future versions. Feel free to use my code as a test case.
try making .bef display block also? just a guess that the containing element of the :before needs to be block so it can listen to the margin-top...
link text
In Safari/Chrome it has extra spacing on the left/top of ol's, blockquotes and other elements.
I can't isolate this, however when I look in the web inspector in Safari, its picking up a margin-left: of 26px on some elements. I have not specified any such rules, so is this a bug in Web inspector?
Can someone enlighten me as to why these exta spacing problems are occurring? Thanks!
That margin-left:26px is the "computed style" of your styling margin-left:2em. Hence why it's under Computed Style section in Safari's Web Inspector.
So if you change your margin-left to some other values the computed-style pixel value will also change too.
Anyway there are indeed extra padding! And it's caused by the user agent stylesheet (-webkit-padding-start:40px). Reset this style by setting padding:0 on your ol and any others elements you want.
A good way to prevent this problem from happening again and develop without worry is to reset your css. A basic reset would be:
* { margin:0; padding:0; }