Xhtml CSS – WL

Safari/Chorme/Webkit-based Browsers CSS hack redux

王万林 — Thu, 23 Jul 2009 01:21:52 +0000

In March 2007, I wrote about a Safari CSS hack called the “Pound Safari Post Semicolon” hack (coined by Tony at Simian Design). As of Safari 3.0, this hack no longer works. However, there is a way to target Safari 3.0:

@media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari 3.0 and Chrome rules here */
}

As always, the disclaimer: nobody condones the use of hacks, but we all (well, most of us) have to make use of them at least once in a while. The above code targets both Safari 3.0 and Google’s Chrome. Hopefully, it will be a future-proof hack, since the -webkit part of the selector will probably not be adopted by other browsers.

Example: The following code set the background color of the element red in all browsers and then resets it to blue in Safari 3.0 and Chrome.
body { background-color: red; } @media screen and (-webkit-min-device-pixel-ratio:0) { body { background-color: blue; } }
[demo]

Tested on Mac OS X version 10.5.1 with Safari version 3.0.4 (5523.10.6) and Mozilla Firefox version 2.0.0.11. Tested on Windows XP Professional Version 2002 SP 2 with Mozilla Firefox version 2.0.0.11, Opera 9.10, and Microsoft Internet Explorer 6. Hack from CSS, JavaScript and XHTML Explained.

Update 2008-11-26: Since this hack targets Webkit-based browsers, Chrome is also affected. At the original time of writing, it also affected Opera (9.10); it hasn’t since 9.50. The post copy has been updated to reflect these developments.

This article comes from :Safari CSS hack redux http://themechanism.com/blog/2008/01/08/safari-css-hack-redux/

Having “layout”

王万林 — Sun, 29 Mar 2009 17:10:21 +0000

Having “layout”

We all know that browsers can be buggy, and IE on Windows seems buggier than most. One of the reasons IE/Win behaves differently from other browsers is because the rendering engine uses an internal concept called “layout.” Because layout is a concept particular to the internal working of the rendering engine, it is not something you would normally need to know about. However, layout problems are the root of many IE/Win rendering bugs, so it is useful to understand the concept and how it affects your CSS.

What is “layout”?

Internet Explorer on Windows uses the layout concept to control the size and positioning of elements. Elements that are said to “have layout” are responsible for sizing and positioning themselves and their children. If an element does not “have layout,” its size and position are controlled by the nearest ancestor with layout. The layout concept is a hack used by IE’s rendering engine to reduce its processing overhead. Ideally all elements would be in control of their own size and positioning. However, this causes huge performance problems in IE. As such, the IE/Win development team decided that by applying layout only to those elements that actually needed it, they could reduce the performance overhead substantially.

Elements that have layout by default include

body
html in standards mode
table
tr, td
img
hr
input, select, textarea, button
iframe, embed, object, applet
marquee

The concept of layout is specific to IE on Windows, and is not a CSS property. Layout cannot be explicitly set in the CSS, although setting certain CSS properties will give an element layout. It is possible to see if an element has layout by using the JavaScript function, hasLayout. This will return true if the element has layout and false if it doesn’t. hasLayout is a read-only property and so cannot be set using JavaScript.

Setting the following CSS properties will automatically give that element layout:

position: absolute
float: left or right
display: inline-block
width: any value
height: any value
zoom: any value (Microsoft property—doesn’t validate)
writing-mode: tb-rl (Microsoft property—doesn’t validate)

What effect does layout have?

Layout is the cause of many IE/Win rendering bugs. For instance, if you have a paragraph of text next to a floated element, the text is supposed to flow around the element. However, in IE 6 and below on Windows, if the paragraph has layout—by setting the height, for example—it is constrained to a rectangular shape, stopping the text from flowing around the float (see Figure below).

Figure Above: Text is supposed to flow around adjacent floated elements. However, on IE/Win, if the text element has layout, this doesn’t happen.

Another problem revolves around how elements with layout size themselves. If the content of an element becomes larger than the element itself, the content is supposed to flow out of the element. However, in IE 6 and below on Windows, elements with layout incorrectly grow to fit the size of their contents (see Figure below).

