Let’s take an example: the code is very simple, as follows:
In this way, a table with two rows and two columns will not display any errors in any browser. But if I add the following css, the situation is different:
It seems that there is going to be a problem, but don’t worry, in fact, you can’t see any problems on the surface at this time, and the page layout will definitely not be messed up,
You can't see anything overlapping.
I never wanted to fool you, although there is no problem on the surface, but now let our ie develop tool come into play, it will tell us the layout What did it bring?
Pay attention to the differences and similarities in the two pictures. Note the blue line circle in the left view Something, the function of this tool is to click on an element on the right side and it will be framed with a wireframe in the web page.
But note that I clicked two different elements twice. The wireframe framed the same place. Sweat, I read it right.
Yes, that is to say, the two tr overlap, but the strange thing is that the elements in tr are rendered completely correctly without affecting any appearance style. Don't think this is safe. The hidden danger is buried at this time.
I actually encountered this problem when making a simulation window. I used a two-row table. The first row is the window title bar, which can be dragged, and the second row is Make the main view, but later I found that the second row of the table covered the first row. Although it looked normal, the title bar was blocked and could not be clicked and dragged.
To fix this phenomenon, Just remove the position in tr
3. From this point of view:
I don’t know if you use some reset when writing css. Anyway, this is what I do, the css in my NetBeans The reset is stored in the template, and there will be a paragraph like this in the header of each css file:
/*
TODO customize this sample style
Syntax recommendation http://www.w3.org/TR/REC-CSS2/
*/
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center ,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin : 0;
padding: 0;
border: 0;
outline: 0;
font-size: 12px;
vertical-align: baseline;
background: transparent;
}
body {
line-height: 1;
}
ol, ul {
list-style: none;
}
blockquote, q {
quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: none;
}
/* The style when the element gets focus! */
:focus {
outline: 0;
}
/* The style of special text! */
ins {
text-decoration: none;
}
del {
text-decoration: line-through;
}
/* thin line table style*/
table {
border-collapse: collapse ;
border-spacing: 0;
}
Everyone knows that if you want to absolutely position an element, you must first position its parent element, for example, set a position: relative so that the child element can be absolute, and then position top and left.
So I I thought, this is too troublesome, I might as well set position:relative for all elements, and then change position:absolute for absolute positioning. This way, I don’t have to set them one by one, and all elements can be absolutely positioned.
So the problem mentioned in this article comes. We set position:relative for all elements, so there is a problem with the table, so this approach is not advisable, and it will cause some other rendering problems. I remember that I saw prompts in several places saying that this setting cannot be done.
This article is actually about layout, but this problem is indeed a bug in IE, not a layout problem. I will encounter layout next time Let’s talk about layout. By the way, this is really a strange bug.