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.
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.
I have a table with 5 columns, 2 of which have a set width, the other three don't. Different browsers interpret this inconsistently.
Have a look at this fiddle in different browsers to see what I mean.
Firefox and IE9 render it the way I'd think correct: all cells have uniform width of 20% (two have a set width of 20% each, and the remaining 60% is divided between the remaining three cells).
Chrome, Opera, IE7 and IE8 force the empty cells without a set width to have zero width, which in turn forces the other two cells to stretch to 50% width each. Putting content into one of the three empty cells makes them take all available width (60% in case one cell has content, 30% if two, etc.). Likewise, removing the content off one of the two cells that have a set width results in a forced 0 width.
Which browsers got it right and which ones are doing it wrong?
Also, I perused the W3C spec regarding tables, but only found the description of the empty-cells property, which is supposed to control the rendering of empty cells with borders/background, but this does not affect the cells' width. I thought the table-layout property might do the trick, but while setting table-layout:fixed in Chrome does make all the columns appear, there is no way (or at least I don't see one) to do the opposite in Firefox. If you could elaborate on this and/or point me to the correct section of the W3C spec that covers this, I would really appreciate it.
The problem arises as the W3C haven't seemed to cover it yet, they haven't suggested any "right" way of dealing with this situation. The browsers have the liberty to interpret it the way they wish, in my opinion is the way IE9 and Firefox do it.
IMHO all the browsers are displaying things RIGHT. As a developer we should understand that what we expect from the empty cells. It is always better to define width or add some spaces even if your cell is going to be empty to achieve consistent display across all browsers.
put inside the "empty" <td>
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.
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.