在quirks模式下不能正常工作的一切的列表？ [英] List of everything that doesn't work correctly in quirks mode?

问题描述

有没有人有一个完整的HTML，JavaScript和CSS的列表，在Quirks模式（特别是IE怪异模式）中有bug？

我已经检出了quirksmode .org列表，位于 http://www.quirksmode.org/css/quirksmode.html，但它似乎并不全面。例如，我看到一些浏览器有框架的问题，除非你使用框架集doctype。

谢谢，
baa

解决方案

以下是浏览器特定怪癖模式行为的汇总：

有些HTML5功能不支持某些版本的IE。例如，IE 9无法以怪癖模式识别canvas元素。

框模型不正确（与CSS规范不同，但可能直觉上更自然）。这意味着width和height属性指定整个元素框的尺寸，包括填充和边框，而不仅仅是元素的内容。 （本文档后面有一个演示。）

未替换的内联元素的尺寸（例如，默认的span元素）受宽度和高度属性影响

元素的百分比高度（例如< table height =100％> / code>在HTML中或 table {height：100％} 在CSS中），使用可用的高度作为参考，即使封闭块具有height： auto（默认）。在标准模式下，高度由内容的要求决定;但是当包围块的高度设置为特定值时，百分比高度工作。

body元素的高度为100％，与其内容相反。 （如果您想在标准模式中使用body的高度为100％，请在CSS中设置 html，body {height：100％} 。）

文本区域宽度的计算方式不同。例如，在IE 9上，cols = 5在标准模式下使区域5个字符宽，而在Quirks模式下只有4个字符宽。

通过扩展一个框来处理溢出。当元素的内容不适合为其指定的维度（显式地或隐式地）时，overflow：visible（默认值）意味着内容溢出，而盒子尺寸是指定的。在怪异模式中，尺寸改变;这可以容易地看出。如果框包含背景颜色或边框。

当图片未显示时，替代图片并不总是显示替代文字。当img元素具有小于文本所需的尺寸时，如在< img src =x.pngalt =some alt textwidth =8height =9> 存在。 Firefox忽略文本并仅显示损坏图像的通用图标。

