Div contents extending size of page rather than scrolling its contents regardless of overflow attribute - html

I am blocking out a new page for my site that is going to be responsive with a sliding divide separating 2 columns. On the left column I have a couple vertically stacked divs, the bottom of which I want to scroll its contents when it overflows. I want only the div to scroll and not the entire page.
I have already set the overflow-y to scroll and while this does produce the scroll-bar it still expands the entire page rather than recognizing the edge of the window. I have a feeling it has to do with the parent containers size not being fixed and I thought setting it to max-height: 100%; would resolve this but it has not.
here is the jfiddle
jfiddle
It is basically just a grab from my sandbox site wtb.dsdcs.com but it seems to behave the same in the jfiddle so it should suffice.
Just a disclaimer: there is a video the autoplays in both the website and jfiddle that I left intact in-case its container is part of the issue, so may need to turn down speakers.
Clarification: #PlayList is the element I wish to be able to scroll.

You need to give your Playlist class a height - (e.g 400px). Then, as you add more a items you should get a scrollbar. You can remove max-height as that won't be needed.
If you want a dynamic height of the playlist, that always takes up the remainder of the height, you could add a jQuery script:
var h1 = $(window).height();
var h2 = $('.videowrapper').height();
$('.playlist').height(h1-h2);
Since your videoWrapper is set to take up 50% of the height, the other approach could be to set your playlist to have the other 50%. So set it to height: 50%.
.playlist {
padding: 10px;
font-size: 12px;
overflow-y: scroll;
height: 50%;
position: relative;
}
EDIT 17 Oct:
The reason the above might not work with all browsers is probably because of your implementation. Like I said in the comments below, you shouldn't be using table-type display properties because they don't support overflow very well.
The W3C even say that the overflow property only applies to block-type elements LINK.
The MDN suggests the same LINK.
As such, implementing overflow on any table-type element will always be a tricky and risky approach as browser support issues or browser display inconsistencies should be expected. To get a fully supported solution, I'm afraid you'd have to try other display properties such as flex or block.
Unfortunately, there is no way to get a fully supported solution for overflow on table elements, and therefore such answer cannot be provided. The only real "solution" here that would actually solve your problem would be a complete (or partual) overhaul of your entire site.
However, I hope the above gave you hint of direction of what to do next and as such being an acceptable answer for you.
Good luck!

Related

position:sticky on horizontal scroll doesn't work

