为什么 HTML5 DOCTYPE 会扰乱我的填充?
我有一个带有导航栏的 html5 页面。完全从头开始编码。我最近刚刚向该项目添加了一个文档类型,现在我在导航栏下获得了额外的空间。如果我删除文档类型声明,它就会恢复正常。我已经完全重置了所有内容的填充、边距等,并将其缩减为说明问题的少量代码。
该页面可以在 http://hackthetruth.org/webdesign/broken 看到
有谁知道为什么声明doctype 弄乱了 div 的高度?
I have an html5 page with a navbar. Completely scratch coded. I just recently added a doctype to the item, and now I’m getting extra space under my navbar. If I remove the doctype declaration, it goes back to normal. I have completely reset padding, margins, etc. on everything, and cut it down to the a small amount of code that illustrates the issue.
The page can be seen at http://hackthetruth.org/webdesign/broken
Does anyone know why declaring the doctype is messing with the height of a div?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
我的一个网站也遇到了同样的问题。
我找到了这个答案 此处:
“使用 HTML5 文档类型,图像会接收文本通常获取的行高属性,因此您会在它们下面得到一个“边距”。您可以将它们设置为 display:block 或 line-height:0,尽管我还没有对后者进行足够的测试以确保它是一个很好的解决方案。”
我应用了
line-height:0
到包含导航图像的。它对我有用。
I had the same problem with one of my sites.
i found this answer here:
"With an HTML5 doctype, images receive what seems to be the line-height attribute which text normally gets, and thus you get a “margin” underneath them. You can either set them to display:block or line-height:0, although I haven’t tested the latter enough to be sure it’s a good fix."
I applied the
line-height:0
to the<div>
which contained the navigation images. It did the trick for me.使用
inline-block
时,这是一个有趣、微妙但又重要的考虑因素。简短的答案是:将
ul
上的vertical-align
设置为baseline
以外的任何值。这样做的原因是内联块被视为文本,因此受到基于文本的属性的影响,例如行高和垂直对齐。
较长的答案如下:
CSS3 规范深入探讨了盒模型的工作原理(可能令人困惑)。以下是 CSS3 框规范的引用,其中我突出显示了与此问题相关的部分:
让我们检查一下流根的自动高度是多少:
线盒部分很有趣。这实际上意味着任何设置为显示为内联块的内容都受纯文本使用的隐式框布局的约束。
您现在可能可以猜到为什么设置
vertical-align
可以解决此问题,但让我们继续通过规范跟踪此问题。line-box
定义有点乏味,而且第 4.2 节 中的示例只有一点点帮助。让我们回到 CSS 2.1 规范,它在解释行框:
从这个解释中,我们看到
line-height
和vertical-align
属性与(行框的高度,即行内块元素的高度)有关。计算出来的。阅读行高的计算几乎可以清楚地了解:因此,我们的内联块元素的高度受到其隐式行框高度计算的影响,而行框高度计算又受到这些垂直对齐计算的影响。
因此,当我们不使用基线作为内联块的垂直对齐时,该框的隐式行框将缩小到其所能达到的最小尺寸。
令人困惑? ...是的。只需跳回较短的答案即可:)
This is an interesting and subtle, yet important consideration when using
inline-block
.The short answer is: set
vertical-align
on yourul
to anything other thanbaseline
.The reason this works is that inline-blocks are considered text, and thus are subjected to text-based properties such as line-height and vertical-align.
The longer answer is as follows:
The CSS3 specification goes in to some (perhaps confusing) depth around how the box model works. Here's a quote from the CSS3 box spec, in which I've highlighted the part that's relevant to this problem:
Let's check what the auto heights for flow roots are:
The line box parts are of interest. What this effectively implies is that anything set to display as inline-block is subject to the implicit box layouts that plain text uses.
You might be able to guess now why setting
vertical-align
fixes this problem, but let's continue tracing this problem through the spec.The
line-box
definition is a little lacklustre, and the example in section 4.2 is only marginally helpful.Let's go back to the CSS 2.1 spec, which does a far nicer job at explaining line boxes:
From this explanation, we see that the
line-height
andvertical-align
properties have something to do with how the heights (of line boxes, thus inline-block elements) are calculated. Reading the calculations of line-height almost make it clear:So our inline-block element's height is being affected by its implicit line box's height calculations, which are in turn subject to these vertical-alignment calculations.
So it would seem that when we don't use baseline as a vertical-align for an inline-block, the box's implicit line box will shrink to the smallest size it can.
Confusing? ...Yeah. Just jump back to the shorter answer :)
这是因为 DOCTYPE 将渲染模式更改为标准合规模式。具体来说,这意味着您现在使用的是 W3C 盒子模型,它以与怪异模式不同的方式计算块元素的宽度/高度。
了解更多此处,此处,以及此处。
It's because the DOCTYPE changes the rendering mode to Standards Compliance Mode. Specifically, this means you're using the W3C Box Model now which computes width/height for block elements differently than quirks mode.
Read more here, here, and here.
试试这个:
CSS:
try this one:
css:
我在将 XHTML4 网站升级到 HTML5 时遇到了同样的问题。我有很多这样的:
最终在图像周围有神奇的额外填充。对我来说,解决方案很简单——添加这个 css:
I had the same problem when upgrading a XHTML4 website to HTML5. I had lots of these:
Which ended up with the magical extra padding around the images. For me the solution was simple -- add this css:
由于 IE7 的问题,我从未使用过
display: inline-block
,所以我不熟悉它的怪癖。在您的情况下,似乎没有必要将其应用于 ul#pagetab ,因为它没有被内联元素包围。我只是将其转换为常规块元素。此外,由于它包含一些内联元素旁边不需要浮动的浮动元素,我只需通过display: block; 给
。ul#pagetab
一个真实的高度。溢出:隐藏;这似乎解决了您的所有问题(我无法详细说明)并提供了风格上更合适的样式。
I've never used
display: inline-block
due to the IE7 issues, so I'm not familiar with its quirks. It seems like it's unnecessary to apply it toul#pagetab
in your situation, since it's not surrounded by inline elements. I would just convert it to a regular block element. Moreover, since it contains floated elements that do not need float beside some inline elements, I would just giveul#pagetab
a real height viadisplay: block; overflow: hidden;
.This appears to resolve all your issues (which I can't account for in detail) and provides stylistically more appropriate styles.
伙计,您在该页面中有 2 个杂散的
标签。第 32 和 34 行。删除并重试。看看是否能解决问题。
Mate you have 2 stray
</div>
tags in that page. On lines 32 and 34. Delete and retry. See if that fixes it.哇。 @matt 是对的(不是在这种情况下),这是常识,但你们都错了。
伙计看看@你的CSS,你有
pagetab {background-color:#ff2d00;内边距:0px 4px;保证金:0;显示:内联块;}
pagetab ul {列表样式:无;边距:0 像素;内边距:0px 4px; display: block;}
for .....
以便第二个声明位于 #pagetab 中出现的嵌套 ul 上。你没有这些。
我把 ul 从声明中去掉了,这样它们就在正确的元素上了。现在你的 css 有 2 种与两者匹配的样式(并且也在你的通用选择器中调用(仅供参考,它位于你的 body{} 声明之上)),所以这就是 3 种样式......过度杀戮老兄。此外,那些不匹配的,您将其设置为 display:inline-block ,然后将其重置为 block...我迷失在这个逻辑中。
所以
以你为例。将两个 pagetab 样式更改为此
pagetab {
}
pagetab {
}
保存。现在把它剥掉,保存为#2。在 FF3.6 7 中它们是相同的。
如果您使用专门为解决/防止此类问题而提供的验证器以及质量保证工具(特别是在这里我谈论的是dust-me选择器书签),您将很快解决这个问题。
回到网络标准, gen ed css: *{} 是通用的,因此只要另一个声明不覆盖 * 的特殊性,它就始终有效。
用英语,如果你声明 *{margin:0;填充:0; border:none} 在页面顶部,您不必放置 margin:0;填充:0;在每一个元素上。你已经有了。
网络标准,它们会拯救你的生命。
wow. @matt is right (not in this case) and that's general knowledge, but you're all wrong.
dude look @ your css, you have
pagetab {background-color: #ff2d00; padding: 0px 4px; margin: 0; display: inline-block;}
pagetab ul {list-style: none; margin: 0px; padding: 0px 4px; display: block;}
for .....
so that second declaration is on nested ul that occur in #pagetab. you dont have any of those.
i took the ul off the declaration so they're on the correct element. now your css has 2 styles that match for both (and are also called in your universal selector (fyi, which goes above your body{} declaration)) so thats 3 styles....overkill dude. moreover, the ones not matching, you set it to display:inline-block and then reset it to block...i'm lost in this logic.
SO
take your example. change two pagetab styles to this
pagetab {
}
pagetab {
}
save it. now strip off it, save that as #2. in FF3.6 on 7 they are the same.
if you would use the validators that are provided specifically for solving/preventing issues like this, as well as qa tools (specifically here i'm talking about the dust-me selectors bookmarklet) you would resolved this in not time.
back to web standards, gen ed css: *{} is universal, so as long as another declaration doesn't override *'s specificity, it will always work.
in english, if you declare *{margin:0; padding:0; border:none} at the top of your page, you don't have to put margin:0; padding:0; on every single element. you already have.
web standards, they'll save your life.