Difference between CSS in IE and Firefox

1. The difference between CSS parsing in IE and Firefox is that I have some experience in using it. I hope you can continue with it.
High Resolution
IE: the actual height will be used even if the height of the image content is defined based on the height change of the content, including the undefined height of the image content, when the content exceeds the height
Firefox: when no height is defined, if the image content is included in the content, the MF height resolution is based on the printing standard, which will cause a highly inconsistent situation with the actual content; when the height is defined, but the content exceeds the height, the content will exceed the defined height, but the style used in the area will not change, resulting in style dislocation.

Conclusion: If you can determine the content height, you 'd better define the height. If there is no way to define the height, you 'd better not use the border style. Otherwise, the style will be messy!

Analysis of ALT and title of IMG objects
ALT: the prompt when the photo does not exist or the load error occurs;
Title: tip description of the photo.
If title is not defined in IE, ALT can also be used as the IMG tip. However, in MF, the two are completely used according to the standard definition.

Conclusion: when defining IMG objects, you can write both ALT and title objects to ensure that they can be used properly in various browsers.

Other details
When you write CSS, especially when you use float: left (or right) to arrange one-click images, you will find that there is a normal problem in Firefox and IE. No matter whether you use margin: 0 or border: 0 as the constraint, it will not help.

In fact, there is another problem here, that is, the processing of spaces by IE. Firefox ignores the processing of spaces between blocks by IE. That is to say, the end of a div should be followed by a DIV, and there should be no carriage return or space in the middle. Otherwise there may be problems, such as 3px deviation, and this cause is hard to find.

Unfortunately, I encountered this problem again, connecting multiple IMG labels and defining float: left. I hope these images can be connected. However, the results are normal in Firefox, and each IMG displayed in IE is 3 px apart. Deleting spaces between tags does not work.

Later, the solution was to set Li outside IMG and define margin: 0 for Li, which solved the display deviation between IE and Firefox. The explanation of some models by IE may cause many errors. You can only find the cause if you try more.

2. nested Div: the height of the parent Div cannot be automatically changed based on the Child Div.
<Div id = "parent">
<Div id = "content"> </div>
</Div>

When the content is too large, even if the parent is set to a height of 100% or auto, it cannot be automatically stretched in different browsers. Solution

<Div id = "parent">
<Div id = "content"> </div>
<Div style = "Font: 0px/0px sans-serif; clear: Both; display: Block"> </div>
</Div>

A space with a height of 1 is generated at the bottom of the layer to solve this problem.

3. CSS Div learning notes
1. Basically, the DIV of each block must have its own ID to prevent blocks of different functions from using the same ID/class

2. Each relatively large block div is followed by a <! --/Id --> MARK start and end

3. Another method for hiding text: Text-indent:-9999px; line-Height: 0

4. cleverly handle the two parallel columns:
1)
Right column: P, width = 44.5%, float = left
Column P. First, border-Right: # a7a7a7 1px solid, width = 45%
2)
Right column # Right, margin-left: 50%
Left column # Left, float = left, width = 50% border-Right: # a7a7a7 1px solid

The key of the above two methods is to select float = left

5. Randomly switch images:
# Random {
Background: URL (/rotate. php );
}
This method is clever.

4. highly adaptive Div
Today, Xiaoye asked me to solve a problem for his pages, that is, the height self-adaptation of the DIV, that is, embedding one left, one right, two sub-Div in a parent Div, the content of the sub-Div on the right can be infinitely expanded, so that the height of the parent Div can be infinitely lengthened. The general layout method can be used for correct browsing in IE, in Mozilla, the height of the parent div is fixed at around 10 PX, and the height cannot be adaptive. The height: auto cannot be used either. What should I do. I have referenced a document on the Internet. To achieve adaptive height, the DIV layer must have the float attribute. So I started the experiment. If float: left, the DIV ran to the far left of the page, this is easy to do. I set a div on the outside and set the position. Even if the float: Left is not moved.

XHTML:
========================================================== ============================