Figure Above: Elements with layout incorrectly grow to fit their contents.

This means that width in IE/Win actually acts more like a min-width. This behavior is also the cause of many broken floated layouts in IE/Win. When the content of a floated box incorrectly forces the width of the box to grow, the box becomes too big for the available space and drops below the other floated elements.

Common bugs and their fixes

One of the greatest skills any CSS developer can have is the ability to spot common browsers bugs. By knowing the various elements that conspire to cause these bugs, you can spot and fix them before they ever become a problem.

Double-margin float bug

One of the most common and easy-to-spot bugs is the double-margin float bug in IE 6 and below. As the name suggests, this Windows bug doubles the margins on any floated elements (see Figure below).

Figure Above: Demonstration of IE/Win’s double-margin float bug

This bug is easily fixed by setting the display property of the element to inline. As the element is floated, setting the display property to inline won’t actually affect the display characteristics. However, it does seem to stop IE 6 and below on Windows from doubling all of the margins. This is such a simple bug to spot and fix: every time you float an element with horizontal margins, you should automatically set the display property to inline.

Three-pixel text jog bug

Another very common IE 5-6/Win bug is the 3-pixel text jog bug. This bug manifests itself when you have text adjacent to a floated element. For instance, say you had an element floated left and you don’t want the text in the adjacent paragraph to wrap around the float.

You would do this by applying a left margin to the paragraph, the same width as the image:

.myFloat { float: left; width: 200px; } p { margin-left: 200px; }

When you do this, a mysterious 3-pixel gap appears between the text and the floated element. As soon as the floated element stops, the 3-pixel gap disappears (see Figure Below).

Figure Above: Demonstration of the IE 5-6/Win’s 3-pixel text jog bug

Fixing this bug requires a two-pronged attack. First, the element containing the text is given an arbitrary height. This forces the element to have layout, which seemingly removes the text jog. Because IE 6 and below on Windows treats height like min-height, setting a tiny height has no effect on the actual dimensions of the element in that browser. However, it will affect other browsers, so the Holly hack is used to hide this rule from everything other than IE 6 and below on Windows:

/* Hide from IE5-Mac. Only IE-Win sees this. */ * html p { height: 1%; } /* End hide from IE5/Mac */

Unfotunately, doing this causes another problem. As you learned earlier, elements with layout are constrained to a rectangular shape and appear next to floated elements rather than underneath them. The addition of 200 pixels of padding actually creates a 200-pixel gap between the floated element and the paragraph in IE 5-6/Win. To avoid this gap, you need to reset the margin on IE 5-6/Win back to zero:

/* Hide from IE5-Mac. Only IE-Win sees this. */ * html p { height: 1%; margin-left: 0; } /* End hide from IE5/Mac */

The text jog is fixed, but another 3-pixel gap has now appeared, this time on the floated image. To remove this gap, you need to set a negative 3-pixel right margin on the float:

/* Hide from IE5-Mac. Only IE-Win sees this. */ * html p { height: 1%; margin-left: 0; } * html .myFloat { margin-right: -3px; } /* End hide from IE5/Mac */

This will fix the problem if the floated element is anything other than an image. However, if the floated element is an image, there is one last problem to solve. IE 5.x/Win adds a 3-pixel gap to both the left and the right of the image, whereas IE 6 leaves the image’s margins untouched. As such, another hack is required to remove the 3-pixel gap from IE 5.x/Win only:

/* Hide from IE5-Mac. Only IE-Win sees this. */ * html p { height: 1%; margin-left: 0; } * html img.myFloat { margin: 0 -3px; margin: 0; } /* End hide from IE5/Mac */

This solves the problem, but in a really nasty and complicated way. As such, if possible you would be better off splitting these rules up into separate, browser-specific stylesheets. If you did this, you could have one stylesheet for IE 5.x on Windows:

p { height: 1%; margin-left: 0; } img.myFloat { margin: 0 -3px; }

And another for IE 6:

p { height: 1%; margin-left: 0; } img.myFloat { margin: 0; }

IE 6 peek-a-boo bug

Another strange and infuriating bug is IE 6’s peek-a-boo bug, so called because under certain conditions text will seem to disappear, only to reappear when the page is reloaded. This happens when there is a floated element followed by some nonfloated elements and then a clearing element, all contained within a parent element that has a background color or image set. If the clearing element touches the floated element, the nonfloated elements in-between seem to disappear behind the parent element’s background color or image, only to reappear when the page is refreshed (see Figure Below).

Figure Above: Demonstration of IE 6’s peek-a-boo bug

Luckily, there are a number of ways you can combat this bug. The easiest way is probably to remove the background color or image on the parent element. However, this is often not practical. Another way is to stop the clearing element from touching the floated element. The bug doesn’t seem to manifest itself if the container element has specific dimensions applied. The bug also doesn’t manifest itself if the container is given a line height. Lastly, setting the position property of the float and the container to relative also seems to alleviate the problem.

Absolute positioning in a relative container

The last major browser bug I am going to cover involves absolutely positioned elements within a relatively positioned container. You learned in earlier chapters how useful nesting an absolutely positioned element in a relative container can be. However, IE 6 and below has a number of bugs when you use this technique.

These bugs arise from the fact that relatively positioned elements don’t gain IE/Win’s internal hasLayout property. As such, they don’t create a new positioning context and all of the positioned elements get positioned relative to the viewport instead (see Figure Below).

To get IE 6 and below on Windows to behave correctly, you need to force the relatively positioned container to have layout. One way to do this is to explicitly set a width and height on the container. However, you will often want to use this technique when you don’t know the width and height of the container, or when you want one or both of these properties to be flexible.

Instead, you can use the Holly hack to supply an arbitrary height to the container. This will give the container layout, but because elements in IE 6 and below incorrectly expand to fit their contents, the actual height won’t be affected.

/* Hides from IE-Mac */ * html .container { height: 1%; } /* End hide from IE-Mac */

Stop picking on Internet Explorer

Internet Explorer isn’t the only buggy browser around, so you may wonder why I have been focusing my attentions on IE bugs. Don’t worry, it’s not another case of Microsoft bashing; there are good reasons for this focus.

First, IE has by far the biggest browser market share. With so many copies in circulation, IE bugs tend to get found and documented pretty quickly. When a major CSS bug gets discovered in IE, scores of developers will be on the case trying to find a fix or a workaround. Because of this popularity, there are more well-documented bugs and fixes for IE than any other browser.

The other major issue is the pace of development. Browsers such as Firefox, Safari, and Opera are constantly being updated, with new builds appearing with remarkable frequency. Almost as soon as a bug is discovered, it is fixed and a new version of the browser released. Because of this, any Firefox or Safari bug I talk about now will probably have been fixed by the next revision.

This pace of development is excellent, but it does have its own problems. Rather than having two or three versions of a browser to deal with, you may have 20 or 30. You can never be sure if your users have the latest version, and this makes testing extremely difficult. IE, on the other hand, didn’t see a major revision for about 5 years. As such, there has been much more time for bugs to surface and much more impetus to find a fix.

Luckily, IE 7 promises to be a much more compliant browser. Many of the better known IE bugs have been addressed, along with increased support for advanced CSS 2.1 selectors such as the child and attribute selectors. As with all browsers, new bugs will surface, and IE 7 will be far from perfect. However, the faster people can be convinced to upgrade to modern browsers such as IE 7 and Firefox, the quicker older browsers such as IE 5.0 can be retired.

In the interim, it is worth exploring Dean Edwards’ excellent IE 7 patch. This series of JavaScript files aims to bring IE 5-6/Win up to speed with IE 7. This includes improved selector implementation and numerous bug fixes. For more information about this patch, visit http://dean.edwards.name/IE7/.

Summary

In this chapter, you have learned some important techniques for tracking down and squashing CSS bugs. You have learned about IE on Windows internal hasLayout property and how this is the root of many IE/Win browser bugs. Finally, you have learned about some of the most common browser bugs and how to fix them.

