This document has not been updated in over a decade and is severely out of date. I have kept it available for historical interest only.
This is a mixed collection of different issues that are worth taking into account when writing Web pages according to the W3C Recommendations. I have either run accross the issues myself or seen others run into them when reporting bugs in the Mozilla browser. These issues are faced when people try to apply experience they have from working with quirky browsers to standards-compliant authoring.
Pages that comply with the HTML Recommendation must begin with a proper doctype declaration. (However, a doctype declaration should not be included in documents that are not really HTML and CSS compliant!) In order to deal with both old pages written to old browser quirks and with new standards-compliant pages, it important to make sure that the browser is in the mode that suits the content. Both Mozilla and IE 5 for Mac choose the mode based on the doctype declaration of the document.
<body>When using the HTML 4.01 Strict DTD (nesting rules), there can only be block-level elements directly inside <body>—unlike when using the Transitional DTD (nesting rules).
<p>The <p> element can’t contain any block-level elements including <p> itself. The block-level elements are <p>, headings, lists, <div>, <noscript>, <blockquote>, <form>, <hr>, <pre>, <table>, <fieldset> and <address>.
When it comes to images or lines with no text, the CSS line box model is very different from the model used in browsers that imitate the behavior of Netscape Navigator 1.x. The line box model is also the single most difficult thing to grasp about CSS. If line heights on a page “break” in Mozilla’s standard layout mode and “work” in the quirks mode, the page most likely is written to the Navigator 1.x model and not to the CSS line box model. One might argue that the authors of the CSS2 specification should have paid more attention to compatibility with existing browsers when choosing the default values for CSS properties.
The inline box model is discussed in detail in David’s Inline Box Model and Eric Meyer’s Inline formatting model.
![[CSS defult behavior]](https://hsivonen.fi/img/css-default.png "CSS default behavior as seen in Mozilla"){kind=small}
When writing code to the Navigator 1.x model, Web authors have come to expect that code like <a href="..."><img src="..."></a> causes the box of the <a> element stretch to match exactly the box of the <img> element. Not so with CSS!
If the <a> element is given a background color, the colored box of the <a> element extends below the bottom edge of the image.
![[Behavior with vertical-align: bottom;]](https://hsivonen.fi/img/vertical-align-bottom.png "vertical-align: bottom; as seen in Mozilla"){kind=small}
This happens, because the initial value the vertical-align property is baseline. As a result, the bottom edge of the <img> is aligned with <a>’s baseline. In order to align the bottom of the image with the bottom of the box of the <a> element, the vertical-align property of the <img> element could to be set to bottom. Unfortunately, this may cause problems in Opera. The alignment problem usually arises when using tables a layout devices. More on that specific situation below.
The image of the previous example is partially transparent. One can notice that the box of the <a> element doesn’t stretch to the height of the image. This is not a browser bug.
While the height of block-level elements depends (by default) on the contents of the element, the height of inline non-replaced elements (including <a>) depends on the line-height property. As a result, the height of the box of the <a> element does not depend on the height of the image. Tall images just overflow without affecting the height of the line box.
![[Behavior with vertical-align: bottom; and background-color: inherit;]](https://hsivonen.fi/img/background-color-inherit.png "vertical-align: bottom; and background-color: inherit; as seen in Mozilla"){kind=small}
The box of the <img> can be made the same color as the box of the <a> by setting the background-color of the <img> to inherit. However, this solution makes no guarantee about the relationship of the line height and the image height.
The two above-mentioned problems are usually faced when sliced images are placed in a layout table. Using tables with sliced images as a layout device is considered depracated and using floaters and non-sliced images works better with CSS.
If one still wants to use the old table-based layout style, there is an easy combined solution. Setting the display property of the images and the enclosing <a> element to block solves the problem.
That is, if your table cells containing only an image are flagged with class="imgcell", the minimum you need is this style rule in the style sheet:
.imgcell img, .imgcell a { display: block; }
Alternatively, you may wish to make sure that margins, padding and borders defined elsewhere don’t interfere with the images:
.imgcell img, .imgcell a {
display: block;
margin: 0;
border: 0;
padding: 0;
}
Even though some browsers treat class and ID selector case-insensitively, class names and IDs are supposed to case-sensitive and will be treated as such by stricter browsers.
In the HTML 4.01 specification both the class attribute and the id attribute are defined to take a value that is case-sensitives.
width is the content widthDespite buggy implementations in some browsers, according to the specification width sets the width of the content area of a box exclusive of padding. If a background color is applied to the box, the width of the colored rectangle is padding-left + width + padding-right.
Conforming CSS user agents are required to apply a default style sheet (or behave as if they did) prior to all other style sheets for a document
. The default style sheet should present the elements of the document language in ways that satisfy general presentation expectations for the document language
.
The CSS2 specification contains a sample style sheet for HTML 4.0. However, the it is informative—not normative. Different browsers have different default style sheets for HTML. Even if a style sheet looks fine in one browser, another browser might have a default style sheet that interacts with the style sheet in an unwanted manner.
For example, some browsers implement the default list indentation using margin-left while others use padding-left. When altering the indentation, it is important to override both properties.
One way to avoid unwanted effects caused by unanticipated style rules in the UA style sheet is to reset padding, margins and borders on all elements to zero. Those properties can then be overridden on selected elements. One could use this rule: * { margin: 0; padding: 0; border: 0; }. However, the universal selector is unsafe on pages with form widgets. Some browsers allow style to be applied to form widgets while other browsers don’t. In order to avoid problems with form widgets, the selector would have to list the names of the other elements.
Unfortunately the W3C didn’t decide on the XHTML namespace URI right away when it became obvious that such a URI is needed. Different URIs have been used as placeholders in Microsoft’s documentation, in mozilla.org’s old documentation and even in the Namespaces in XML Recommendation! The correct final XHTML namespace URI is “http://www.w3.org/1999/xhtml” (as specified in the XHTML 1.0 Recommendation).
The attribute xmlns:html="http://www.w3.org/1999/xhtml" associates the prefix html with the XHTML namespace. IE 5 (incorrectly) requires the use of the html prefix.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。