<Div id = "container_father">
<Div id = "Container">
<Div id = "Panel"> test <br/>
Test <br/>
Test <br/>
<! -- Id = "Panel" -->
</Div>
<Div id = "sidebar">
<Ul>
<Li class = "current"> pre-Installation check </LI>
<Li> Read the PFC authorization protocol. </LI>
<Li> initialize the database </LI>
<Li> complete installation </LI>
</Ul>
<! -- Id = "sidebar" -->
</Div>
<! -- Id = "Container" -->
</Div>
</Div>

CSS
========================================================== ==========
# Container_father {
Margin-left: auto;
Margin-Right: auto;
Padding: 0px;
Width: 750px;
}

# Container {
Width: 750px;
Border: 1px solid # cccccc;
Padding: 8px;
Margin: 0px;
Background-color: # f1f3f5;
Float: left;
}

From: http://www.singki.com/blog

5. In-depth standards ~ The IE doubled float-margin bug (ie Double Floating boundary bug)
What is the fault?

A piece of error-free code places a float: Left element into a container box and uses the Left Border (margin-left) on the floating element) to make it a distance from the left side of the container. It looks quite simple, right? But until it is browsed in IE/win, the border length of the left floating element in the browser is mysteriously doubled!

What should happen?

The following illustration shows a simple Div (a brown box) containing a left-floating Div (a Green Box ). A floating element has a left boundary of PX, which generates a gap of PX between the container box and its left edge. So far, it has been good.

. Floatbox {
Float: left;
Width: 150px;
Height: 150px;
Margin: 5px 0 5px 100px;
/* This last value applies the 100px left margin */
}

Old ie "double occupied"

The same original code is displayed in a slightly different way when viewed in IE/win. The following illustration shows the layout of IE/win.

Why does this happen? Don't ask this silly question! This is IE, remember? Compliance with the standards is just an ideal situation and is not expected to be achieved. This simple fact is being verified.

Key Points

This bug occurs only when the floating boundary and the floating element direction appear between the floating element and the inner edge of the container box at the same time. Any floating element with similar boundary afterwards does not display double boundary. Only the first floating element of a specific floating row will encounter this bug. As in the left-side case, the double border is mysteriously displayed in the same way as the right-side case.

Finally, solution!

Until now (January) this bug has been regarded as unrecoverable. It is usually used to replace the control method of the wrong boundary, for example, the left margin of an invisible floating element, together with an embedded box, the visible box is packed in an invisible floating element; or you can use this technique to set only 1/2 of the boundary for IE/win. This method takes effect, but it is messy and the source code is corrupted. But now it's all over.

Steve clason found a fix. In his guest demo, he fixed the bug of double boundary and text indent. This is a classic ie bug fix. You can use a property to fix bugs that affect unrelated properties.

How to do it now?

Studying it, simply setting {display: inline;} to floating elements is all you need to do! Yes, it sounds too simple, isn't it? However, this is true. Only one display "inline" statement is qualified.

People familiar with the Rules know that floating elements are automatically set to "Block" elements, regardless of what they were. As Steve pointed out from W3C:

9.5.1 positioning the float: The 'float' Property

"This Property specifies whether a box shoshould float to the left, right, or not at all. it may be set for elements that generate boxes that are not absolutely positioned. the values of this property have the following meanings:

Left
The element generates a block box that is floated to the left. content flows on the right side of the box, starting at the top (subject to the 'clear' property ). the 'display' is ignored, unless it has the value 'none '.

Right
Same as 'left', but Content flows on the left side of the box, starting at the top.

None
The box is not floated ."

This indicates that the {display: inline;} on the floating element will be ignored. In fact, no changes are made to all browsers, including IE. However, it somehow causes IE to stop doubling the boundary of floating elements. Therefore, this solution can be applied directly without any tedious hidden methods. If a browser decides to fix the vulnerability in the future, just mount the vulnerability to tan hack, which is dedicated to IE, and the details are like ie Three pixel text-jog demo.

Below are two vivid demos using the same code above. The first bug that shows ie as usual, and the next one uses "inline" to fix floating elements.
. Floatbox {
Float: left;
Width: 150px;
Height: 150px;
Margin: 5px 0 5px 100px;
Display: inline;
}