为什么 HTML5 DOCTYPE 会扰乱我的填充?

发布于 2024-09-05 01:26:38 字数 297 浏览 6 评论 0原文

我有一个带有导航栏的 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

燃情 2024-09-12 01:26:38

我的一个网站也遇到了同样的问题。
我找到了这个答案 此处

“使用 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.

云柯 2024-09-12 01:26:38

使用 inline-block 时,这是一个有趣、微妙但又重要的考虑因素。

简短的答案是:将 ul 上的 vertical-align 设置为 baseline 以外的任何值。

这样做的原因是内联块被视为文本,因此受到基于文本的属性的影响,例如行高和垂直对齐。


较长的答案如下:

CSS3 规范深入探讨了盒模型的工作原理(可能令人困惑)。以下是 CSS3 框规范的引用,其中我突出显示了与此问题相关的部分:

9.5。 “内联块”或浮动、非替换元素

...height 的使用值是计算值,
除非是'auto',当使用的值由“'Auto'定义时
流根的高度。”

让我们检查一下流根的自动高度是多少:

9.10。流根的“自动”高度

在某些情况下(请参阅前面的部分),
元素计算如下:

  • 如果只有内联子级,则高度是最顶部行框的顶部与行框底部之间的距离
    最底下的行框。

...

线盒部分很有趣。这实际上意味着任何设置为显示为内联块的内容都受纯文本使用的隐式框布局的约束。

您现在可能可以猜到为什么设置 vertical-align 可以解决此问题,但让我们继续通过规范跟踪此问题。

line-box 定义有点乏味,而且第 4.2 节 中的示例只有一点点帮助。

让我们回到 CSS 2.1 规范,它在解释行框:

包含形成线条的框的矩形区域称为线条框...[其高度]由线条高度计算部分中给出的规则确定。

从这个解释中,我们看到 line-heightvertical-align 属性与(行框的高度,即行内块元素的高度)有关。计算出来的。阅读行高的计算几乎可以清楚地了解:

...如果[行框]“顶部”或“底部”对齐,则必须对齐它们以最小化行框高度。

因此,我们的内联块元素的高度受到其隐式行框高度计算的影响,而行框高度计算又受到这些垂直对齐计算的影响。

因此,当我们不使用基线作为内联块的垂直对齐时,该框的隐式行框将缩小到其所能达到的最小尺寸。

令人困惑? ...是的。只需跳回较短的答案即可:)

This is an interesting and subtle, yet important consideration when using inline-block.

The short answer is: set vertical-align on your ul to anything other than baseline.

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:

9.5. ‘Inline-block’ or floating, non-replaced elements

... The used value of height is the computed value,
unless that is ‘auto’, when the used value is defined by “‘Auto’
heights for flow roots.”

Let's check what the auto heights for flow roots are:

9.10. ‘Auto’ heights for flow roots

In certain cases (see the preceding sections), the height of an
element is computed as follows:

  • If it only has inline-level children, the height is the distance between the top of the topmost line box and the bottom of the
    bottommost line box.

...

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:

The rectangular area that contains the boxes that form a line is called a line box ... [its height] is determined by the rules given in the section on line height calculations.

From this explanation, we see that the line-height and vertical-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:

...In case [line boxes] are aligned 'top' or 'bottom', they must be aligned so as to minimize the line box height.

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 :)

阳光的暖冬 2024-09-12 01:26:38

这是因为 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.

蓝颜夕 2024-09-12 01:26:38

试试这个:

CSS:

html * { margin:0; padding:0; }

try this one:

css:

html * { margin:0; padding:0; }
秋千易 2024-09-12 01:26:38

我在将 XHTML4 网站升级到 HTML5 时遇到了同样的问题。我有很多这样的:

<a><img></a>

最终在图像周围有神奇的额外填充。对我来说,解决方案很简单——添加这个 css:

img { vertical-align: top; }

I had the same problem when upgrading a XHTML4 website to HTML5. I had lots of these:

<a><img></a>

Which ended up with the magical extra padding around the images. For me the solution was simple -- add this css:

img { vertical-align: top; }
夏尔 2024-09-12 01:26:38

由于 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 to ul#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 give ul#pagetab a real height via display: block; overflow: hidden;.

This appears to resolve all your issues (which I can't account for in detail) and provides stylistically more appropriate styles.

会傲 2024-09-12 01:26:38

伙计,您在该页面中有 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.

作业与我同在 2024-09-12 01:26:38

哇。 @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 {

background-color: #ff2d00;
padding: 0px 4px;
margin: 0;

}

pagetab {

list-style: none;
margin: 0px;
padding: 0px 4px;
display: block;

}

保存。现在把它剥掉,保存为#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 {

background-color: #ff2d00;
padding: 0px 4px;
margin: 0;

}

pagetab {

list-style: none;
margin: 0px;
padding: 0px 4px;
display: block;

}

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文