i have a table that looks like this:
<table id="navbar" border="1" style="background-color:navy;height:150px;position:sticky;top:0px;right:0px;left:0px;border-style: solid;border-color:black;max-width:999999px; width:100%; background-image: none;">
the style for all tables:
table{
text-align:center;
width:30%;
left:25%;
/*font-size:larger;*/
}
the psoition sticky should make it so that the table will always remain at the top of the screen, even on horizontall scroll. yet it doesn't work. the only way i found for it to work was by adding another table above and giving both the display:inline-table attribute, but it is not the solution i am looking for.
anyone knows the reason for why it doesn't work?
edit-i need to use position:sticky. it works pefectly for vertical scroll, but not for horizontal scroll. that is the problem i need to fix
Sorry it took so long for someone to answer you #Erel.
So you don't have to read my ramblings if you just want code, I'll start with the demo: https://codepen.io/NerdyDeeds/pen/oNYVLpB
There's a couple things to note here, for the behavior you're after:
Much like the whole height:100% thing, for this to work, the measurements need to go all the way down to the :root. That is to say, every DOM node hierarchy needs to know the actual limits of its bounding box (don't worry: it'll become more clear below).
When an object is positioned sticky, it basically has TWO sets of coordinate limitations: those of the viewport, AND those of its parent. If the parent is 500px wide and you scroll 1500px off screen to the right, the sticky element will stop at the edge of its parent, not continue to tag along. Which brings us nicely to the most important aspect:
The <body> tag is simply another block-level container object, only it gets an implicit min-width:100vw; min-height:100vh. That said, if the one of IT'S children that's necessitating the horizontal scroll is, say, 250vw wide, it will expand to contain that element, but it's measurement width remains the same; it's children still think papa's only 100vw wide. Likewise, were you to explicitly tell it that it's "ACTUAL" width is really only 100vw, it too, will slide off-screen when scrolling, carrying its sticky child (aren't they all?) with it.
The same thing applies to all the ancestral containers of your sticky element. They DON'T automatically get the min-width, so you need to explain to them they're to take up that full space. If you want that done dynamically, you need to explain that to the <body>, so they can inherit the "real" 100% of the page. If any ancester is throttled in its movement or its dimensions, that will cascade all the way down-chain to your element, sticky or not.
The simplest way to tackle this I've found is to simply add:
body {
width: max-content;
}
...to you CSS. This tells the body "you're actually as wide as your widest contents... pass it on!" The "cascading" portion of the CSS will take hold and carry they measurement all the way up to your sticky element, provided none of the parent nodes between it and the body themselves are constrained (like if you set a width:100vw in there somewhere. 100% will work fine, but again: only if none of IT'S ancestors is smaller).
Check out the attached CodePen. I tried to make it as self-explanatory as I could.
And again: sorry nobody got back to you sooner. That's a frustrating feeling that stinks. I hope you already found your solution, but if not, this may help who comes googling after. Hope this helped.
Use fixed position:
<table id="navbar" border="1" style="background-color:navy;height:150px;position:fixed;top:0px;right:0px;left:0px;border-style: solid;border-color:black;max-width:999999px; width:100%; background-image: none;">
position: fixed always fixates an element to some position within its scrolling container or the viewport. No matter how you scroll its container, it will remain in the exact same position and not affect the flow of other elements within the container.
position: sticky basically acts like position: relative until an element is scrolled beyond a specific offset, in which case it turns into position: fixed, causing the element to "stick" to its position instead of being scrolled out of view.

Stick columns to the left and top in a table-like structure made out of divs

I have a table-like structure made out of different divs (and not the html tag). (kind of like an excel view).
I want to implement the fixation of the top row (header) and the first column (has some actions).
All my actions are in one view. Every row with data is a separate view and the header is a separate view.
I have presently applied position: sticky/-webkit-sticky and top: 0/left:0 as required.
This has been able to fix my problem in most browsers. However, Safari is behaving very abnormally.
My left column gets to stay fixed, but the top column on scrolling goes out of the viewPort.
Can anybody suggest some other fix or a Safari related fix?
Please find images attached below:
Sticky can be finicky. If you showed us relevant html/css it would be easier to offer solutions.
Is there a reason you can't use position: fixed; instead of sticky? unless the sticky elements are only sometimes sticky, then fixed should work.
Or maybe set the body 100% width and height, overflow: none; and then set the area you want scrollable to 100% height with overflow-y: scroll or 'auto'.
Edit: Based on your comments below.
I think I have a better idea about what you are trying to do. You want the left column to scroll up/down with the rows, but not left/right. position: sticky; may be the only way to achieve that other than javascript.
I think you should take the top row out of the equation though. Put the whole thing in one container, then setup nested containers within that. There are lots of different ways to structure it. Because position: sticky; gets positioned relative to the nearest scrollable ancestor.
I made a jsfiddle to show one possible method. https://jsfiddle.net/c9kaz854/4/ I can't test it in safari right now, but maybe you can test it, and maybe it can give you some different ideas.
I would suggest you make the same sort of structure you are going for in a simplified format. Start with a clean html file and basic css reset file. Build the basic structure and tweak it until you have something that works consistently across the browsers you need to support. Then use that basic pattern in your full site.
Because position: sticky; has inconsistent implementations in some browsers, a possible workaround for your situation could be to put the element in an <iframe>, <object> or <embed>. Then you could used position: fixed; in a more limited context.
To make that work though, you would put the top row above and outside the iframe, and all the scrollable content inside the iframe (left column and all but top row). Just have left column (inside iframe) be 'fixed.' Put the iframe in a div with overflow-y: scroll; (or auto), and make the iframe itself taller than its container div, so for vertical the scrolling happens outside the iframe, and the whole iframe element scrolls within the containing div, including the left column which is fixed inside the iframe. Then put a class on the iframe source's html/body elements and limit their width with width: 100%; (size of the container) and give them overflow-x: scroll; (or auto), so the the horizontal scrolling happens within the iframe where the left column is fixed and won't move.

Can you control mobile Chrome's "inferred layout height" (for horizontal layouts)?

Lacking better terms for the problem, this question got a bit long. Sorry!
I've been trying to build a simple horizontal layout with a bunch of <div>s with width: 100%; height: 100% next to each other ("screens" of an app that you can swipe).
In Chrome's responsive preview, as well as on a real device, empty space appeared below the <div>s — no invisible objects, no traces of the excess height in any DOM properties.
Here's a gist, try it via bl.ocks.org. Scrolled all the way down, it looks like this:
Red/blue are the divs, yellow is bodys background-color.
In a related answer I found this:
Chrome infers the layout height using the width and screen's aspect ratio. i.e. height=width/aspectRatio
Which means that if my content is wider than the viewport, a minimal height will be calculated for it. I find this weird, and came up with workarounds:
set html, body { overflow-y: hidden}
put all children of <body> inside a <div> wrapper
Since both methods have downsides or aren't always applicable, I am wondering: is there a way to control this behavior, like, set the inferred layout height to "auto"?

How can the top DIV from two stacking DIVs affect the other's height

As the title suggests, I have two stacking <div>s.
They are placed in an absolutely positioned container that covers the whole page. Basically, those 2 <div>s, taken together, should also cover the whole space of the containier.
Another important aspect is that these <div>s have dynamic content. The bottom one can have a lot of content, so an overflow: auto rule is required. The top one can also have dynamic content, but it's not really expected to grow out of control. Thus, I don't want to cut the overflow.
The main question is: How can the top one affect the other one's height without the risk of overlapping? (I prefer a CSS only solution, or something that wouldn't imply JS pixel values computations)
Here are two images that describe the best what I'm trying to achieve:
"initial state"
a state with some more data in the top div
Here is also a JSfiddle for convenience: http://jsfiddle.net/60qan4t6/
This is the kind of situation that display:flex handles extremely well. Update to your fiddle:
http://jsfiddle.net/60qan4t6/1/
Note, I quickly wrote this, so it's missing browser prefixes to support some browsers, but the fiddle should work in Chrome just fine.
Be sure to see check browser support for flexbox here:
http://caniuse.com/#feat=flexbox
If it's acceptable to set height to div's you can use such an example
.top-area {
background: red;
overflow: hidden;
height: 40%;
}
.bottom-area {
overflow: auto;
height: 60%;
}
http://jsfiddle.net/xqh2vw2g/

css 100 % height bug

When I resize window and when vertical scrollbar appears, if I scroll it way to the bottom, - the bottom breaks. I dont understand why, but I think it has something to do with the way how page uses 100% height. Any help would be appreciated!
Here's the page: zxsdesign.com/main1.html
Here's a screenshot
zxsdesign.com/bug1.PNG http://zxsdesign.com/bug1.PNG
It's a mix of you using the CSS height property and absolute positioning. ajm has talked about using min-height - ideally, you should be using it instead of height when you make things 100% high.
Onto your other problem. When you position elements absolutely, they're no longer part of the page structure. Instead, they live in a separate plane, and so do not affect the page dimensions. When your <div id="flashcontent"> runs past the window boundary, it doesn't affect <body>'s borders.
You can fix this by not using position: absolute. There's no real need to. Instead, you can position the #flashcontent element normally, and get rid of the #bg element completely - just give #flashcontent a background instead. Then use margin: 0 auto; and padding-top: 179px; to position it in the correct place.
Unfortunately height: 100%; is implemented differently... You can not be sure that a browser does what you want when you use it.
Try to use clear: left; or clear: both; in your style.
100% height is one screen height. If you scroll up, it does cover 100% of the height. Make your blocks scale too, or at least move to the center of the screen. You can do this by setting their top and bottom padding to auto.
Also, your head tag isn't closed properly. Check this
Your page is based entirely on using 100% height for all of your Elements. If the user's browser viewport is big enough, that's fine; however, if they resize their browser to be small enough, your page will be 100% of that smaller height and things will drop out of the bottom.
Look into setting a min-height on one of your container Elements. That will force things to stop resizing if the browser window falls below that height. Or, you can set a plain old height big enough to contain your flash piece on one of your container items and let the others inherit from that.
And, since IE6 doesn't support min-height (FF2+, IE7, Safari all do), you'll need to hack it in like so.