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.
Related
I had some problems with vertical spacing in Firefox and IE for an embarrassingly long time.
I am using a * selector in my css to apply margins to everything within a certain container element. Works fine in Chrome, however in FF and IE I was getting mysterious extra padding seemingly coming from nowhere, as you can observe here: http://jsfiddle.net/XrVXF/3/.
It turns out I had two separate problems. One is that non-Chrome browsers will select elements with the * selector and apply the margins and the margins show up in the browser! even though the element is invisible to things like Firebug. Should this be considered a bug? You may be asking what business is a link element doing inside the body tag. Well I could probably avoid it but it is the easiest way to do some things on my site. This page says that the * selector should only apply to block level elements in HTML5, which I am using, so in that sense it seems to me that Firefox at least is bugging out, and IE too if they are supposed to have proper HTML5 support yet. Now that I know this I can work around it but maybe there are other elements I should worry about too? (Doesn't seem to apply to script or style tags.) Would I be better off applying margins to a large list of html elements instead of *?
The other weird thing, which you can observe in the fiddle I linked is that the clearfix on the bottom (which is not necessary in the example, but is on my site) also picks up the margins and applies them in FF and IE but not in Chrome. Which is the 'right' behaviour? Strangely, I noticed that turning off overflow:hidden, prevents the clearfix from taking up space, and doesn't seem to have any detrimental effect on my site. What is overflow set to hidden for?
Correction: Oops, I was using .clear when I meant to be using .clearfix (which appends content after your floated stuff), which seems to work fine and doesn't have margin issues.
Should this be considered a bug?
Considering you're applying styles to elements that are in places that they shouldn't be in the first place (link in body???), this is anybody's guess. The likely reason why they don't show up in Firebug is because Firebug isn't expecting them to be there.
In all seriousness, my best guess as to what's going on in your fiddle is:
Chrome has a UA style for link elements to display: none. I imagine it does the same for any other elements that belong in the head element and not body.
Other browsers have no default display style for link elements, instead relying on head to have display: none to hide everything that belongs in the head element as well. So when you place a link within body, it shows up with the margins because it's showing up with the initial value of display: inline.
FWIW, if you give it a style of display: block, its margins will collapse and it'll have the same apparent effect as if it had display: none as in Chrome.
Again, this is based on invalid markup in your fiddle, so I can't say which browser, if any, is right or wrong since all the spec says is that the page head should not be rendered. Also, cue arguments/debates on whether this is a reason not to use the * selector, or a reason not to write invalid HTML, or both...
If you look at this code: http://jsfiddle.net/b3KaM/2/
in IE7 the <a> tags do not stretch to their parent <li> width even if display: block; is set. You can see the difference with the background color set to red on the list items and yellow on the links.
it obviously work fine in FF/Chrome & friends.
EDIT:
the complication here is that I cannot set a fixed width - the link text should stay on one line and the whole list should expand as needed.
I'm aware that this as been asked before and I've found a few questions on SO but I could not find a valid solution to this issue - any ideas anyone?
If not - is it safe to say that is not possible to achieve the same result on IE7 as on other browsers, i.e. it's an Internet Explorer bug with no workaround?
This problem is caused by a rendering phenomenon in IE7 and lower known as hasLayout.
To fix the problem, you must simply prevent your a elements from "gaining layout".
Unfortunately, there's massive list of stuff that causes an element to "gain layout".
Your a elements currently have overflow: hidden and min-height set. If you remove those properties, it will work in IE7.
With block you have to give the width also for the element.For example:- http://jsfiddle.net/b3KaM/8/
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.
All the documentation I can find suggests that almost standards mode differs from standards mode only in the way images in table cells are aligned.
This question : Internet Explorer 8 and Checkbox CSS Problem, however indicates that the rendering in IE8 and Opera changed between the two modes, based on how checkboxes are interpreted. Certainly there are neither tables nor images on that page.
So, does anyone know of other differences between these two modes?
Yes, it removes baseline under inline images which are only child of their containers.
MDC reference.
The original almost standards mode only affected images in tables. Other browsers adopting the mode may of course have put other differences in it.
Form fields, and especially checkboxes, are tricky. The standards doesn't really cover how they should be rendered, so it's still pretty much up to the browser to make something reasonable out of it. Checkboxes are inline elements just like images, so some browsers may very well handle them similar to images.
This Microsoft article explains the difference and covers both the common case of images and baselines, as well as the behaviour of checkboxes that prompted this question:
http://msdn.microsoft.com/en-us/library/ff405794%28v=vs.85%29
It says that for Almost Standards mode:
Inline elements contribute to line height if and only if one of the
following is true.
If the element:
Contains text characters
Has a nonzero border width
Has a nonzero margin
Has a nonzero padding
Has a background image
Has vertical-align set to a value other than baseline
Note that a line break is not considered a text character for this
definition unless it is the only content of a line box. In that case,
the line box height remains the uppermost inline box top and the
lowermost inline box bottom on the line, regardless of the specified
line height.
If an img element is the sole content of a table cell, the line box
height of the cell line box height is adjusted to zero.
For example I have a situation where I have something like this (contrived) example:
<div id="outer" style="margin: auto>
<div id="inner1" style="float: left">content</div>
<div id="inner2" style="float: left">content</div>
<div id="inner3" style="float: left">content</div>
<br style="clear: both"/>
</div>
where there are no widths set on any elements, and what I want is #inner1, #inner2 and #inner3 to appear next to each other horizontally inside #outer but what is happening is that #inner1 and #inner2 are appearing next to each other and then #inner3 is wrapping on to the next line.
In the actual page where this is happening there is a lot more going on, but I have inspected all of the elements very carefully with Firebug and do not understand why the #inner3 element is not appearing on the same line as #inner1 and #inner2 and causing #outer to get wider.
So, my question is: Is there any way to determine why the browser is sizing #outer the way it is, or why it is choosing to wrap #inner3 even though there is plenty of room to put it on the previous "line"? Baring specific solutions to this problem, what tips or techniques do you hardcore HTML/CSS/Web UI guys have for a poor back end developer who has found himself working on the front end?
It would be nice to have a tool that could tell you exactly what all your layout problems are, but in this case the browser rendered the page exactly how it should have -- the combined width of the floats exceeded the width of the containing block, so the last one drops to a new line (this is slightly different than the IE6 expanding box/float drop problem which is typically caused by content inside the float, not the floats themselves). So in this case, there was nothing wrong with your page.
Debugging this is simply a matter of walking through your HTML in Firebug and figuring out which children of a block is exceeding the block's width. Firebug provides plenty of information for this purpose, although sometimes I need to use a calculator. I think what you described about being able to see which elements constrain other elements would simply be too complex and overwhelming, especially for elements that are removed from normal flow (such as floats or positioned elements).
Also, a deeper understanding of how CSS layout helps a lot as well. It can get pretty complicated.
For example, it is generally recommended to assign explicit widths to floated elements -- the W3C CSS2 spec states that floats need to have an explicit width, and does not provide instructions of what to do without it. I think most modern browsers use the "shrink to fit" method, and will constrain themselves to the width of the content. However, this is not guaranteed in older browsers, and in something like a 3-column layout, you'll be at the mercy of at the width of content inside the floats.
Also, if you're striving for IE6 compatibility, there are a number of float related bugs that could also cause similar problems.
Try the Web Developer Plugin for Firefox. Specifically, the Information -> Display Block Size and Outline -> Outline Block Level Elements options. This will allow to see the borders of your elements, and their size as Firefox sees them.
In Firebug's CSS tab, you can see what style rules apply to a selected elements in the cascading order. This may or may not help you in your problem.
My guess would be that something about the content of #inner3 is causing it to wrap below the first line, and the #outer is just getting sized to accommodate the smaller needed space.
So I found the answer in my specific case -- there was a div much further up in the DOM that had specific left/right margins set which compressed it and everything in it.
But the heart of the question is really how can you easily debug this sort of issue? What would be perfect in this case for example would be something in Firebug that, when hovering over an element's size in the layout panel would display a tool tip that says something like "width constrained by outer element X; height constrained by style Z on element Q" or "width contributed to by inner elements A, B and C".
I wish I had the time to write something like this, although I suspect it would be difficult (if not impossible) to get that information out of Firefox's rendering engine.