I'm running into an issue in desktop Safari (haven't checked mobile) where the top part of an input element's content is being cut off. There is no padding on the parent element and the styles render correctly in other browsers.
I believe the issue is due to a shadow div element that Safari has added that is the direct child of the input, as the calculated style for this shadow div has font-size 12px, while the actual size of the font specified on the input is 16px. When I type, the cursor has height 12px.
I'm not able to target the shadow div to overwrite the font-size. Any styles I try to apply are ignored. Any idea what this shadow element uses to calculate its styles, or how I can target would be greatly appreciated. Thanks!!
UPDATE: Happily, a simple solution. Applying a line-height to the input element solved the issue.
Interestingly, on both my branch with this bug and another branch without it, the value returned by getComputedStyle() for lineHeight was the same: 'normal'. I suppose it helps to be explicit with CSS. Hope this helps someone else.
Related
I've got a scenario where focus outlines are not being represented correctly in Internet Explorer 10 when focus is given to an a element.
Nested inside each a element is a series of div elements and within the lowest-level div is an img element.
When I tab to each a element (via IE10), focus outlines show up offset to the right of the group of a elements. When I view the page in Chrome, focus outlines show up perfectly.
I've been able to reproduce this in a JSFiddle.
CSS is bloated with styles from the existing project I'm having the issue in.
You haven't adjusted the display property for your a elements, so they're still displaying inline, even though they're "containing" block-level div elements. The result is in accordance with this section of the CSS2.1 spec which has a description on how inlines containing block children should behave.
None of the browsers are automatically adjusting the display modes, but what Chrome appears to be doing is guessing the location of its default outline and drawing it according to its best guess. The really weird thing about this, though, is that it doesn't always do this. The moment you adjust the outline style, the outline behavior immediately reverts to something similar to what you see on other browsers:
a:focus{
outline-style: dashed;
}
Unfortunately, because outline rendering is poorly defined, it's not possible to judge if any of the browsers are buggy in this aspect. And although HTML5 explicitly allows a elements to contain most any other element, it does not state how their display mode should be adjusted, if at all, so it looks like browsers just don't do anything about it. The main issue here, though, is with outlines.
The easy solution to the original problem is of course to set the display style of your a elements explicitly to something other than the default inline. This will at the very least improve outline rendering by making it more predictable. You may or may not wish to move the styles for your div elements to your a elements instead as well, depending on what sort of role those divs play in your layout and whether they are necessary. As it is, most of the styles that you do have on a aren't actually taking effect because of what I've described from the spec.
In all major browsers: as the question states, a parent <div> container (whose height is not set) over-sizes its height to fit a child <img> element (for instance, a 300-pixel tall image that is the only thing inside the div). The over-sizing is usually about 3 to 5 pixels, and appears at first as img margin-bottom or div padding-bottom might look.
However, using absolute positioning, it is clearly demonstrated that the bottom of the div is below the bottom of the imgby a few pixels. It might not ruin a website's design, but it is a hurdle to overcome in certain situations. I have made a fairly detailed fiddle demonstrating this issue here.
Why is this standard practice in web browsers?
Is this meant to compensate for something? It seems unnecessary.
Is this a bug, or a soon-to-be antiquated feature?
EDIT: Thanks to the answerers/commentators below, I know the reason is that an <img> is treated by default as CSS
display:inline which preserves whitespace around the element.
Changing it to display:block completely fixes the problem by
eliminating whitespace around the element.
Notes: This over-sizing can be averted by giving the image child element a CSS property of float:left or float:right, etc., but this is a workaround, and as such is not the answer to the question. One reason this can be problematic is if you already have other float elements layered in front of the div child image (float overlap not allowed Firefox, Opera, IE. float overlapping only seems allowed in Chrome and Safari using CSS position settings). Thanks!
Add display:block to your image. I think that will fix the problem.
This little fiddle shows the problem I'm having.
The login form on the right looks fine under firefox (And even IE6) but when viewed in IE7+ or chrome/chromium there is a size difference.
This isn't an actual size difference, but an illusion created by some of the inputs becoming positioned lower than the others, and the overflow on the div cutting them off.
I thought it could be some invisible value such as firefoxes dotted lines but setting outline: none doesn't work either.
I've been debugging this all day and I don't know why it's not working.
Edit: Screenshot
Replace height with line-height.
http://jsfiddle.net/gnxRG/1/
Apparently vertical-align applies to the object relative to it's parent, not the objects children relative to the object. Setting vertical-align on the inputs to top fixes the problem (But I still don't know what caused it in the first place, odd)
http://jsfiddle.net/gnxRG/2/
I would like to understand CSS more and now I have an example that renders differently in two browsers and in a program called "explorer". Here is the link to the example page that I tried to clean from any disturbing details: http://csaladterapia.hu/example.html
In the latest Firefox version the image is placed inside the fieldset because it is float:right and the other elements are clear:none. In Chrome and IE the image is placed above the fieldset.
Could you help me understanding the difference?
The interpretation of Firefox is wrong, and even very strange. Floating an element should never place the element on top of other elements - it just takes them out of the document flow, puts them to the left/right on the current line. If the element following the float is not too wide, and has no 'clear' property, it will be placed on the same line.
In your example the following element is the div, which defaults to 100% width, so it can't be placed on the same line.
What Firefox is doing is very strange - even clear:left on the following element has no effect.
Reference:
http://coding.smashingmagazine.com/2007/05/01/css-float-theory-things-you-should-know/
This is a strange one, and i'm not sure what the correct behavior is here. It is due to the width of the fieldset being 95%. Removing this width attribute shows the same behavior in Firefox and Chrome.
If you want the image to appear in the fieldset then move the image to be the first element after the legend, this way you should see consistent behavior in all browsers.
Firefox tries to honor the width of this whilst maintaining the float but it seems Chrome wants to move the fieldset onto a new line due to being block and 95% width.
In this case you can change the mark-up as mentioned.
While I was debugging an issue in my GWT project, I noticed that when I moused over an element, I saw its size in a tooltip and a shaded region indicating its size and position in the screen. However, when selecting that element and viewing its "computed style" attributes, I notice that the width is the same, but the height differs from the tooltip (it is zero).
This makes me wonder: what is the size that Chrome is displaying in the tooltip? Why is it nonzero when the computed style is zero?
Also, the "metrics" region that shows the box model for the element displays a size with a height of zero.
Here is an image about what I am talking about:
http://img845.imageshack.us/img845/1766/96984162.png
It's possible that you have an error with your doctype -- this can cause elements to render with an abnormal box model. Tried running your markup through W3C validation? Is there any code that appears before your doctype?
I came across this problem a while back when I accidentally left a print_r() at the beginning of my code.
The tooltip displays the effective offsetWidth/offsetHeight for the inspected element, while the Computed Style displays... well, computed style values for the element. WebKit erroneously returns "0px" instead of "auto" for "display: inline" elements. I guess it still holds for your "display: table-cell" element.