根元素是IE上Quirks模式下的body元素。按照规范，它是html元素。例如，为身体设置边距或宽度在Quirks模式中不起作用。作为另一个例子，IE默认情况下有一个垂直滚动条，虽然它是无效的（昏暗），当没有什么可滚动，你可以通过设置 body在Quirks模式中删除它（当不需要时） {overflow：auto; } ，但在标准模式下，您需要添加 html {overflow：auto;

在某些版本的IE上默认出现灰色的2px页面边框。在某些情况下，可以通过设置html元素的border属性（例如 html {border：0;} ）来更改或删除。

id属性值不区分大小写，因此例如CSS选择器#foo匹配id =Foo的元素。根据规范，匹配必须区分大小写：#foo仅匹配具有id =foo的元素。

在CSS中设置时，图像的填充将被忽略对于img元素或输入类型=image元素。
浮动图像的默认水平边距为三个像素（而不是零）。也就是说，如果img元素具有属性align =left或align =right或者如果CSS规则float：left或float：right适用于它，则浏览器的行为就像img元素具有属性hspace = 3（或其左边缘和右边缘属性的值为3px）。这适用于IE;在其他浏览器上，怪癖模式可能只会在图像一侧产生额外的边距，其宽度可以是2像素，而不是3像素。

图像的垂直对齐是在一定条件下到包围盒的底部，而不是到文本的基线。当图像是元素（通常是表单元格）中的唯一内容时，会发生这种情况。这意味着默认情况下，表格单元格中的图像位于Quirks模式下的单元格底部（这通常是作者想要的），而在标准模式下，图像下方有几个像素间距（除非设置为vertical-align：

在IE 9中的文本呈现在Quirks模式下不使用浏览器中的几个新功能。这可以例如。使得一些文本所需的宽度在不同模式下不同，从而影响文本划分成行。请参阅Microsoft在Windows Internet Explorer 9中的关于文本呈现。

在CSS中使用margin：0 auto不工作。注意：在IE到IE 7中，在HTML中设置align =center或者在CSS中的text-align：center中，div不正确地将任何内块元素作为整体居中，即使在标准模式下。在IE 8上，这只发生在怪异模式，

字体属性不会从主体或其他封闭元素继承到表中。这发生特别是对于font-size，但也可能发生在字体，颜色和行高。例如，如果您设置 body {font-family：Arial} ，表单元格中的字体可能仍为浏览器默认值。

在表格单元格的字体大小设置中，百分比值被解释为相对于浏览器的基本字体大小，而不是通过CSS规范应用于封闭元素（表行）的字体大小。

字体大小关键字解释不正确，因此媒体大于浏览器的基本字体大小，小于基本字体大小。类似地，关键字的整个规模，xx-small，x-small，small，large，x-large，xx-large被系统地解释错误：每个值被解释为比它应该更大的一步。

字体渲染在IE 9上是不同的。在标准模式下，它应用更先进的技术。这导致小的差异可能很重要，影响文本的宽度等。请参阅关于Windows Internet Explorer 9中的文本呈现。

边框宽度关键字thin，medium和thick在IE上有不同的含义。例如，在标准模式下，thin为1px，在Quirks模式下为2px。

在非标准但广泛支持的bordercolor属性在Quirks模式模式由IE。

在Quirks模式的IE中，单选按钮和复选框的总尺寸为20 x 20像素，在标准模式和其他浏览器中与13×13相反。图形按钮或框的大小是相同的，但是它周围的间距是不同的。它是元素呈现的一个组成部分，不受填充或边距属性的影响，但受宽度和高度属性的影响。

格式不正确的属性值通常基于的猜测，例如margin：10 as margin：10px and color：ffffff as color：#ffffff。这违反了CSS中的强制性错误处理规则：使用语法错误值的规则将被忽略。

浏览器无法识别的属性值不正确，可能会导致该属性被忽略。例如，设置 h1 {color：red;颜色：废话} 可能导致整个规则被忽略;按规格，正确的设置 color：red 为准。此类重复设置通常用于尝试在使用高级CSS值时提供回退，并且这通常在Quirks模式下失败，因为回退被忽略。该问题只出现在CSS规则中，因此将规则分为两部分将有所帮助。例如，而不是 h1 {color：#ccc; color：rgba（255，255，255，0.7）; } ，您将使用 h1 {color：#ccc; } h1 {color：rgba（255，255，255，0.7）; }

字母的情况在CSS中的类和标识符选择器中被视为无关紧要。因此，选择器.foo匹配class =Foo或class =FOO的元素。根据CSS规范，这种情况在这些上下文中是重要的。
类和标识符选择器接受格式错误的名称。具体来说，接受以句点或数字符号开头的名称（例如在选择器.123a和＃42中）。

声明white-space：pre被忽略。 / p>

不支持固定定位：声明位置：fixed被视为position：static（在IE 7上）。

IE 7中许多标准（CSS 2.1）添加到CSS支持（例如max-width属性和属性选择器）不是使用Quirks模式。也就是说，有许多CSS功能不支持在IE 6和在IE 7支持，但只在标准模式。请参阅Microsoft的博客条目关于IE7的CSS更改的详细信息。

某些非标准CSS功能（CSS 2.1中没有的功能），如滚动条属性， Opera在Quirks模式，但在标准模式下被忽略。在许多浏览器中，忽略设置rowspan = 0或colspan = 0，即使它们支持这些标准模式下的设置。 （这意味着单元格跨越了行或列的其余部分，这在浏览器中相对最近。）

标记汤解析。例如，如果文档包含标记
< p> text< table> ...< / table>
， Firefox在Quirks模式下将p元素视为包含表格元素。在标准模式下，表的开始标记隐式关闭打开的p元素。差异可以看出，如果你在p元素上设置边框。类似地，例如，Firefox在字体元素内接受ul元素。即使在标准模式下，IE总是按照错误的规则工作，但是可以通过使用有效的标记并且总是使用如< / p>



不同的标签汤加工。相反的问题，或多或少，是在Quirks模式中，像< font color = red>< table> ...< / table>< / font> 不会影响表中文本的颜色。在标准模式下，即使标记是非标准的（根据所有的HTML规范也是无效的）！





元素之间的空格可能很重要。例如，假设您有一个链接列表。通常，您将在列表项之间写入标记，换句话说，li元素（即<$​​ c $ c>< / li> 和< li> ; 标签）：





 < ul& 
< li>< a ...> ...< / a>< / li> 
< li>< a ...> ...< / a>< / li> 
 ... 
< / ul> 
 





但是，如果您设置display：元素，则可能会在框之间产生垂直间隙（空行）。这发生在IE 7在Quirks模式，并始终在IE的以前的版本。另一方面，对于上面的标记，如果您为li元素设置display：inline，则在Quirks模式下的IE上的元素框之间没有空格。在标准模式下，在其他浏览器上，有一个空格对应一个空格，这被认为是一些符合标准的。

表单有默认的下边距的1em左右在某些浏览器。 （在IE 7上，在这两种模式下都有这样的余地。）这显然意味着继续web浏览器的传统，在表单之下留下很多空格。

默认垂直边距在某些上下文中被抑制，例如，当p元素作为td元素中的第一个元素出现时。这或多或少是浏览器的传统行为，并发生在IE 7在两种模式（在IE 8，在Quirks模式下）。如果相关元素的垂直边距在CSS中显式设置，则不会出现此问题。

img元素的工具提示效果基于某些旧式浏览器的alt属性，包括处于Quirks模式的IE 8，但不处于标准模式。

线断开机会的wbr标记被授予。浏览器已经广泛支持它，但IE 8已经停止这样做在标准模式这是坏消息，因为< wbr> 标签是唯一有效的方法

Mozilla浏览器（如Firefox和Seamonkey）有一些额外的功能，记录在quirk.css文件中。例如，表格边框的默认颜色为灰色（如在大多数其他浏览器中），与使用标准模式下的表格的前景颜色相反。注意：并不是该文件中的所有设置都适用于所有版本的Mozilla。

某些DOM功能不可用。例如，在Quirks模式下，IE 9无法识别方法getElementsByClassName（其他浏览器完全支持并包含在HTML5中）。

所谓的命名访问在Window对象上使用（在JavaScript中）window.foo，window ['foo']或只是foo来引用id =foo的元素是可能的在Quirks模式只在一些版本的Firefox。 （在版本15中，它在两种模式下都恢复了对此旧版功能的支持。）

在Firefox中，document.all集合只要。

在Firefox中，在quirks模式下，没有行/行组的表格即使指定了高度也为零。

在Firefox中，在quirks模式下在FRAMESET cols / rows规范中将0 *视为1 *

/ p>



无散列的十六进制颜色奇偶

无单位长度quirk

行高计算quirk

这些块忽略了行高问题

百分比高度计算quirk

html元素填充视口quirk

body元素填充html

表格单元格宽度计算quirk

表格单元格nowrap最小宽度计算quirk

折叠表quirk

文本修饰不会传播到表quirk

表继承了正文quirk的颜色

表格单元格高度框大小quirk

：active and：hover quirk

参考

• 在Quirks模式下会发生什么在网络浏览器中？




• Quirks Mode Standard




• Mozilla Quirks模式行为 - Mozilla | MDN




• IE10中的互操作HTML5疑问模式 - IEBlog




• HTML 5.2：第10节呈现

Does anyone have a complete list of HTML, JavaScript, and CSS that is buggy in Quirks Mode (particularly IE Quirks Mode)?

I have checked out the quirksmode.org list at http://www.quirksmode.org/css/quirksmode.html, but it does not seem to be comprehensive. For example, I've seen some browsers have problems with frames unless you use a frameset doctype.

Thanks, b.a.a.

解决方案

Here is an aggregate of browser specific quirks mode behaviors:

Some HTML5 features are not supported some versions of IE. E.g., IE 9 does not recognize the canvas element in Quirks Mode.

The box model is incorrect (different from CSS spec­i­fi­ca­tions, though perhaps intuitively more natural). This means that the width and height properties specify the dimen­sions of the entire element box, including padding and border, and not just the element’s content. (There is a demo later in this document.)

Dimensions of non-replaced inline elements (e.g., span elements by default) are affected by width and height properties (while by CSS specifications, they shall be ignored).

Percentage heights for elements (e.g., <table height="100%"> in HTML or table { height: 100% } in CSS) are applied, using the available height as reference, even when the enclosing block has height: auto (the default). In Standards Mode, the height is determined by the require­ments of the content; but percentage heights work when the enclosing block has its height set to a specific value.

The height of the body element is 100%, as opposite to being determined by its content. (If you want 100% height for body in standards mode, set html, body { height: 100% } in CSS.)

Textarea widths are calculated differently. E.g., on IE 9, cols=5 makes the area 5 characters wide in Standards Mode but only 4 characters wide in Quirks Mode.

Overflow is treated by expanding a box. When the content of an element does not fit into the dimensions specified for it (explicitly or implicitly), then overflow: visible (the default) means that the content overflows while the box dimensions are as specified. In Quirks Mode, the dimensions change; this can easily been seen e.g. if the box has a back­ground color or a border.

Alt text is not always shown as a replacement for an image when the image is not shown. When the img element has dimensions smaller than needed for the text, e.g. as in <img src="x.png" alt="Some alt text" width="8" height="9"> when x.png does not exist. Firefox omits the text and shows a generic icon for a broken image only.

The root element is the body element on IE in Quirks Mode. By the specifications, it is the html element. For example, setting a margin or width for body has no effect in Quirks Mode. As another example, IE has a vertical scrollbar by default, though it is inactive (dim) when there is nothing to scroll, and you can remove it (when it is not needed) in Quirks Mode by setting body { overflow: auto; }, but in Standards Mode, you need to add html { overflow: auto; } as well.

A gray 2px page border appears by default on some versions of IE. It can in some cases be changed or removed by setting the border property of the html element (e.g., html { border: 0; }).

The id attribute values are matched case-insensitively, so that e.g. the CSS selector #foo matches an element with id="Foo". By the specifications, the match must be case-sensitive: #foo matches only an element with id="foo".

Padding for an image is ignored when set in CSS for an img element or an input type="image" element. Default horizontal margin for a floated image is three pixels (instead of zero). That is, if the img element has the attribute align="left" or align="right" or if the CSS rule float: left or float: right applies to it, the browser behaves as if the img element had the attribute hspace="3" (or its margin-left and margin-right properties had the value 3px). This applies to IE; on other browsers, Quirks Mode may cause the extra margin on one side of the image only, and its width can be 2 pixels instead of 3.

Vertical alignment of an image is under certain conditions to the bottom of the enclosing box, not to the baseline of text. This happens when the image is the only content within an element, typically a table cell. This means that e.g. an image in a table cell is by default at the bottom of the cell in Quirks Mode (which is often what the author wants), whereas in Standards Mode there is a few pixels spacing below the image (unless one sets e.g. vertical-align: bottom for the img element).

Text rendering on IE 9 does not use several new features in the browser, when in Quirks Mode. This may e.g. make the width needed by some text different in different modes, thereby affecting the division of text into lines. See Microsoft’s About Text Rendering in Windows Internet Explorer 9.

Centering a block in CSS using e.g. margin: 0 auto does not work. Note: On IE up to IE 7, setting align="center" in HTML or text-align: center in CSS for a div incorrectly centers any inner block element as a whole, even in Standards Mode. On IE 8, this happens in Quirks Mode only,

Font properties are not inherited from body or other enclosing elements into tables. This happens especially for font-size but may happen for font face, color, and line height as well. For example, if you set body { font-family: Arial }, it is possible that the font in table cells remains the browser default.

In a font size setting for a table cell, a percentage value is interpreted as relative to the browser’s basic font size, not to the font size that applies to the enclosing element (the table row) by CSS specifications.

Font size keywords are interpreted incorrectly so that medium is larger than the browser’s basic font size and small equals that basic font size. Similarly, the entire scale of keywords, xx-small, x-small, small, large, x-large, xx-large is interpreted systematically wrong: each value is interpreted as one step larger than it should.

Font rendering is different on IE 9. In Standards Mode, it applies more advanced technologies. This causes small difference that may matter, affecting the width of text among other things. See About Text Rendering in Windows Internet Explorer 9.

Border width keywords thin, medium, and thick have different meanings on IE. For example, thin is 1px in Standards Mode, 2px in Quirks Mode.

The bordercolor attribute, which is nonstandard but widely supported, is treated differently in Quirks Mode vs. Standards mode by IE. The colors appear differently, though this seems to be caused by an effect on border style.

Radio buttons and checkboxes have total dimensions 20 by 20 pixels in IE in Quirks Mode, as opposite to 13 by 13 in Standards Mode and in other browsers. The size of the graphic button or box is the same, but the spacing around it is different. It is an integral part of the element rendering, not affected by padding or margin properties, but affected by width and height properties.

Malformed property values are often interpreted on the basis of guesswork, e.g. margin: 10 as margin: 10px and color: ffffff as color: #ffffff. This violates mandatory error processing rules in CSS: a rule using syntactically incorrect value shall be ignored.

Incorrect property values that are not recognized by a browser may cause an earlier setting for the property to be ignored. For example, setting h1 { color: red; color: nonsense; } may cause the entire rule to be ignored; by the specifications, the correct setting color: red shall prevail. Such duplicate settings are often used in an attempt to provide a fallback when using advanced CSS values, and this often fails in Quirks Mode, because the fallback gets ignored. The problem only appears within a CSS rule, so dividing a rule into two parts would help. For example, instead of h1 { color: #ccc; color: rgba(255, 255, 255, 0.7); } you would use h1 { color: #ccc; } h1 { color: rgba(255, 255, 255, 0.7); }

Case of letters is treated as insignificant in class and identifier selectors in CSS. Thus, the selector .foo matches an element with class="Foo" or class="FOO". By CSS specifications, the case is significant in these contexts. Malformed names are accepted in class and identifier selectors. Specifically, names starting with a period or a number sign (e.g. in selectors .123a and #42) are accepted.

The declaration white-space: pre is ignored.

Fixed positioning is not supported: the declaration position: fixed is treated as position: static (on IE 7).

Many standard (CSS 2.1) additions to CSS support (such as the max-width property and attribute selectors) in IE 7 are not in use Quirks Mode. That is, there are many CSS features that were not supported in IE 6 and are supported in IE 7, but only in Standards Mode. See Microsoft’s blog entry Details on our CSS changes for IE7.

Some nonstandard CSS features (features not in CSS 2.1) such as scrollbar properties are recognized by some versions of IE and Opera in Quirks Mode but ignored in Standards Mode. On IE 8 and newer, this also applies to the expression() construct.

Setting rowspan=0 or colspan=0 is ignored in many browsers, even if they support these settings in Standards Mode. (They mean that the cell spans the rest of the row or column. This was implemented in browsers relatively lately.)

Tag soup parsing. For example, if a document contains the markup <p>text<table>...</table> then e.g. Firefox treats, in Quirks Mode, the p element as containing the table element. In Standards Mode, the start tag of table implicitly closes the open p element. The difference can be seen if you e.g. set a border on the p element. Similarly, for example, Firefox accepts a ul element inside a font element. IE always works by wrong rules in such issues, even in Standards Mode, but standards-conforming behavior can be achieved by using valid markup and always using explicit end tags like </p> even when they are formally optional.

Different tag soup processing. An opposite issue, more or less, is that in Quirks Mode, markup like <font color=red><table>...</table></font> does not affect the color of text inside the table. In Standards Mode, it does – even though the markup is nonstandard (invalid according to all HTML specifications)!

White space between elements can be significant. For example, let’s say you have a list of links. Typically you would write the markup with line breaks between the list items, the li elements (that is, between </li> and <li> tags):

    <ul>
    <li><a ...>...</a></li>
    <li><a ...>...</a></li>
    ...
    </ul>

However, if you set display: block and a border for the link elements, you may wind up with vertical gaps (empty lines) between the boxes. This happens on IE 7 in Quirks Mode, and always on previous versions of IE. On the other hand, for the markup above, if you set display: inline for the li elements, then there is no white space between the element boxes on IE in Quirks Mode. In Standards Mode, and on other browsers, there is white space corresponding to one blank, and this is regarded as standards-conforming by some.

Forms have a default bottom margin of 1em or so in some browsers. (On IE 7, there is such a margin in both modes.) This is apparently meant to continue the tradition of web browsers to leave that much spacing below a form. It used to be a frequently asked question how to get rid of the empty line after a form.

Default vertical margins are suppressed in some contexts, e.g. when a p element appears as the first element in a td element. This is more or less traditional behavior in browsers and takes place on IE 7 in both modes (on IE 8, in Quirks Mode only). The issue does not arise if the relevant elements have their vertical margins set explicitly in CSS.

Tooltip effects for img elements are based on alt attributes on some old-style browsers, including IE 8 in Quirks Mode but not in Standards Mode.

The wbr markup for a line breaking opportunity is honored. Browsers have widely supported it, but IE 8 has stopped doing so in "standards mode." This is bad news, since <wbr> tags have been the only effective way to suggest line break opportunities for otherwise unbreakable strings on web pages.

Mozilla browsers (like Firefox and Seamonkey) have some additional features, documented in the quirk.css file. For example, the default color for table borders is gray (as in most other browsers), as opposite to using the foreground color of the table as in Standards Mode. Note: Not all the settings in that file apply to all versions of Mozilla.

Some DOM features are not available. For example, in Quirks Mode, IE 9 does not recognize the method getElementsByClassName (which is well supported by other browsers and included in HTML5).

The so-called named access on the Window object such as using (in JavaScript) window.foo, window['foo'] or just foo to refer to the element with id="foo" is possible in Quirks Mode only in some versions of Firefox. (In version 15, it however restored support to this legacy feature in both modes.)

In Firefox, the document.all collection (in JavaScript) is recognized in Quirks Mode only.

In Firefox, in quirks mode tables with no rows/rowgroups have zero height even when a height is specified

In Firefox, in quirks mode in a FRAMESET cols/rows specification 0* is treated as 1*

And some CSS quirks:

The hashless hex color quirk

The unitless length quirk

The line height calculation quirk

The blocks ignore line-height quirk

The percentage height calculation quirk

The html element fills the viewport quirk

The body element fills the html element quirk

The table cell width calculation quirk

The table cell nowrap minimum width calculation quirk

The collapsing table quirk

The text decoration doesn’t propagate into tables quirk

The tables inherit color from body quirk

The table cell height box sizing quirk

The :active and :hover quirk

References

• What happens in Quirks Mode in web browsers?

• Quirks Mode Standard

• Mozilla Quirks Mode Behavior - Mozilla | MDN

• Interoperable HTML5 Quirks Mode in IE10 – IEBlog

• HTML 5.2: Section 10. Rendering

这篇关于在quirks模式下不能正常工作的一切的列表？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！