Next you will see how all of this information can be put together, through two stunning case studies created by two of the best CSS designers and developers of our time.

拥有布局 IE haslayout

王万林 — Sun, 29 Mar 2009 17:09:21 +0000

找们那知道浏览器有bug，而且Windows上的lE的bug 似乎比太多数浏览器都多。IE/Win的衣现与其他浏览器不同的原因之一是，显示引擎使用一个称为布局(layout)的内部概念。因为布均是一个专门针对显示引擎内部工作方式的概念，所以一般悄况下不需要了解它。但是，布局问题是许多IE/Win显示bug的根源，所以理解这个概念以及它如何影响CSS是有捂助的。

什么是布局

Windows 上的IE 使用布局概念来控制元素的尺寸和定位。那些称为拥有布局(have layout)的元素负责本身及其子元素的尺寸和定位。如果一个元旦在没有拥有布局，那么它的尺寸和位置由最近的拥有布局的祖先元素控制。

IE 显示引擎利用布局概念减少它的处理开销。在理想悄况下，所有元素都控制自己的尺寸和定位。但是，这会在IE中导致很大的性能问题。因此，IE/Win 开发团队决定只将布局应用于实际需要它的那些元素，这样就可以充分地减少性能开销。

在默认情况下拥有布局的元素包括:

body
标准模式中的 html
table
tr, td
img
hr
input, select, textarea, button
iframe, embed, object, applet
marquee

布局概念是Windows 上的I E 特有的，而且它不是CS S 属性.尽管某些CSS 属性会使元ffi拥有布局，但是在CSS 巾无法显式地设宣布局.可以使用JavaScript 函数hasLayout 查看一个元亲是否拥有布局.如果元素拥有布局，这个函数就返回true ; 否则返回falseo hasLayout 是一个只读属性，所以无法使用JavaScript 选行设置.

设宜以下CSS 属性会自动地使元亲拥有布局·

position: absolute
float: left or right
display: inline-block
width: any value
height: any value
zoom: any value (Microsoft property—doesn’t validate)
writing-mode: tb-rl (Microsoft property—doesn’t validate)

布局有什么效果?

布局是许多IElWin 显示bug 的根源。例如，如果一个文本段落靠谷一个浮动元索，那么期望文本围绕这个元索。但是，在Windows 上的1E 6 和更低版本巾，如果段落拥有布局(例如，由于设置了高度).那么它就被限制为矩形，因此阻止文本国绕浮动元素〈见图9-5).

Figure Above: 期望文本围绕相邻的浮动元素，但是，在IE/Win上，如果文本元素拥有布局，就不会这样显示。

这会导致浮动布间的各种问题更糟的是，许多人使用IE 作为主浏览器，他们会俯误地认为这才是正确的表现，在其他浏览器以不同方式处理泞-动元素时，他们反而会这必不解.

另-个问题涉及拥有布局的元素如何确定自己的尺，如果元亲的内容变得比元素本身大，那么期望元素流出到元素外.但是，在Windows 上的IE 6 和更低版本中，拥有布局的元素会销误地扩展以便适应内容的尺寸(见圈9-6).

Figure Above: 拥有布局的错误的扩展以便适应内容

这意味IE/Win中的width 实际上更像min-width. 这种行为也是在IE/Win中许多浮动布局被破坏的原因。当浮动框的内容错误地迫使框的宽度增加时，框对于可用空间来说太大了，因此下降到其他浮动元素在下面.

其他问题包括:

拥有布局的元素不进行收缩。
布局元亲对浮动进行自动消理。
相对定位的元素不获得布局。
在拥有布局的元素之间空白地不叠加。
在不拥有布局的块级链接上，单击区域只覆盖文本。

在下一节中，我们将讨论一些最常见的浏览器bug. 你会注意到对于Windows 上的IE的许多修复方法都涉及通过设置属性迫使元素拥有布局。实际上，如果遇到一个IE/Wi n bug，首先应该做的事情之一就是尝试通过应用规则迫使元崇拥有布局。看看这是否可以修复问题。

