Reprint: On Have layout_css/html

Translator Note: A very good article, a long time ago in the blog on the recommendation, these two days intermittent spent a little time to translate a bit, recommended to read. The English text is here.

All of the layout of the word has not been translated, the word itself is more than the meaning of the words, turned into what all feel awkward, and secondly it is also a proprietary attribute, so just a little bit. The level is limited, many places are vague to paraphrase, found the mistake welcome message to point out.

Quote a comment from Dean Edwards:

I recommend that every the CSS designer and DOM scripter read this. Understanding "Layout" gives a huge insight into lots of the other IE bugs and idiosyncrasies.

(Dean Edwards)

Introduced

There are many strange rendering problems in Internet Explorer that can be solved by giving them "layout". John Gallant and Holly Bergevin classify these issues as "size bugs (Dimensional bugs)", meaning that these bugs can be resolved by assigning a certain width or height to the corresponding element. This leads to a question about "layout": why does it change the rendering characteristics of an element, and why does it affect the relationship between elements? The question was very good, but it was difficult to answer. In this article, we focus on the performance of those aspects of this complex problem, and the specific discussion and examples in a particular context are referenced in the relevant links.

haslayout-definition

"Layout" is a ie/win private concept that determines how an element displays and constrains what it contains, how it interacts with other elements, how it responds and passes application events/user events, and so on, which is somewhat similar to the concept of a form.

Microsoft developers think that box-type elements should have a "property" (which is a concept in object-oriented programming), so they use layout , that is hasLayout .

　　hasLayoutIn fact, is not a property is not a behavior, but IE this rendering engine generation inheritance has always been a rendering concept, the concept of rendering elements will have a feature.

In fact, this rendering feature is inherent in some HTML elements, and in other elements it can be triggered by some CSS properties true , and once the trigger is irreversible.

Terms

When we say that an element "has layout" or "Get Layout", or an element "has layout", we mean that its Microsoft proprietary properties hasLayout are set true . A "layout element" can be an element that has layout by default or an element that gets layout by setting some CSS properties.

The "No layout element" refers to an element that is not triggered by the haslayout, such as a clean div element that is not set to a wide and high size, and can be used as a "no layout ancestor".

The way to assign layout to an element that does not have layout by default includes setting the hasLayout = true CSS properties that can be triggered. Refer to the default layout elements and the list of these properties. There is no way to set the hasLayout = false CSS properties to be removed unless you start those triggers hasLayout = true .

All sorts of problems

　　hasLayoutQuestion whether the designer or programmer may have encountered the problem, both novice and veteran. Elements with layout often have unusual and unpredictable display effects, and sometimes even implicate their child elements.

Whether an element has "layout" may cause some of the following problems:

• IE a lot of common floating bugs.
• The element itself has an exception-handling problem with some basic attributes.
• Margin overlap (margin collapsing) problem between the container and its descendants.
• Many problems with using the list.
• The problem of positioning deviation of background image.
• There is an issue of handling inconsistencies between browsers that are encountered when using scripts.

The list above is just a ballpark and not perfect. The following article will be as detailed as possible to describe the "layout" of the various problems brought about.

Where does Layout come from

Unlike standard properties, and unlike some browser's private CSS properties, layout cannot be set directly by a CSS declaration . In other words, there is no "layout property", the element itself automatically has layout, or with some CSS declaration to quietly get layout.

Default layout element

The following elements should have layout by default:

• ,
• , ,

  ,

  , , , , &lt;embed&gt;, &lt;object&gt;, &lt;/CODE&gt; &lt;LI&gt;&lt;CODE&gt;&lt;marquee&gt;&lt;/CODE&gt; &lt;/li&gt;&lt;/ Ul&gt;<p id=prop&gt; Properties &lt;/H5&gt;&lt;P&gt; The following CSS properties and values will let an element get Layout:&lt;/p&gt;&lt;dl&gt;&lt;dt&gt;&lt;code &gt;position:absolute&lt;/CODE&gt; &lt;DD&gt; the inclusion block of an absolutely positioned element (containing block) is often problematic in this regard. &lt;DT&gt;&lt;CODE&gt;float:left|right&lt;/CODE&gt; &lt;DD&gt; The floating model has a lot of weird performance due to the features of the layout element. &lt;DT&gt;&lt;CODE&gt;display:inline-block&lt;/CODE&gt; &lt;DD&gt; when an inline-level element requires layout, it is often used, which may also be the CSS Property's unique effect--let an element have layout. "Inline-block behavior" is achievable in IE, but very different: Ie/win:inline-block and haslayout. &lt;dt&gt;&lt;code&gt;width: Any value &lt;/CODE&gt; &lt;DD&gt; when many people encounter layout-related problems, they will usually try to fix them first. &lt;dt&gt;&lt;code&gt;height: Any value &lt;/CODE&gt; &lt;dd&gt;height:1% is used in Holly Hack. &lt;dt&gt;&lt;code&gt;zoom: Any value &lt;/CODE&gt; (MSDN) &lt;dd&gt;ms proprietary attribute, cannot pass the checksum. However &lt;CODE&gt;zoom:1&lt;/CODE&gt; can be used as a temporary debugging. &lt;DT&gt;&lt;CODE&gt;writing-mode:tb-rl&lt;/CODE&gt; (MSDN) &lt;dd&gt;ms proprietary genusCannot pass the checksum. &lt;/DD&gt;&lt;/DL&gt;&lt;P&gt; in IE7, overflow also becomes a layout trigger:&lt;/p&gt;&lt;dl&gt;&lt;dt&gt;&lt;code&gt; Overflow:hidden|scroll|auto&lt;/code&gt; &lt;DD&gt; This property has no function to trigger layout in previous versions of IE. &lt;DT&gt;&lt;CODE&gt;overflow-x|-y:hidden|scroll|auto&lt;/CODE&gt; &lt;dd&gt;overflow-x and Overflow-y are properties in the CSS3 box model and has not been widely supported by the browser. They do not have the ability to trigger layout in previous versions of IE. &lt;/DD&gt;&lt;/DL&gt;&lt;P&gt; another IE7 on the screen added a few haslayout actors, if only from haslayout this aspect, Min/max and width/height performance similar, posit Ion's fixed and absolute are identical. &lt;/P&gt;&lt;DL&gt;&lt;DT&gt;&lt;CODE&gt;position:fixed&lt;/CODE&gt; &lt;dd&gt;./. &lt;dt&gt;&lt;code&gt;min-width: Any value &lt;/CODE&gt; &lt;DD&gt; even set to 0 allows the element to be layout. &lt;dt&gt;&lt;code&gt;max-width: Any value other than none &lt;/CODE&gt; &lt;dd&gt;./. &lt;dt&gt;&lt;code&gt;min-height: Any value &lt;/CODE&gt; &lt;DD&gt; even set to 0 allows the element to be haslayout=true &lt;DT&gt;&lt;CODE&gt; Max-height: Any value other than none &lt;/CODE&gt; &lt;dd&gt;./. &lt;/DD&gt;&lt;/DL&gt;&lt;P&gt; above conclusion with the help of IE Developer Toobar and pre-test. &lt;/p&gt;&amp;lT H5 id=inline&gt; about inline-level elements &lt;/H5&gt;&lt;P&gt; for inline elements, such as &lt;CODE&gt;span&lt;/CODE&gt; elements, which can be inline by default, or they can be &lt;CODE&gt; Elements of Display:inline&lt;/code&gt;) &lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;CODE&gt;width&lt;/CODE&gt; and &lt;code&gt;height &lt;/CODE&gt; triggers &lt;CODE&gt;hasLayout&lt;/CODE&gt; only under ie5.x and IE6 quirks mode. Because in IE6, if the browser is running in standard compatibility mode, the inline element ignores the width or Height property, so setting width or height cannot order the element to have layout in this case. &lt;LI&gt;&lt;CODE&gt;zoom&lt;/CODE&gt; can always trigger &lt;code&gt;haslayout&lt;/code&amp;gt, but is not supported in IE5.0. &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; the element with "layout" if it is also &lt;CODE&gt;display:inline&lt;/CODE&gt;, then its behavior is the same as the standard Inline-block is very similar: in the paragraph as normal text in the horizontal and continuous arrangement, affected by vertical-align, and size can be adjusted according to the content of the adaptive. This can also explain why inline elements in Ie/win alone can contain block-level elements that are less problematic because &lt;CODE&gt;display:inline&lt;/CODE&gt; is inline in other browsers, unlike Ie/win once inline elements have Layout will also become inline-block. &lt;/p&gt;<p id=haslayoutprop&gt; Script Properties Haslayout</p&gt;&lt;p&gt; We call this haslayout "script properties" to be distinguished from the CSS properties we know well. &lt;/P&gt;&lt;P&gt; Note Once an element has layout, there is no way to set it to &amp;LT Code&gt;haslayout = false&lt;/code&gt;. &lt;/P&gt;&lt;P&gt; Haslayout-property can be used to detect whether an element has layout: For example, if its &lt;CODE&gt;id&lt;/CODE&gt; is "Eid", then as long as the Enter &lt;code Class=c1&gt;javascript:alert (eid.currentStyle.hasLayout) &lt;/CODE&gt; in the ie5.5+ address bar to detect its status. &lt;/P&gt;&lt;P&gt; IE's Developer Toolbar can check the current style of an element in real time; if &lt;CODE&gt;hasLayout&lt;/CODE&gt; is true, its value is displayed as "1". We can trigger &lt;CODE&gt;hasLayout&lt;/CODE&gt; for debugging by modifying the properties of an element in real time to set Zoom (CSS) to "1". &lt;/P&gt;&lt;P&gt; Another thing to note is that "layout" affects script programming. If an element does not have "layout", then &lt;CODE&gt;clientWidth&lt;/CODE&gt;/&lt;CODE&gt;clientHeight&lt;/CODE&gt; always returns 0. This will confuse some novice scripting, and this is not the same as the way Mozilla browsers handle it. But we can use this to detect "layout" in IE5.0: if &lt;CODE&gt;clientWidth&lt;/CODE&gt; is 0 then this element has no layout. &lt;/p&gt;<p id=hack&gt;css hacks</p&gt;&lt;p&gt; The following hack for triggering &lt;CODE&gt;haslayout&lt;/CODE&gt; has been IE6 And the following versions of the test. Future versions of IE are likely to be treated differently. If the new version of the browser is published, we will reorganize this part of the content. &lt;/P&gt;&lt;P&gt; John Gallant and Holly Bergevin released in 2003 Holly hack: &lt;/p&gt;&lt;pre class=code&gt;/* \*/* html. gainlayout {height:1%;} /* */&lt;/pre&gt;&lt;ul&gt;&lt;li&gt; can let any element of ie5+ get layout, in addition to inline elements in standard compatibility mode IE6. &lt;LI&gt; is generally very effective, except in some rare cases, the need to use height:0 Or 1px a little better. &lt;LI&gt; and &lt;CODE&gt;overflow:hidden&lt;/CODE&gt; are incompatible unless in IE6 's label compatibility mode (because if the parent element is not set high, then &lt;code&gt;height:1% &lt;/CODE&gt; will be changed back to &lt;CODE&gt;height:auto&lt;/CODE&gt;). &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; or we can use underscore hack:&lt;/p&gt;&lt;pre class=code&gt;.gainlayout {_height:0;} &lt;/PRE&gt;&lt;P&gt; In addition, a more backward-compatible approach is to use conditional annotations (conditional comments): &lt;/p&gt;&lt;pre class=code&gt;&lt;!--[if LTE IE 6]&gt;&lt;style&gt;.gainlayout {height:1px;} &lt;/style&gt;&lt;! It is also a safe and effective way for [endif]--&gt;&lt;/pre&gt;&lt;p&gt; to link an external stylesheet file that is specifically modified for Ie/win in conditional comments: &lt;/p&gt;&lt;pre Class=code &gt;&lt;link rel= "stylesheet" href= "Allbrowsers.css" type= "text/css"/&gt;&lt;!--[if LTE IE 6]&gt;&lt;link rel= Stylesheet "href=" Iefix.css "type=" Text/css "/&gt;&lt;! [endif]--&gt;&lt;/pre&gt;&lt;p&gt; We are more inclined to use &lt;code&gt;height:0&lt;/code&gt; and &lt;code&gt;1px&lt;/code&gt;--and advocates always use &lt;CODE&gt;height&lt;/CODE&gt; unless it conflicts with something else (&lt;CODE&gt; overflow:hidden&lt;/code&gt;). For values, we tend to avoid &lt;CODE&gt;1%&lt;/CODE&gt;, as it may (albeit rarely) cause some problems. &lt;/P&gt;&lt;P&gt; one of the things to be aware of is that if we want an element to remain inline, then we can't use &lt;CODE&gt;height&lt;/CODE&gt;, and then we can use &lt;code&gt;display: Inline-block&lt;/code&gt;. We only use &lt;CODE&gt;zoom:1&lt;/CODE&gt; to avoid some rendering errors during the early commissioning phase. &lt;/P&gt;&lt;P&gt; we have seen some of the Holly hack really as holy (sacred) hack blindly use, such as the use of floating elements or for elements that already have a specific width to use this hack. Remember that the purpose of this hack is not to add a height to an element, but to trigger &lt;code&gt;haslayout = true&lt;/code&gt;. &lt;/P&gt;&lt;P&gt; do not set layout:&lt;code&gt;* {_height:1px for all elements;} &lt;/CODE&gt;. The so-called overkill, get layout does not mean to get a panacea, it is only used to change the rendering mode. &lt;/p&gt;<p Id=hackmanagement&gt;hack finishing &lt;/H5&gt;&lt;P&gt; But the browser will always change, we need to face a lot of problems, such as some rely on IE6 bugs do hack will be in IE7 Or a later version of the new browser due to bug fixes (or even harmful) problems, such as the new version of the browser similar layout bug still exists but for hack filter such as &lt;code&gt;* html&lt;/code&gt; does not work properly. In this case, the MS proprietary properties &lt;CODE&gt;zoom&lt;/CODE&gt; can be considered for use. &lt;/P&gt;&lt;pre class=code&gt;&lt;!--[if LT ie 7]&gt;&lt;style&gt;/* ie 6 + IE5.5 + IE5.0 style */.gainlayout {height:0;} &lt;/style&gt;&lt;! [endif]--&gt;&lt;!--[If IE 7]&gt;&lt;style&gt;.gainlayout {zoom:1;} /* or anything else that may be needed later */&lt;/style&gt;&lt;! [endif]--&gt;&lt;/pre&gt;&lt;ul&gt;&lt;li&gt;&lt;code&gt;zoom:1;&lt;/code&gt; can let any element of IE5.5+ (including inline elements) get layout, However, it is not valid in IE5.0. &lt;LI&gt; no other side effects (inline elements become inline-block, of course). &lt;LI&gt; If you need to pass validation, you should use conditional comments to hide &lt;CODE&gt;zoom&lt;/CODE&gt;. &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; in fact, when we consider "backwards compatibility" is very contradictory, we strongly recommend that the page designer back to look at their own pages with the obvious or not obvious "hacks", Use conditional annotations to re-process against different browsers to be foolproof. &lt;/p&gt;<p id=iemac&gt; about IE mac small problem &lt;/H4&gt;&lt;P&gt; ie mac and Windows IE is a completely different two things, they have their own rendering engine, IE Mac is completely I do not know "haslayout" (or contenteditable) so-called What. In contrast, IE Mac render engine to be more standard compatible point, such as &lt;CODE&gt;height&lt;/CODE&gt; is treated as &lt;CODE&gt;height&lt;/CODE&gt;, no other effect. So hacks and other solutions for "haslayout" (especially by using &lt;CODE&gt;height&lt;/CODE&gt; or &lt;CODE&gt;width&lt;/CODE&gt; properties) tend to be for IE Mac is harmful, so it needs to be hidden from it. More about IE Mac related issues can be found in IE Mac, bugs and oddities pages. &lt;/p&gt;<p ID=DOCU&amp;GT;MSDN Documentation &lt;/H4&gt;&lt;P&gt; MSDN There are few places to haslayout this MS attribute, and there are few specific explanations for the relationship between layout and IE rendering models and less. &lt;/P&gt;&lt;P&gt; in IE4, almost all elements have some kind of layout (MSDN), except that they do not have an absolute positioning or a wide, high inline element. In this early layout concept, like &lt;code&gt;border, margin, padding&lt;/code&gt; these properties are called "Layout properties" and they cannot be applied to a simple inline element. In other words, "have layout" can be roughly understood as: "Can have these several properties." &lt;/P&gt;&lt;P&gt; still uses the Layout property on MSDN, but the meaning is changed, and they have nothing to do with the elements that have layout. This proprietary attribute of MS has been introduced in IE5.5 &lt;code&gt;haslayout&lt;/code&gt; it's just some sort of internal sign. &lt;/P&gt;&lt;P&gt; in IE5.5, MSHTML Editing Platform (that is, you can set &lt;code&gt;&lt;body Contenteditable=true&gt;&lt;/code &gt; To allow users to edit, drag, and resize the layout elements in real-time, as well as describe three important features related to layout: &lt;/p&gt;&lt;blockquote title= "from the MSDN specification: Editing Platform "cite=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmshtml/html/ mshtmleditplatf.asp&gt;&lt;p&gt; If there is content in a layout element, the layout of the content is determined by its bounding rectangle. &lt;/P&gt;&lt;P&gt; Having layout means basically representing an element.is a rectangle. &lt;/P&gt;&lt;P&gt; internally, having layout means that an element is responsible for drawing its internal content. &lt;/p&gt;&lt;/blockquote&gt;&lt;p class=blockquotesource&gt; (Editing Platform) &lt;/P&gt;&lt;P&gt; and layout The internal work mechanism itself was not documented until August 2005, when Markus Mielke [MSFT] opened the door to further discussion due to the WEB standards Project and Microsoft's Special working Group:&lt;/p&gt; &lt;blockquote title= "from the MSDN Specification: Filters and Transitions" cite=http://msdn.microsoft.com/library/default.asp?url=/ Library/en-us/ietechcol/cols/dnexpie/expie20050831.asp&gt;&lt;p&gt; in general, in the DHTML engine of Internet Explorer, Elements are not responsible for their own location arrangements. Although a div or a P element has a position in the source code, there is a position in the document flow, but their contents are arranged by their nearest layout ancestor (often the body). These elements rely on the layout of their ancestors to handle a lot of heavy work such as sizing and measuring information. &lt;/p&gt;&lt;/blockquote&gt;&lt;p class=blockquotesource&gt; (haslayout overview) &lt;/p&gt;<p id=interpr&gt; Analysis &lt;/ H4&gt;&lt;p&gt; Our analysis attempts to explain what is going on in a known case, this analysis should also be used as a guide under unknown cases. But the black-box test that we're trying to use in a variety of test cases is destined to eliminate the mystery of the black box-we can't answer the question of "why". We can only try to understand the working framework of the entire "haslayout" model and how it will affect the rendering of Web documents. As a result, we can only provide some &lt;EM&gt; guidelines &lt;/EM&gt; (and only guidelines, not absolute solutions) in the end. &lt;/p&gt;&amp;Lt P&gt; What we think they are referring to is a small form. The internal content of a layout element is completely independent, and it cannot affect anything outside its bounds. &lt;/P&gt;&lt;P&gt; MS attribute layout is just some sort of flag: once it is set, this element will have its own special layout "feature", which includes floats, floats, stacks, and layers that manifest itself and its non-layout children. Count and so on many aspects of the special performance. &lt;/P&gt;&lt;P&gt; This independence may explain why layout elements are generally stable, and they can make some bugs disappear. The cost of this situation is two, one deviation from the standard, and the other is that it does not take into account the possible future bugs and problems. &lt;/P&gt;&lt;P&gt; MS's "page" mode, from the perspective of semiotics, can be seen as a lot of unrelated small blocks, and the HTML and web-based model that the "page" mode should be narrative complete, the story of the relevant information block composition. &lt;/p&gt;<p id=rev&gt; Detailed description of various situations </p&gt;<p id=clear&gt; clear float and auto scale fit height &lt;/H5&gt;&lt;P&gt; floating elements will be layou element is automatically included. This is a common problem for many novices: a page completed under IE has been stretched out of its containment container by all non-cleared floating elements under the standard compatible browser. &lt;/p&gt;&lt;ul&gt;&lt;li&gt;containing floats &lt;li&gt;how to clear floats without structural markup &lt;/LI&gt;&lt; /ul&gt;&lt;p&gt; the opposite: what if a floating element is really needed to extend its containing container, that is, to automatically include an effect that is not desired?　　You are likely to have this headache as well, as an example of this in-depth discussion: &lt;/p&gt;&lt;ul&gt;&lt;li&gt;acidic float tests &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; In IE, a floating element is always "subordinate" to its layout containing the container. The latter element is affected by the layout containing the container, not the floating element. &lt;/P&gt;&lt;P&gt; this feature and the IE6 auto-expansion to accommodate internalThe nature of the content width can be seen as being affected by this rule: "It is determined by its bounding rectangle." &lt;/P&gt;&lt;P&gt; worse problem:&lt;code&gt;clear&lt;/code&gt; cannot affect the float element outside its layout containing the container. If the page that relies on this bug to layout in IE goes to the standard compatible browser, only redo it all. &lt;/P&gt;&lt;P&gt; See the section "similar to CSS specifications" in this article for more information. &lt;/p&gt;<p id=nextfloat&gt; The element next to the floating element &lt;/H5&gt;&lt;P&gt; when a block-level element immediately follows a left-floating element, The text content should be arranged in the right order of the floating elements and will slide below the floating element. But if this block-level element has layout, for some reason the width is set, then the layout element will appear as a rectangle, where the text does not slide below the floating element. Its width is also calculated incorrectly-starting from the right of the floating element, so if it is set to &lt;CODE&gt;width:100%&lt;/CODE&gt; it will cause the width of the block to appear with the width of the floating element and the horizontal scroll bar. This is a far cry from what is described in the specification. &lt;/P&gt;&lt;P&gt; similar to this, the relative positioning element adjacent to the floating element, its position offset should refer to the parent element's filler (padding) edge (for example,&lt;code&gt;left:0;&lt;/code&gt; A relative positioned element should be stacked above the floating element in front of it. In IE, the offset &lt;CODE&gt;left:value;&lt;/CODE&gt; is calculated from the edge of the floating element's right margin (margin), which results in horizontal misalignment due to the variation in the width of the floating element (a workaround is to use the &lt;code &gt;margin-left&lt;/CODE&gt;, but also note that there are some weird problems when using a percent score. &lt;/P&gt;&lt;P&gt; according to the specification, the floating element should be combined with the box &lt;EM&gt; interleaving &lt;/EM&gt;. This is not possible for rectangles in two-dimensional spaces that do not intersect. &lt;/P&gt;&lt;P&gt; can (again) visit the following page: &lt;/p&gt;&lt;ul&gt;&lt;li&gt;tHree Pixel Text-jog &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; We can see that the layout element following a floating element does not show the bug of this 3px gap, because the 3px hard edges of the floating element's periphery cannot affect a The inner content of the layout element, so this hard edge pushes the entire layout element right 3px. Like a shield, layout can protect its internal content from being affected, but the power of the floating element pushes the entire shield away. &lt;/P&gt;&lt;P&gt; more about this section of this article, "and the CSS specification," &lt;/p&gt;<p id=list&gt; list &lt;/H5&gt;&lt;P&gt; either the list itself (&lt; Code&gt;ol, ul&lt;/code&gt;) or a single list element (&lt;CODE&gt;li&lt;/CODE&gt;), having layout will affect the performance of the list. Different versions of IE have different performance. The most obvious effect is on the list symbol (the problem will not be affected if your list customizes the list symbol). These symbols are likely to be attached to the list elements by some internal mechanism (usually attached to them). Unfortunately, because they are added through the "internal mechanism", we cannot access them or correct their error performance. &lt;/P&gt;&lt;P&gt; The most obvious effect is that after the:&lt;/p&gt;&lt;ul&gt;&lt;li&gt; list is given layout, the list symbol disappears or is placed in a different or incorrect position. &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; sometimes they can be re-emerged by changing the margins of the list elements. This seems to be the result of the fact that the layout element will attempt to cut out internal content beyond its bounds. &lt;/P&gt;&lt;UL&gt;&lt;LI&gt; list elements Get layout, there will be the same problem as above, more references (extra vertical space between list items) &lt;/li&gt;&amp; Lt;/ul&gt;&lt;p&gt; A further problem is that any list element with layout appears to have its own independent counter (in a sequential list). For example, we have an ordered list with five list elements, and only the third list element has layout. We're going to see this:&lt;/p&gt;&lt;p&gt;.　　1 ... 2 ... 1 ... 4 ... 5...&lt;/p&gt;&lt;p&gt; In addition, if a list element with layout is displayed across rows, the list symbol is aligned at the bottom (not the expected top). &lt;/P&gt;&lt;P&gt; Some of these issues cannot be resolved, so it's best to avoid having lists and list elements get layout if you need list symbols. If you need to limit the size, it is better to set the size of other elements, such as to the entire list of elements and set its width, or for example, the content of each list element to set the height and so on. &lt;/P&gt;&lt;P&gt; Another common problem with the list in IE is when something in &lt;CODE&gt;li&lt;/CODE&gt; is a &lt;CODE&gt;display:block&lt;/CODE&gt; Anchor Point (anchor). In this case, the spaces between the list elements will not be ignored and will usually appear as an extra line sandwiched between each &lt;CODE&gt;li&lt;/CODE&gt;. One way to avoid this extra whitespace in vertical direction is to assign these anchor layout. Another benefit is that the rectangular area of the entire anchor point can respond to mouse clicks. &lt;/p&gt;<p id=tab&gt; table &lt;/H5&gt;&lt;P&gt; &lt;CODE&gt;table&lt;/CODE&gt; always has layout, it always behaves as an object with a defined width. In IE6,,&lt;code&gt;table-layout:fixed&lt;/code&gt; is usually the same as a table with a width of 100%, and this also poses many problems (some computational errors). There are also other situations that need to be noted in the quirks mode of IE5.5 and IE6. &lt;/p&gt;<p id=rp&gt; relative positioning elements (R.P.) &lt;/H5&gt;&lt;P&gt; Note that &lt;CODE&gt;position:relative&lt;/CODE&gt; does not trigger Haslayout, so many rendering errors, such as content disappearing or misplaced, can be caused. These phenomena can occur when you refresh the page, resize the window, scroll the page, select content, and so on. The reason is that when IE offsets the element from this attribute, it seems to forget to signal that the child elements of the layout are "redrawn" (and if it is a layout element, in the signal chain where it redraws the event, thisA signal passed to their child will be sent normally). &amp;LT;/P&amp;GT;&amp;LT;UL&amp;GT;&amp;LT;LI&amp;GT;R.P. Parent and disappearing floated child &lt;li&gt;disappearing List-background bug &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; above is a description of some of the related issues. As a experience of experience, it's best to give layout when you position an element relative to it. Again, we also need to check whether the parent element with this structure needs layout or &lt;CODE&gt;position:relative&lt;/CODE&gt; or both, and it is important if the floating element is involved. &lt;/p&gt;<p id=cb&gt; Absolute Positioning Element (A.P.):&lt;br&gt;&lt;span&gt; contains chunks, what is the containing chunk? &lt;/SPAN&gt;&lt;/H5&gt;&lt;P&gt; Understanding the inclusion block concept of CSS is important, and it answers the question of where the absolute positioning element is relative to the location: the containing block determines the starting point of the offset, and contains a calculation reference that defines the percentage length of the chunk. &lt;/P&gt;&lt;P&gt; for an absolutely positioned element, the containing chunk is determined by its nearest location ancestor. If none of its ancestors are located, use the initial include block &lt;CODE&gt;html&lt;/CODE&gt;. &lt;/P&gt;&lt;P&gt; normally we will use &lt;CODE&gt;position:relative&lt;/CODE&gt; to set any included blocks. That is to say, we can make an absolute positioning element reference to the origin and length, etc. do not depend on the order of the elements, this can meet such as "content first" the accessibility concept of the need, but also to the complex floating layout convenience. &lt;/P&gt;&lt;P&gt; However, due to the concept of layout, the effect of this design concept in IE will have to hit a question mark. Because the absolutely positioned element in IE is offset relative to its nearest &lt;em&gt;layout location &lt;/EM&gt; ancestor, the percentage size is the next &lt;em&gt;layout&lt;/em of the layout-positioned ancestor. &gt; Ancestors calculated. Note the small difference here, and the mention of &lt;code&gt;position:relative&lt;/code&gt; is not triggered by haslayout. &lt;/P&gt;&lt;P&gt; Suppose a non-layout parent element is relatively positioned-we have to assign it to layout to make the offset work: &lt;/p&gt;&lt;ul&gt;&lt;li&gt;absolutely Buggy II &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; Suppose an unnamed parent element requires a specific size, and the page design is based on a percentage width--We can abandon the idea because the browser is poorly supported:&lt;/p&gt;&lt; Ul&gt;&lt;li&gt;absolutely positioned element and percentage width &lt;/li&gt;&lt;/ul&gt;<p id=filter&gt; filter &lt;/ H5&gt;&lt;p&gt; MS Proprietary Filter Properties filter is applicable only to layout elements. Some filters extend the bounds of an object. They reveal their own peculiar flaws. &lt;/p&gt;<p id=reflow&gt; reflow of rendered elements (Re-flow) &lt;/H5&gt;&lt;P&gt; when all elements have been rendered, if there is a change caused by the mouse passing (such as a link &lt; code&gt;background&lt;/code&gt; changes), IE will rearrange its layout containing chunks. Sometimes some elements will be placed in a new position, because when the mouse through the occurrence, IE has been aware of all the relevant elements of the width, offset and other data. This does not occur when the document is first loaded, and the width is not determined due to the feature of auto-expansion. This situation causes the page to jump when the mouse passes.　　&lt;/p&gt;&lt;ul&gt;&lt;li&gt;jump on:hover &lt;li&gt;quirky percentages:the reflow &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; These bugs related to reflow problems can cause a lot of trouble with the flow layout of percent margins and fillers. &lt;/p&gt;<p Id=bgorigin&gt; Background Origin &lt;/H5&gt;&lt;P&gt; Ms Proprietary This haslayout also affects the positioning and expansion of the background. For example, according to the CSS specification,&lt;code&gt;Background-position:0 0&lt;/code&gt; should refer to the element's "padding edge (padding edges)". And under Ie/win, if &lt;code&gt;haslayout = false&lt;/code&gt; refers to "border edge (Border edge)", when &lt;code&gt;haslayout=true&lt;/ Code&gt; refers to the filler edge: &lt;/p&gt;&lt;ul&gt;&lt;li&gt;background, Border, Haslayout &lt;/li&gt;&lt;/ul&gt;<p id= uncollapse&gt; margin overlap &lt;/H5&gt;&lt;P&gt; &lt;CODE&gt;hasLayout&lt;/CODE&gt; will affect the margin overlap of a box and its descendants. According to the specification, if a box does not have a padding and a top border, its top margin should overlap with the top margin of the first child element in its document flow: &lt;/p&gt;&lt;ul&gt;&lt;li&gt;collapsing Margins &lt;LI&gt; Uncollapsing Margins &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; in Ie/win if this box has layout then this phenomenon will not happen: it seems to have layout Will prevent their child's margins from sticking out of the containment container. Also, when &lt;code&gt;haslayout = True &lt;/CODE&gt;, there is a problem with margin calculation errors, whether it contains a container or a child element. &lt;/p&gt;&lt;ul&gt;&lt;li&gt;margin collapsing and Haslayout &lt;/li&gt;&lt;/ul&gt;<p id=link&gt; block-level links </p &gt;&lt;P&gt; Haslayout affects a block-level linked mouse response area (clickable area). Usually haslayout = False when only the text coverage area can respond. Haslayout = True will respond to the entire block area. Any block-level element that adds events such as Onclick/onmouseover also has the same phenomenon. &lt;/p&gt;&lt;ul&gt;&lt;li&gt;blockAnchors and Haslayout &lt;/li&gt;&lt;/ul&gt;<p id=inpage&gt; using the keyboard in the page: Explore &lt;/H5&gt;&lt;P&gt; When you use tab to navigate through the page, If you enter a page link (in-page link), then press the &lt;KBD&gt;tab&lt;/KBD&gt; button will not continue to normal: &lt;/p&gt;&lt;ul&gt;&lt;li&gt;haslayout Property characterizes IE6 Bug &lt;li&gt;keyboard Navigation and Internet Explorer &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; &lt;k The Bd&gt;tab&lt;/kbd&gt; key will bring the user to the first target (which is usually wrong) in its nearest layout ancestor (if this ancestor was made by &lt;code&gt;table&lt;/code&gt;, &lt;CODE&gt; Div&lt;/code&amp;gt, &lt;CODE&gt;span&lt;/CODE&gt; or some other label). &lt;/p&gt;<p id=stack&gt; Stacking, layering and layout &lt;/H4&gt;&lt;P&gt; Ie/win appear to have two levels of layering and stacking order:&lt;/p&gt;&lt;ul&gt;&lt;li&gt; One is the pattern of (pseudo) attempts to adopt CSS: Effect of Z-index value to RP and AP blocks &lt;LI&gt; There is also a "contenteditable" by "Haslayout" and his twin brother The stacking order in which the behavior occurs. As shown in the relative positioning example above, stacking under the influence of layout is like the masterpiece of Harry Houdini, the Magician, who became famous as a card trick. &lt;/LI&gt;&lt;/UL&gt;&lt;P&gt; two stacking modes are incompatible, but coexist in the IE rendering engine. Experience: When debugging, both situations need to be taken into account. We may see problems regularly in drop-down menus or similar complex menus, as they often involve a lot of headaches such as stacking, positioning, and floating. Lay the elements that z-index positionedOut is a possible remedy, but not limited to this, just a reminder. &lt;/p&gt;<p id=contenteditable&gt; Chaotic contenteditable</p&gt;&lt;p&gt; If you give an HTML tag setting &lt;CODE&gt; The Contenteditable=true&lt;/code&gt; property, such as &lt;code&gt;&lt;body Contenteditable=true&gt;&lt;/code&amp;gt, will allow the element and its Layout sub-elements for real-time editing, drag to change the size and other operations. You can use this attribute on a floating element or a layout list element in a sequence table to see the effect. &lt;/P&gt;&lt;P&gt; to manipulate elements (edit them), "contenteditable" and "haslayout" for those &lt;CODE&gt;hasLayout&lt;/CODE&gt; returns &lt; The elements of code&gt;true&lt;/code&gt; introduce a separate set of stacking orders. &lt;/P&gt;&lt;P&gt; Editing Platform inherited the layout concept, the layout of the misunderstanding is due to contenteditable and can be used as proof ( Some application software that integrates the IE editing engine in some way implies some kind of forced backward compatibility with the layout concept. &lt;/p&gt;&lt;ul&gt;&lt;li&gt;more on contenteditable &lt;/li&gt;&lt;/ul&gt;<p id=engineer&gt; and CSS specifications similar places &lt;/ H4&gt;&lt;p&gt; your MSIE page is a mess in another browser? We don't need to let that happen. If used properly, any good browser can MSIE the page--as long as you use some of the correct CSS. &lt;/P&gt;&lt;P&gt; using &lt;EM&gt; subtle &lt;/EM&gt; similarities between &lt;CODE&gt;hasLayout&lt;/CODE&gt; and "new block-level format content", There are several ways we can re-implement the "include floating element" effect &lt;CODE&gt;hasLayout&lt;/CODE&gt; in a standard compatible browser, and some "floatingThe element next to the moving element "is unique to the effect. &lt;/p&gt;&lt;ul&gt;&lt;li&gt;reverse Engineering Series &lt;li&gt;simulations &amp;LT;/LI&amp;GT;&amp;LT;/UL&amp;GT;&amp;LT;H4 id= Quirk&gt;quirks mode &lt;/H4&gt;&lt;P&gt; Some doctype, or &lt;CODE&gt;&lt;xml&gt;&lt;/CODE&gt; declaration, "Quirks mode" is triggered in IE6 or backward compatibility mode. In this mode, IE6 is like IE5.5, and has the same bug as his brother, the same problem and the same behavior. &lt;/P&gt;&lt;P&gt; for the ie7,&lt;code&gt;&lt;xml&gt;&lt;/code&gt; declaration no longer changes the rendering mode; to trigger the quirks mode, we have to insert a comment. (IE7 quirks mode and IE6 quirks mode are still to be verified) &lt;/p&gt;&lt;pre class=code&gt;&lt;?xml version= "1.0" encoding= "Utf-8"? &gt;&amp; lt;! -- ... Let IE7 run in quirks mode--&gt;&lt;! DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 strict//en" "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" &gt;&lt;/ PRE&amp;GT;&amp;LT;H4 id=conclusion&gt;layout-Conclusion &lt;/H4&gt;&lt;P&gt; the entire Layout concept and some basic CSS concepts are incompatible, i.e. include, arrange, float, position and cascade. &lt;/P&gt;&lt;P&gt; due to elements on the page or with or without layout, the behavior of Ie/win will be inconsistent with the CSS specification. &lt;/p&gt;<p id=bottomline&gt; have layout-another engine? </p&gt;&lt;blockquote title= "Dean Edward some notes about IE7" cite=http://dean.edwards.name/ie7/notes/#layout &gt;&lt;P&gt; IE's object model seems to be a blend of document models and their traditional application models. I mentioned this because it is important to understand how IE renders pages. The switch from the document model to the application model is to give an element "layout".　　&lt;/p&gt;&lt;/blockquote&gt;&lt;p class=blockquotesource&gt; (Dean Edwards) &lt;/P&gt;&lt;P&gt; Sometimes it's impossible to explain something: like Haslayout, it chooses two different rendering engines depending on its state, and each has its own bugs and quirks. &lt;/p&gt;<p id=absurd&gt; bug</p&gt;&lt;blockquote title= "Molly said ..." cite=http://www.gunlaug.no/ Contents/molly_1_15.html&gt;&lt;p&gt; software bugs are caused by human errors in the process of making integrity and logic issues poorly conceived. This is the inherent flaw of mankind, there is no good solution at present. &lt;/P&gt;&lt;P&gt; also because of this flaw, any attempt to fix bugs without rewriting the software will inevitably lead to more complex bugs in the software. &lt;/P&gt;&lt;P&gt; all software that relies on other software-including, of course, dependent on the operating system-will also rely on their bugs. So we get a bunch of bugs from all the associated software, which also means it's almost impossible to find a bug-free software. &lt;/p&gt;&lt;/blockquote&gt;&lt;p class=blockquotesource&gt; (Molly, the cat?) &lt;/P&gt;&lt;P&gt; This article was created on June 30, 2005 and last modified on April 2, 2006. &lt;li &gt;&lt;i class= "Layui-icon" &gt;&amp; #xe63a;