因此，我使用 sIFR（版本 3，修订版 436）来替换导航中的元素，一切都很漂亮。但是当我打开 sIFR.useStyleCheck 来检测 CSS 负载时，Safari 4 中的一切都变得不正常。通过不正常，我的意思是插入的虚拟 div 似乎在其 42px 的左边距中徘徊，并且它抛出了 sIFR 的文本所以它不在正确的水平位置，或者在应该的时候没有换行，等等。我的浏览器窗口中也有一个水平滚动条，这总是很有趣。但是，如果我调整浏览器窗口的大小，一切都会重新绘制并且再次正常。
我知道这在 Firefox 中不会发生。它似乎确实会影响 Opera。尚未在 Safari 3 中进行测试。天知道当我在 IE 中启动它时会发生什么，但我猜它实际上会没事的，因为 Mark (Wubben) 说 sIFR.useStyleCheck 主要是为了提高 Safari 和 Opera 中的性能。
有什么建议么？我寻找一种强制重绘的方法，但无法弄清楚。如果我这样做了，那将不是一个非常优雅的解决方案。
对于任何关心的人，我发现问题在于我的 sIFR.css 在我的typography.css 之前加载。之所以重要，是因为当您使用 sIFR.useStyleCheck 时，sIFR 会等待进行任何替换，直到它检测到它插入的虚拟 div 的左边距为 42px。42px 的边距当然是由 sIFR.css 设置的。一旦检测到 42px 的左边距，sIFR 就会愉快地替换您的文本，即使您的 CSS 的其余部分首先指示文本如何定位/样式尚未加载。替换完成后，您的typography.css 不会改变它们——除非您调整浏览器窗口的大小并重新绘制 sIFR。
所以我的第一个猜测是虚拟 div 以某种方式扔掉了东西，这根本不是。虚拟 div 已成功删除并且不会更改任何内容。
有趣的是不同的浏览器处理 CSS 的方式不同。很明显，Firefox 必须先处理所有的 CSS，然后才能让 sIFR 如何设置虚拟 div 的样式。但是对于 Opera 和 Safari，以正确的顺序加载 CSS 至关重要，因为 sIFR 会在样式发生时得到风声。所以，这解决了上面在 Safari 和 Opera 中描述的“怪异”，但我仍然在 Opera 中遇到了一些神秘的样式问题……但那是另一回事了。