I have made a messaging web app a while back and this summer i tried to make another with a bit of a different structure but ran into this issue where the spans' (messages') height shrunk instead of overflowing with scroll, and if i set a min-height they wouldn't get taller when the message was longer, so i used the source code of the old one and changed it a bit, but had the same issue. I would really like to know why this is happening and how to solve it.
I put the code on github, to be easier to see/try: https://github.com/Konstei/stack-overflow-code/.
I also made it into a running website using github's pages: https://konstei.github.io/stack-overflow-code/new/, https://konstei.github.io/stack-overflow-code/old/
I have referred your code and the issue is you have set overflow: hidden on *{} global selector. Since your direct span element after message-area div hasn't specified any overflow property, the overflow property from your global selector gets applied whose value is hidden and hence the overflowing content from inner span is being hidden. Just remove that property from your global selector and it should work.
When I use the following:
body {
overflow: hidden;
}
The element that is overflowing is clipped, when I do the following:
body {
overflow: auto;
}
It's not clipped but now there's a scrollbar where it's going over.
I'd like to make the element not clip but also to not show the scrollbar or be scrollable
So basically, you don't want to control overflow, since you don't want the element to overflow. You want its parent container to adapt to whatever the size of the element.
It can be done in multiple ways. One of the best being, not doing anything since most HTML elements won't clip whatever's inside them.
Except for window, which is the boundaries of your browser. And it can't be skinned anyway.
I don't have much informations, but a wild guess would be to believe that you are trying to have an iframe behave like a regular HTML element.
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!
For starters, check this fiddle -> http://jsfiddle.net/xV4s3/
As you can see, we have a wrapper with overflow: hidden and inside there is a native select with three options and an ul styled to look like a select with three items. Now, when you click on the ul, you can see its height changes (due to the script), but nothing beyond the wrapper is seen, because of the overflow: hidden. And that works as expected.
My question is about the default select's options, since I couldn't find anything in the specifications. Why are they not affected by overflow: hidden ?
This is probably nothing more than an implementation detail. The only thing CSS2.1 says about overflow control is that the overflow property controls overflowing of content according to the containing block to which the property is applied. It does not define the behavior and rendering of form elements and such with respect to this property.
As I commented, it's clear that the drop-down menu isn't being created as a descendant of the wrapper, or even the select element. In fact, it's possible that most browsers choose to render it completely independently of the canvas and as an application-level or system-level UI element in its own right (likely for usability reasons). Note that while you can apply CSS to the option elements to influence the way the drop-down menu displays, you cannot actually style the drop-down menu itself.
I'm running into some extremely strange behaviors, and non-consistant across every browser i've tested.
I've a pretty complex layout, but the main issue lies here:
<div id="drop">
<div id="header"></div>
</div>
#drop has position:absolute and z-index:100
#header has position:fixed; top:60px;
As I start scrolling down Chrome ignores the position:fixed rule. If I remove either of the two styles above from #drop then Chrome starts respecting the position:fixed rule.
can't get it working on Ubuntu Chrome 23.0.1271.97 and see the same behavior on Mac Chrome 25.0.1364.99. My friend uses Ubuntu Chrome 25.0.1364.68 beta and it works correctly for him. I've tested it on firefox and it kinda works (with other symptoms)
Has anyone heard of this error? or can anyone even reproduce it?
edit
I'm using openlayers map as another div with position:fixed if I delete that layer or at least change it to display:none then this weird bug goes away.
edit
Noticed that during the presence of this bug, if I change the zoom level back and forth, then the position adjusts itself to the proper behavior. To me, this indicates a webkit issue that fails to execute some internal callback function on scroll.
Another extremely strange thing is that I have a few links inside of #header and they work if I just click the expected location, even though the the div does not appear there. Overall I've noticed that it's only the rendering that's broken. If at any point of time I force the browser to re-render by resizing the window, or changing zoom, or just doing Select-All, then the header bar jumps to the proper position, but does not remain fixed.
You mentioned in the comments that OpenLayers uses CSS transforms. That being the case:
the element with fixed positioning will become relative to the element with the transform - not relative to the viewport
Take a look at the spec: The Transform Rendering Model
Specifying a value other than ‘none’ for the ‘transform’ property
establishes a new local coordinate system at the element that it is
applied to.
.wpr
{
width: 200px;
height:1000px;
background: pink;
position:relative;
margin: 0 200px;
-webkit-transform: translateX(0);
transform: translateX(0);
}
.fixed
{
width: 200px;
height:200px;
margin: 50px;
position: fixed;
top:0;
left:0;
background: aqua;
}
<div class="wpr">
<div class="fixed"></div>
</div>
As the accepted answer says, this is the intended behavior, and is spec-compliant. Another important component of this is what it means to be using CSS transforms.
In your case, it was due to OpenLayers, but this applies to anyone using will-change: transform as well (probably a lot of the people visiting this question). This has been brought up on the Chromium bug tracker here, and marked as WontFix, because (as I said) it's intended behavior. The official comment is this:
This behavior is required by the spec
(http://dev.w3.org/csswg/css-will-change/): "If any non-initial value
of a property would cause the element to generate a containing block
for fixed-position elements, specifying that property in will-change
must cause the element to generate a containing block for
fixed-position elements."
The idea is that once will-change:transform is specified, you should
be able to add/remove/change transforms cheaply, without needing
fixed-position descendants to get re-layed-out.
Note that using other values of will-change (e.g. opacity, top) will
not change the positioning of fixed-position descendants.
As far as I am aware, the only solution is to make the child of the will-change element a sibling instead, to prevent the attribute from cascading.
As a side note, in my specific case, I was able to fix it by being more specific with the will-change attribute. Instead of using it on the div containing the performance-jarring element that required GPU offloading, I used it directly on the offending element. This was due to my original bad code, though, so it won't work for most cases.
You will have to place header outside the parent container drop to make it work.
I had slightly similar issues days back.For instance,if you set z-index of header,it will be attain the z-index of the parent dropcontainer.The z-index of header will be useless because it is already inside a container which has another z-index.
The same logic of z-index applies to position.
I want to add another possible solution because I was struggling with chrome ignoring position:fixed for quite some time until I finally found the culprit:
-webkit-perspective: 1000;
It was coming from a plugin I was using and causes ALL position:fixed elements to be ignored.
Hope it helps someone.
I think this is impossible, i don't think if two positions can be placed at the same place without one to collapse. But i think its better to use Avail height in javascript, i mean if you wanna an outer div to hold inner div, and outer div must cover the whole screen, use Availheight in js, this will get the screen height and then apply if, thereafter set all the divs in fixed position.
Add this to parent:
position: fixed;
...and this to the child:
position: sticky;
First of all, put something in your div as empty ones behave really weird. Then, what do you expect by putting a fixed into an absolute? Obviously, nobody knows what is the reference point of your fixed div. Should it be its parents position? which is not changing with scroll or the page position which changes? Try to use things that are completely meaningful and have a clear definition because if you fix it in chrome, what would happen with another browser? Do you really prefer to test is on all of them?
I suppose a small change in your divs so that pull the fixed div out of the absolute one or move the absolute div somewhere else.