如果希忘进一步了解IE的内部hasLayout属性，我建议阅读http://tinyurl.com/acg78上的”On Having Layout”。【我的翻译文章在这里IE Haslayout 详解】

常见bug及其修复方法

CSS 开发人员最重要的技能之一是发现常见浏览器bug的能力。通过了解导致这些bug 的各种元索，可以在它们造成问题之前发现并且修复它们。

双空白边浮动bug

最常见且最容易发现的bug 之一是IE6和更低版本中的双空白边浮动bug。顾名思义，这个Windows bug使任何浮动元素上的空白边加倍(见图9-7)。

Figure Above: IE/Win 的双空白浮动bug示意阁

这个bug 很容易修复，将元素的display 属性设置为inline 就行了.因为元素是浮动的，将display 属性设置为inline 实际上不会影响显示方式。但是，这似乎会阻止Windows 上的IE6和更低版本将所有空白地加倍。这是一个非常容易发现和修复的bug : 每当对具有水平空白边的元素进行浮动时，都应该很自然地将display 属性设置为inline。

3像素文本偏移bug

另一个非常常见的I E 5-61Win bug 是3像素文本偏移bug。当文本与二个浮动元示相邻时，这个bug 就会表现出来。例如，假设将-个元素向左浮动，并且不希望相邻段落中的文本围绕浮动元素。你可能会在段落上应用一个左空白边，其宽度等于浮动元素的宽度:

.myFloat { float: left; width: 200px; } p { margin-left: 200px; }

如果这么做，在文本和浮动元素之间就会出现一个莫名其妙的3像素间隙。(见图9-8) 。

Figure Above: IE 5-6/Win 的3像素文本偏移bug示意图

修复这个bug 需要双管齐下。首先，给包含文本的元素设置任意的高度。这会迫使元素拥有布局，这在表面上会消除文本偏移。因为Windows 上的IE6和更低版本将height作为min-height那样对待，所以设置一个小的高度并不会影响元素在这些浏览器巾的实际尺寸。但是，这会影响其他浏览器，所以要使用Holly招数对除了Windows 上的IE6 和更低版本之外的所有其他浏览器隐藏这个规则，

/* Hide from IE5-Mac. Only IE-Win sees this. \*/ * html p { height: 1%; } /* End hide from IE5/Mac */

不幸的是，这么做会导致另一个问题。正如在前面学到的，拥有布局的元素被限制为矩形的，并且出现在浮动元索的旁边而不是它们的下面。添加200像素的空白边实际上会在IE 5-6/Win 中在浮动元素和段落之间产生200像素的间隙。为了边免这个问隙，需要将IE 5-6/Win 上的空白边重新设置为零:

/* Hide from IE5-Mac. Only IE-Win sees this. \*/ * html p { height: 1%; margin-left: 0; } /* End hide from IE5/Mac */

文本偏移被修复了，但是现在另一个3像亲间隙出现了，这一次是在浮动元素上。为了去掉这个问隙，需要在浮动元素上设置一个负值的3像素右空白边：

/* Hide from IE5-Mac. Only IE-Win sees this. \*/ * html p { height: 1%; margin-left: 0; } * html .myFloat { margin-right: -3px; } /* End hide from IE5/Mac */

如果浮动元素是除了图像之外的任何其他东西，那么这个问题己经修复了。但是，如果浮动元旦在是图像，那么还有放后一个问题需要解决。 IE 5.x/Win在图像的左右都添加3像亲的间隙。而IE6不改变图像的空白边。因此，需要用另一个招术在IE 5.x/Win 上去掉3 像素的问隙:

/* Hide from IE5-Mac. Only IE-Win sees this. \*/ * html p { height: 1%; margin-left: 0; } * html img.myFloat { margin: 0 -3px; ma\rgin: 0; } /* End hide from IE5/Mac */

这会解决问题，但是采用的方式很难看而且太复杂。因此，如果可能的话，最好将这些规则分别放进单独的浏览器特定的样式表中。如果这样做，用于Windows 上的lE 5.x的样式表如下：

