I'm trying to use scroll snapping via the CSS scroll-snap-type and scroll-snap-align properties, but no matter what I do I end up making non-snapping elements unreachable.
In the example below, for example. the paragraphs (<p>) are all reachable and even snapping just fine, but the header (<h1>) becomes unreachable because when I try to scroll up to view it, I just get snapped back down to the first paragraph beneath it.
html {
scroll-snap-type: y mandatory;
height: 100vh;
overflow: scroll;
}
p {
background: pink;
padding: 3rem 4rem;
scroll-snap-align: start;
}
<h1>THIS IS UNREACHABLE</h1>
<p>1.1</p>
<p>1.2</p>
<p>1.3</p>
<p>1.4</p>
<p>1.5</p>
<p>1.6</p>
<p>2.1</p>
<p>2.2</p>
<p>2.3</p>
<p>2.4</p>
<p>2.5</p>
<p>2.6</p>
<p>3.1</p>
<p>3.2</p>
<p>3.3</p>
<p>3.4</p>
<p>3.5</p>
<p>3.6</p>
My question: Is there a way to achieve CSS scroll snapping without making non-snapping elements unreachable?
further notes:
You'll probably notice that I'm using scroll-snap-type on the <html> tag rather than using a container, which is apparently more typical. That's because using a container makes things even worse, introducing multiple scrollbars and confusion over whether the container or the <body> is being scrolled. Also, for the scroll-snapping design I'm trying to achieve to function, I would need to force the container itself to snap to the top of the viewport, which just brings us back to using <body>, or, since that simply doesn't work (don't know why), <html>.
It's not really possible. Because the scroll snapping API wasn't meant to be used with mixed non-snapping elements. I ran into the same issue myself, hence why I ended up on your entry. One thing that helps a little is to use proximity instead of mandatory on the html element.
Obviously that yields a different scroll feel that you might be going for. And it has its own shares of issues; such as when you refresh the page it might still scroll down to the first <p> element because it happens to be close enough for the proximity value to trigger. To kind of avoid this you can unset snapping on the first and last child with pseudo selectors.
In the demo below it looks like it might work, but this is where things go from bad to really bad. Let's say you want to have some content below the <p>'s that also doesn't snap. If you resize the window, while at the very bottom you'll notice that the window jumps back up to the last registered snap point. Same thing will happen to any layout shifts such as opening and closing an accordion, or browsing on a mobile device with a shifting url bar. Not ideal.
So in terms of viability; mixing snap enabled together with non-snapping elements is a rabbit hole of despair, dont do it.
html {
scroll-snap-type: y proximity;
height: 100vh;
overflow: scroll;
}
p:first-of-type {
scroll-snap-align: unset;
}
p {
background: pink;
padding: 3rem 4rem;
scroll-snap-align: start;
}
h2 { height: 150vh; }
<h1>THIS IS UNREACHABLE</h1>
<p>1.1</p>
<p>1.2</p>
<p>1.3</p>
<p>1.4</p>
<p>1.5</p>
<p>1.6</p>
<p>2.1</p>
<p>2.2</p>
<p>2.3</p>
<p>2.4</p>
<p>2.5</p>
<p>2.6</p>
<p>3.1</p>
<p>3.2</p>
<p>3.3</p>
<p>3.4</p>
<p>3.5</p>
<p>3.6</p>
<h2>content below</h2>
Related
The bounty expires in 4 days. Answers to this question are eligible for a +50 reputation bounty.
rbhalla wants to draw more attention to this question.
Here is an example: https://codesandbox.io/s/spring-wood-0bikbb?file=/src/styles.css
To replicate:
focus the input at the top
scroll all the way to the bottom, click on an empty space
notice that the screen jumps back up to the top to the snap target
What I've determined seems to be contributing to this:
The scroll window being ontop of a space with no snap target in proximity
The input width being resized on focus/blur
What the demo does:
On focus/blur of the input, a class is attached/removed from the container element.
That class changes the width of the container
The input container is the only element with scroll-snap-align set.
Question: what is causing this jump to occur, and how do I stop it?
It seems you have stumbled onto a chromium bug. Nowadays they are a little less common, but still not that rare. We tend to find them in the edge-cases of new(-ish) features and there is no other choice but to work around them.
Here's the minimal reproducible example, which replicates your issue in Chrome, but not in Safari nor Firefox (macOS).
.main {
scroll-snap-type: y proximity;
height: 100vh;
overflow-y: scroll;
background: green;
}
.spacer {
height: 200%;
}
input {
width: 25%;
scroll-snap-align: start;
}
input:focus {
width: 50%;
}
<div class="main">
<input type="text" />
<div class="spacer"></div>
</div>
If you want to be a good citizen of the web, your next step would be to check on the chromium bug tracker whether that bug has been reported already or not, and if needed file an issue yourself https://bugs.chromium.org/p/chromium/issues/list
As for your practical case of what to do to avoid it? As long as it is not fixed you'll need to find a workaround. This could include (not tested but likely to work):
only enabling scroll snapping under certain conditions (pretty standard workaround for other scroll-snap related issues chrome has had for the past few years)
force the scroll position on input blur
don't resize the input
add a snap target below the input
change your design / functional requirements
In this fiddle, why is B falling out of the yellow container?
http://jsfiddle.net/en7qfto1/
It does not happen in Chromium.
Is that a Firefox bug?
This is the code:
<style>
.a, .b
{
display: inline-block;
background: lightblue;
}
.b
{
float: right;
}
.c
{
background: yellow;
white-space: nowrap;
}
</style>
<div class=c>
<a class=a>A</a>
<a class=b>B</a>
</div>
Yes, this is a bug. You can find the Bugzilla ticket here.
David Baron points out the cause, which indicates in the code itself that this is due to a known limitation:
The cause is this code in nsLineLayout::ReflowFrame:
if (psd->mNoWrap) {
// If we place floats after inline content where there's
// no break opportunity, we don't know how much additional
// width is required for the non-breaking content after the float,
// so we can't know whether the float plus that content will fit
// on the line. So for now, don't place floats after inline
// content where there's no break opportunity. This is incorrect
// but hopefully rare. Fixing it will require significant
// restructuring of line layout.
// We might as well allow zero-width floats to be placed, though.
availableWidth = 0;
}
I wonder whether the right thing to do is:
not manipulate the available width at all, or
make the available width infinite, since the nowrap content is never going to wrap around the float anyway
(In theory, the correct solution is not to try placing the float until the following break opportunity. I wonder if other browsers do that.)
I actually think this is quite doable; we already defer layout of floats in mBelowCurrentLineFloats; we just need to do something similar and notify line layout at break opportunities. It's far from trivial, though. (We also need to place the float immediately if we're currently at a break opportunity... I think.)
I too wonder if that is what other browsers do (Chrome and IE behave the same, placing the float on the same line as the inline-block). Unfortunately I don't fully understand the interaction between floats and line breaks, so I can't comment further.
I ran into the same bug, and for me the best workaround was to use an equivalent flexbox layout: http://jsfiddle.net/nquyefaq/.
It behaves the same on Chrome, Firefox and IE11:
Both items render on the same line, with inline-block type behaviour.
The second item is right-aligned. (Instead of float: right it uses margin-left: auto.)
If the items have fixed width (mine do), the second item drops down onto the next line if the container becomes too narrow.
I hope this helps someone else looking for a workaround.
I'm trying to achieve a combination of three goals...
Determine if I should use <code><pre>...</pre></code> or <pre><code>...</code></pre>?
Make code not wrap, not create horizontal scrollbars and not overflow any parent element.
Ensure that when a visitor copies code that the white-space is maintained when they paste it in to any (competent) editor.
So far I've had the most luck with white-space: pre-wrap; however I do not want the text to wrap. If they're interested enough they'll copy-paste it for themselves. While I do not want it to wrap I also do not want it to make the element overflow outside of any parent element and I don't want the text to appear outside of it's direct parent element.
I'd be okay with a horizontal scrollbar for the code itself (pre or code element, whichever) though I'd generally prefer not to.
Just in case it's relevant I don't use any CSS frameworks or the likes, I only do a basic reset...
* {border: 0px; margin: 0px; outline: none; padding: 0px; }
I test in Firefox, then Chrome, then (actual) Opera and then maybe IE if I have sanity to spare. Thoughts please?
On number 2 and 3: Hopefully I haven't misunderstood your question--I got what I understood your goal to be working easily by by adding a fixed width and overflow:hidden to the css class.
On 1: it's working with <pre (outer)><code (inner)> so... hey.
http://jsfiddle.net/A2zhH/2/
FYI, border: gray; isn't doing anything. You need to use the format border:1px gray solid;
Goal 1 is simple: code inside pre is valid, pre inside code is not. On the other hand, pre is what matters here. You can use code inside it as a matter of principle if the content is computer code.
Goal 2 is self-contradictory as such, unless you are referring to an idea of reducing font size so that everything fits. More realistically, with regard to the statement that it is okay to have a horizontal scroll bar for the code block, use just
pre { width: 100%; overflow: auto }
This causes a horizontal scroll bar to appear for the block, instead of overflowing the content.
Goal 3 is achieved when you use normal spaces. What is copied contains spaces, and what happens to them after paste depends on the software.
I got it working to an accuracy of about 99.8% of the time using the following...
XHTML
<pre><code>/* Code here. */</code></pre>
CSS
pre {white-space: pre; width: 75vmax;}
I have a website at filmblurb.org.
The page-container of my site extends to the bottom of the window when you scroll out to make for a 100% CSS layout style, but for some reason even when the height is 100% for both the body and tag, those two elements go about halfway down the page and then stop when the viewport is zoomed out. When I'm profiling those elements in Google Inspect Element that is. My page-container is currently min-height: 100%, but that for some reason actually does extend to the bottom of the viewport when zoomed out.
I've also taken screenshots of what I'm seeing to give you a better idea. Here they are [link]i917.photobucket.com/albums/ad16/jtarr523/… (for the body) and
(for the HTML)...Both are not extending to the bottom.
Anybody know how to fix this?
I would appreciate it.
min-height: 100% on the html element means that that element will be at least as tall as the viewport. It does not mean that it will always extend to the bottom. If you scroll down, then you may still be able to scroll below the bottom of the <html> element.
The only way to prevent this (short of JavaScript) is to ensure that all elements on the page (that is, everything that could possibly cause a scrollbar) is kept within the html element. A simple way to force this is to put overflow: hidden on your html element:
body {
overflow: hidden;
}
If the problem is being caused by a float, then that will solve it. If the problem is caused by an absolute-positioned element or a negative bottom margin on the last element, then that will replace your problem with a more serious one: the page will be cut off at the bottom of the html element. You will then have to find the problem element some other way.
(The same applies to the body element; it will need its own overflow: hidden; to ensure that nothing can extend beyond it.)
Not sure exactly if it would work with browser zoom, but in my experience (and according to this question) you need to set the html tag height to 100% if you are setting container elements to min-height: 100%.
html { height: 100%; }
body { min-height: 100%; }
Replace body with a reference to your main container and it should still work. As far as I can tell there are no adverse reactions to setting html to 100%; it doesn't cut the page off or mess up any other styles.
Like I said, I'm not 100% sure this is related to your problem, but it's probably worth a shot.
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!
Remove the overflow:hidden on #main in css_75afd7072eaf4096aaebf60674218e31.css
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).
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.
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.
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.
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.
<!DOCTYPE html>
<html>
<head>
<style>
#container {
margin: 1em auto;
width: 40em;
}
#wrapper {
overflow: hidden;
position: relative;
}
#c1 {background-color: #aaf;}
#c2 {background-color: #ccf;}
.column {
float: left;
margin-bottom: -5678px;
padding-bottom: 5678px;
width: 50%;
}
#footer {
background-color: #eee;
padding: 1px;
text-align: center;
}
p {margin: 1em;}
</style>
</head>
<body>
<div id="container">
<div id="wrapper">
<div id="c1" class="column">
<p>This is some content in a short column. We would need some Javascript to change its height if we wanted a different background color for each column to stretch the full height of the respective columns...or we can use large padding together with an equal negative margin.</p>
<ul>
<li>Jump to P1</li>
<li>Jump to P2</li>
<li>Jump to P3</li>
</ul>
</div>
<div id="c2" class="column">
<p id="p1">The desired effect is to have the height of the two columns appear the same. We use 'overflow:hidden' on the containing div (#wrapper) to wrap it around the floated columns.</p>
<p id="p2">These paragraphs have fragment identifiers. Problem comes in when clicking one of the links on the left. Instead of scrolling just the page, the browser scrolls the div with 'overflow:hidden' so the target is at the top. It does this even if the target is already visible.</p>
<p id="p3">Opera does not exhibit this behavior. This occurs in Chrome/Safari, Firefox, and IE. (Interestingly, IE also works as expected if we completely remove the DOCTYPE declaration.)</p>
</div>
</div>
<div id="footer">
<p>Footer stuff.</p>
<p>To see why 'overflow: hidden' (or any other piece of the CSS) is needed, just try disabling it.</p>
</div>
</div>
</body>
</html>
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).
I was able to solve this with some javascript to scroll the body to the position the overflow hidden element was scrolled to.
setTimeout(() => {
let intendedScroll = document.getElementById("fragmentfix").scrollTop;
document.getElementById("fragmentfix").scrollTop = 0;
window.scrollTo(0, intendedScroll);
}, 0)