URL 片段如何影响 CSS 布局?
比较这 3 个 URL(分别查看顶部导航栏):
- http://fast.kirkdesigns。 co.uk/blog
- 如上,但带有 url 片段 #navigation
- 如上,但带有 url 片段 #node-2655
请注意,唯一的区别是末尾的 URL 片段。
前两个页面显示得非常好(至少在 Firefox 中)。 问题出在第三个。 片段 #node-2655 将顶部导航栏推离屏幕顶部。 然后,当您向上滚动到页面顶部时,导航栏已被切成两半。 当使用任何导致导航栏在页面首次加载时超出初始视口的 URL 片段时,就会发生这种情况。
那么,使用 url 片段怎么会影响这样的 css 布局呢?!
解决方案: 如下所示,删除保存导航栏的容器元素上的溢出:隐藏解决了问题。 我很想了解为什么!
Compare these 3 URLs (look at the top navigation bar in each case):
- http://fast.kirkdesigns.co.uk/blog
- as above but with the url fragment #navigation
- as above but with the url fragment #node-2655
Note, that the only difference is the URL fragment on the end.
The first two pages display absolutely fine (in Firefox at least). It's the third one where the problem lies. The fragment #node-2655 pushes the top navbar off the top of the screen. When you then scroll back up to the top of the page, the navbar has been cut in half. This happens when using any URL fragment that causes the navbar to be out of the initial viewport when the page is first loaded.
So, how can using a url fragment affect the css layout like this?!
THE SOLUTION:
as suggested below, removing the overflow: hidden on the container element that held the navbar fixed the problem. I'd love to understand why though!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
我能够用一些 JavaScript 来解决这个问题,将主体滚动到溢出隐藏元素滚动到的位置。
I was able to solve this with some javascript to scroll the body to the position the overflow hidden element was scrolled to.
顺便说一句,上述技术通常用于提供灵活宽度的多列布局。 如今,随着固定宽度布局越来越多的评论,这一点可能变得不那么重要了——浏览器能够放大网页以查看小文本,并且固定宽度使得控制页面的排版变得更加容易,例如,设置宽度(以 em 为单位)以每行显示理想的 9 个单词,无论用户选择什么字体大小和放大倍数。
抱歉,如果这听起来不像一个答案,但它基本上是建议放弃这个旧模型并考虑转向固定宽度列(这是一个全新的主题)。
Just as a side-note, the above technique is generally used to provide flexible-width mulit-column layouts. This is probably becoming less important these days as fixed-width layouts are becoming a lot more comment - browsers are able to magnify the web page to see small text, and fixed-width makes it a lot easier to control the typography of a page, e.g. set the width (in ems) to display the ideal nine words per line regardless of what font size and magnification the user chooses.
Sorry if that does not sound like an answer, but it is basically suggesting to discard this old model and consider moving to fixed-width columns (which is a whole new subject).
抱歉,这不是一个“答案”,尽管它是对此处其他评论的回应。 这个问题简直令人瞠目结舌。 它很容易隔离(即与样式表的数量无关),并且没有适当的“解决方案”,因为没有办法实现所需的渲染。
Sorry this isn't an "answer," tho it is a response to the other comments here. This problem is just flabbergasting. It is very easy to isolate (i.e., has nothing to do with number of stylesheets), and doesn't have a proper "solution," as there is no way to achieve the desired rendering.
原因是具有大填充的列已扩展其容器,但扩展随后被隐藏,但溢出:隐藏; 但随着片段的使用,它被滚动到片段的位置,有效地砍掉了上面的任何东西。 您可以使用javascript并将scrollTop设置为0,然后将其滚动回正常位置。
基本上是一个奇怪的边缘情况,浏览器似乎不能很好地处理。
The reason is the column with the large padding has expanded it's container, but the expansion is then hidden but overflow:hidden; but with the use of the fragment it is being scrolled into the position of the fragment, effectively chopping off anything above that. You can use javascript and set scrollTop to 0 and it scroll it back to the normal position.
Basically a wierd edge case which browsers do not seem to handle very well.
我只是指出,头部链接的 30 多个样式表可能有一些奇怪的继承。 也可能没有,而且 Dan 建议这可能是一个渲染错误(可能与
:target
样式相关)。 我只是觉得值得指出的是,如果您有超过三十个样式表,您可能会开始看到一些奇怪的情况,无论发生什么情况。I'll just point out that there may be some weird inheritance from the 30+ stylesheets linked to in the head. There may not, either, and it's probably a rendering bug (possibly related to
:target
styling) that Dan suggested. I just felt it worth pointing out that if you've got more than thirty stylesheets, you likely to start seeing some weirdness, whatever else might happens.我也遇到这个问题,我想我可以看到发生了什么。
具有巨大(5678 像素)边距和填充的“列”块使该块非常高。 在 Firefox 以外的浏览器中,正值和负值相互抵消,但 FF 确实让它变得那么高 - 有点。
FF 也知道两者相互抵消,但似乎查看了 5678px 填充并确定列块伸出了 #wrapper 块的底部。 这是溢出 - 当 #wrapper 上的溢出设置为自动时,您会看到 #wrapper 的真实大小,并在侧面有一个滚动条。
将溢出设置为隐藏后,FF 会取消滚动条,但似乎仍会滚动 #wrapper 的内容,以便片段指向的项目位于页面顶部。 这是可滚动块中片段链接的正常行为,但由于没有滚动条,因此您无法再次向下滚动内容,因此看起来布局已受到片段的影响。
简而言之,我怀疑FF在这个例子中操作了一个不可见的滚动条。 这可以被认为是一个错误,但它可能是正确的行为。 能够使用 URL 片段在非溢出的固定大小块内上下滚动内容是一种可以有效地用于实现即使在没有 JavaScript 的情况下也能工作的图像“滑块”的技术。
希望有帮助。 这多年来一直困扰着我,这个解释突然让我大吃一惊。 我当前的解决方法是使用 jQuery“滚动到”插件将整个页面向下滚动到片段,因为这似乎阻止了 #wrapper 的内容在内部滚动。
您还可以将“display:hidden”从 #wrapper 中删除,但您的页面最终会长半英里。
I am having this problem too, and think I can see what is happening.
The "column" block with the massive (5678 pixel) margin and padding makes that block very tall. In browsers other than Firefox, the positive and negative values cancel each other out, but FF really does make it that tall - kind of.
FF also knows the two cancel each other out, but seems to look at the 5678px padding and decides the column block is poking out the bottom of the #wrapper block. This is overflow - and with overflow set to auto on #wrapper, you see the true size of #wrapper with a scroll-bar down the side.
With overflow set to hidden, FF takes away the scrollbar, but still seems to scroll the contents of #wrapper so that the item the fragment points to is at the top of the page. This is normal behaviour for fragment links in scrollable blocks, but since there is no scrollbar, you cannot scroll the content back down again, hence it looks like the layout has been effected by the fragment.
So in short, I suspect that FF is operating an invisible scrollbar in this example. That could be considered a bug, but it is probably correct behaviour. Being able to scroll the content up and down inside a non-overflowed fixed-sized block using URL fragments, is a technique that can be used effectively to implement image "sliders" that work even in the absence of JavaScript.
Hope that helps. This has been puzzling me for years, and this explanation suddenly struck me out the blue. My current workaround for this is to use jQuery "scroll to" plugin to scroll the whole page down to the fragment, as this seems to prevent the contents of #wrapper from scrolling internally.
You can also take "display: hidden" off #wrapper, but your page then ends up half a mile long.
我想说这是 FireFox 中的一个渲染错误,因为它在 Opera 中没问题。 无论如何,锚点不应该像你所说的那样改变 CSS(除非你使用 jQuery 或其他东西)。
I'd say it's a rendering bug in FireFox as it's fine in Opera. There shouldn't be anyway an anchor would change the CSS like you say (unless you are using jQuery or something).
删除 css_75afd7072eaf4096aaebf60674218e31.css 中
#main
上的overflow:hidden
Remove the
overflow:hidden
on#main
in css_75afd7072eaf4096aaebf60674218e31.css