document.compatMode and almost standards mode
http://chunghe.googlecode.com/svn/trunk/experiment/almost.standard.mode/
http://chunghe.googlecode.com/svn/trunk/experiment/almost.standard.mode/standard.mode.htm
document.compatMode - MDC
mode = document.compatMode
mode is a string containing "BackCompat" for Quirks mode or "CSS1Compat" for Strict mode.
There is a third mode, Gecko's "Almost_Standards" Mode, which only differs from Strict mode in the layout of images inside table cells. This third mode is reported the same way as Strict mode: "CSS1Compat".
Gecko's "Almost Standards" Mode - MDC - 在 almost standard mode 設定 img{display:block} or img{vertical-align:bottom} 看起來跟 standard mode 一模一樣
"Almost standards" rendering mode is exactly the same as "standards" mode in all details save one: the layout of images inside table cells is handled as they are in Gecko's "quirks" mode, which is fairly consistent with other browsers, such as Internet Explorer. This means that sliced-images-in-tables layouts are less likely to fall apart in Gecko-based browsers based on the rendering engine found in Mozilla 1.0.1 or later when in either "quirks" or "almost standards" mode. (See the DevEdge article "Images, Tables, and Mysterious Gaps" for a detailed explanation of how such layouts are treated in "standards" mode.)
The DOCTYPEs that will trigger "almost standards" mode are those which contain:
* The public identifier "-//W3C//DTD XHTML 1.0 Transitional//EN"
* The public identifier "-//W3C//DTD XHTML 1.0 Frameset//EN"
* The public identifier "-//W3C//DTD HTML 4.01 Transitional//EN", with a system identifier
* The public identifier "-//W3C//DTD HTML 4.01 Frameset//EN", with a system identifier
* The IBM system DOCTYPE "http://www.ibm.com/data/dtd/v11/ibmxhtml1-transitional.dtd"
A complete DOCTYPE contains a public identifier and a system identifier.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
The parts are as follows:
* Public Identifier: "-//W3C//DTD HTML 4.01 Transitional//EN"
* System Identifier: "http://www.w3.org/TR/html4/loose.dtd"
Images, Tables, and Mysterious Gaps - MDC
The most crucial part of Figure 3 is the baseline (represented by the blue line), and its placement within the line box. The baseline's exact placement is dependent on the "default" font for the line box (represented by the red box), which is determined by the value of font-family for the element that contains the line box. It isn't possible for an author to change the baseline's position directly, so wherever it ends up is where it will be. The space below the baseline is referred to as "descender space" since that's where the descenders in lowercase letters like "j", "y", and "q" are drawn. Figure 4 shows what happens when we add an image to the mix.
Note where the image sits by default: its bottom edge is aligned with the baseline of the line box. This placement can be changed with vertical-align.
he other main choice is leave the image inline and alter the vertical alignment of the image with respect to the line box. For example, you could try the following:td img {vertical-align: bottom;}
This will cause the bottom edges of the images to be aligned with the bottom of the line box, instead of the baseline.
here have been many proposals to fix the problem, but one of the most promising approaches is the property line-box-contain, which has been proposed for inclusion in CSS3. Should this property be adopted, then any browser supporting it could emulate traditional "shrinkwrap" behavior without risking other layout upset with the following rule:td {line-box-contain: font replaced;} /* proposed for CSS3 */
沒有留言:
張貼留言