p { height: 1%; margin-left: 0; } img.myFloat { margin: 0 -3px; }

用于IE 6的样式表如下:

p { height: 1%; margin-left: 0; } img.myFloat { margin: 0; }

IE 6躲躲猫bug

另一个奇怪而且很烦人的 bug 是IE6 的躲躲猫(peek-a-boo) bug，之所以起这个名称是因为在某些条件下文本看起来消失了，只有在前新装载页面时才再度出现。出现这个bug 的条件是:一个浮动元素后面跟着一些非浮动元素，然后是一个清理元素，所有这些元素都包含在一个设置了背景颜色或阅像的父元束中。如果清理元素碰到了浮动元素，那么中间的作浮动元素看起来消失了，隐藏到了父元素的背景颜色或图像后面，只有在刷新页面时才重新出现(见图9-10)。

Figure Above:IE 6的躲躲猫bug示意图

相对容器中的绝对定位

我要讨论的段后一个主要浏览器bug涉及相对定位容器中的绝对定位元素。在前面的章节中你学到将绝对定位的元素嵌套在相对容器中是多么有用。但是，IE 6和更低版本在使用这种技术时有许多bug。

这些bug 的原因在于相对定位的元素没有获得IE/Win 的内部hasLayout 属性。因此，它们不创建新的定位上下文，所有绝对定位元素相对于窗口进行定位(见图9-11)。

Figure Above:IE5.x对相对容器中的绝对定位元素的定位方式不正确

为了使Windows 上的IE 6和更低版本的表现正确。需要迫使相对应位的容器拥有布局。一种方法是在容器上显式地设置width 和height。但是，常常希望在不知道容器的width 和height的况下，或者在需要这些属性保持灵活的情况下使用这种技术。

可以使用Holly 招数为容器提供一个的高度。这会让容器拥有布局。但是因为IE 6和更低版本中的元素会不正确地扩展以适应它们的内容，所以设置小的高度不会影响实际高度。

/* Hides from IE-Mac \*/ * html .container { height: 1%; } /* End hide from IE-Mac */

停止对IE 的批评

IE 并不足惟一一种有bug 的浏览器，所以你可能会奇怪我为什么只关注IE bug。不必担心，我找并不是专门和微软过不去，这么做是有理由的。

首先， IE 目前占有最大的浏览器市场份额。因为有许多人在使用IE，IE bug 往往很快被发现而且很好地记录下来。当在IE中发现一个重大的CSS bug时，许多开发人员会尝试寻找修复方法或解决方案。由于IE的流行程度，被记录并修复的IE bug比其他任何浏览器都要多.

另一个主要问题是开发的节奏。Firefox、Safari和Opera等浏器不断地进行更新，新版本以非常高的频率出现。 bug 几乎一经发现就被修复了，并且发布浏览器的新版本.因此，现在讨论的任何Firefox或Safari bug 可能已经被下一个修订版修复了。

如此高的开发节奏确实很棒，但是也有自己的问题。开发人员要应付的浏览器版本不是两三个，而是20或30个。你无法确定用户是否使用最新的版本，这使测试变得极其困难。另一方面，IE差不多5年没有发布主要修订版了。因此，bug 有更多的时间可以暴露出来，开发人员也有更强的寻找修复方法的动力。

幸运的是，IE 7承诺将成为更符合标准的浏览器。许多著名的IE bug 已经被解决，而且对高级CSS 2.1 选择器（比如子选择器和属性选择器）的支持也在增加。与所有浏览器一样，新的bug也会出现，IE 7远不是完美的。但是，人们越快地升级到IE 7和Firefox 等现代浏览器，IE 5.0等老式浏览器就会越快地退役。

在这个过渡时期，可以考虑使用Dean Edwards 的IE 7 补丁。这是一系列JavaScript 文件，它们使IE 5-6/Win 能够接近IE 7的水平.这包括改进的选择器实现和许多bug 修复。关与这个补丁的更多信息，请访问http://dean.edwards.name/IE7/。