I'm building a responsive CSS grid with items whose sizes match a desired aspect ratio. I've tried the padding hack among a few other techniques, but nothing has worked nearly as well for me as using JS to determine the pixel value of 1fr for the desired number of columns and the gap size, and then applying that to the row sizing using repeat(auto-fill, minmax(${width}px, 0)).
Unfortunately, this approach comes with a rather nasty side effect: the parent div (display: grid) doesn't know the height of its own content, so it never sizes correctly. As a result, it's never able to show more than one row of the grid. The rest of the grid items display as a line just below that first row.
To fix this, I've tried setting the height of the parent to 100%, but that covers all of the other content on the page. I've tried using containers to fix the sizing, but haven't had any luck there, either. I've also tried overflow: auto, to no effect. If I could calculate and manually set the height of the parent div in my script, that might work, but I've not been able to find a way to do so (and also seems like a messy approach).
Is there any (good) way to do this? Here's a demo of the issue: https://codepen.io/jmindel/pen/GRoMjEw
when you set the overflow: auto it will make a scroll bar in your element to show all of the content in the specified area. then in this case it won't help you. when you set the height of an element to 100% it's height will be the same as it's parent element. I had this problem before. if you want to set the height of an element you should set the height attribute of all the parents of the parents of your element. you can use % as the unit of height and width if you want your code be responsive and don't want to calculate the exact height of elements and if not you can use other units. try to set height with % unit for all of your parents. it helped me and I am sure it will help you too.
Here's what I wound up doing:
I tried wrapping .grid in another div and styling that wrapper such that it has overflow: scroll, which fixes the height not displaying (100% is fine in this environment--it doesn't cover anything, since it's limited to the height of its block-level parent).
I wrote a script that temporarily sets the grid's height to a very large number, finds the lowest element in the grid, and uses its position to determine the grid's height, which gives it a forced pixel height until the next resize.
A few shortcomings of this approach:
The grid must be contained to a scrollable subcontainer, which works well for my use, but might not for others.
The grid's height should size properly, but didn't without a forced pixel height. min-content and max-content did not work.
Related
My particular problem first occured to me when using with http://mkoryak.github.io/floatThead/
On certain pages I have tables with a of of columns. The client opted for horizontally scrolling these tables. Therefore those tables are wrapped in a div that has overflow-x: auto;
Works nice on desktop browsers and Safari/iOS.
When using floatThead at some point it requests the width of the table with outerWidth() to set the width of the table header when it is floated. On the iPad that floated table header is just as wide as the wrapper element, the rest of it is cropped. I debugged the outerWidth() values of both the container and the table.
On a desktop browser I get values like e.g. 1200px for the container, but 1900px for the much wider table inside of the container.
But in Safari iOS I get 935px for both the container and the table. The container elements doesn't have to be set to scroll larger contents to produce this error. I work with Twitter Bootstrap 2.3.2. If there is a page with a container fluid, its width is adjusted to the window width. If there is a table inside with a larger width, it is visible through overflow: visible;. But – on the iPad – when floatThead is triggered, the floated table headers width gets restricted to the width of the fluid container (minus its padding).
Therefore I presume that the reason for this is a different calculation of the width of bigger elements that are inside smaller containers.
If I understand it correctly, jQuery's outherWidth() uses css() to retreive the width of elements, and css() uses getComputedStyle or currentStyle.
I assume the browser returns the "wrong" with values, and that's all jQuery/floatThead can work with.
And I was wondering if my assumption is correct, or if there could be other factors triggering the "wrong" calculation of the width in Safari iOS.
Apologies for not checking into it any further myself before asking the question. After making a static copy of one of the problematic pages and successively deleting html, javascript and css code I was able to track down the reason.
Twitter Bootstrap 2.3.2 sets max-width: 100&; for table elements. In the said case (table being inside a smaller container that allows for scolling its contents), the table width doesn't need to be restricted in any way.
It didn't cause any problems in desktop browsers. Even in Safari the width of the table itself was fine and scrolling worked. Just jQuery's outerWidth() received a wrong value, which resulted in the floated thead being cropped to the width of the outer container.
Say you have a Div (id="toolbar"), and inside that toolbar you have a Div (id="ButtonHolder") that contains 2 buttons. If you float the #ButtonHolder to the right and don't set an explicit width on it, is that kosher?
I've read on stack overflow that you should always set a width on a floated element. The buttons text might change, from save to apply, and I don't want to have to adjust #ButtonHolder's width every time.
I thought about setting #ButtonHolder's width to auto, but the browser does that by default so it seems unnecessary to set it's width to auto. I'm worried the browser might not always float #ButtonHolder the way I think it should.
A change from "save" to "apply" isn't going to take up much more room, to be honest.
In principle, yes you should always set a width - if you don't, then say you have the button float:left; and another <div> float:right;. If you don't set widths, they're not going to take up the full screen width, so any elements you put in below are going to try to position themselves in the gap between the two.
It is also a good idea to have a 100% width container element for this particular scenario to prevent the described effects.
float and position usually come with a cost. You should try to first find other ways to position elements within your layout. You can should consider other options such as margin, padding, display: inline-block;, text-align ... etc.
I would recommend reading this.
To answer your question directly. Setting width for floats is not written on stone but not doing so, usually means trouble later. At least in my personal point of view.
I am using the Malihu custom content scroller with automatic scrolling. So far, I basically am experimenting with it. I noticed when I take the height of the scrolling div and use a percentage instead of a fixed amount in px, it expands the div the entire height of the scroll area (off the screen).
I'm literally just taking the code from this GitHub location then opening the file "auto_scrolling_example.html".
Then in the <style> section of the header, I'm simply changing .content: height:500px to .content: height:50%.
Does anyone know why this doesn't work and/or have a good workaround for it?
When you specify the height or width as a percentage, that's a percentage with respect to the element's parent.
If the parent doesn't have any height or width inner children will not work in percentage.
I have an issue with my web page.
Basically, I have the <html> on overflow:hidden, two horizontal navbars, one fixed vertical sidebar on the left and in the remaining center, one div that has the height: 90% property.
Edit: The container div has the overflow: auto property.
The content is loaded in the container area via AJAX. The content consists mainly of tabular data, and the point is to have the container area scroll whenever there is too much content. Everything works nice and fine on a regular monitor with normal height, but when it's taken to a laptop, the last 1-2 rows become 'hidden' due to html overflow.
If i decrease the original height: 90% to a smaller value, problem fixed, but after I switch to large screen with the decreased height, the content area is not fully covered.
Is there a way to fix this issue via CSS? If not, is it possible via screen resize javascript event?
The easiest and probably the fastest way to do it would be using Javascript.
If you specifically set the height of your tabular data container, you will gain much more control over the layout and general item spacings.
When setting your height, you have to take into account the heights of your navbars, so in jQuery the code would look something like this:
function resizeMain()
{
$('#tabularBox').height($(window).height() - $('#topBar').height() - $('#bottomBar').height());
}
// size it on load:
$(function(){
resizeMain();
}
// and size it on resize
$(window).resize(resizeMain);
Of course, many ways to optimize this, but that's the idea. And you have to watchout for tiny screens, but this would be a problem with % anyway.
Finally, you need Overflow: auto; on our tabular box
in the div that is height:90% put overflow: auto or overflow: scroll. That'll add a scroll bar to that div only.
Size element so it is exactly as tall as it needs to be to not scroll
I am working on a tool to allow creating small "notes" that I then turn into Ext.Draggable items. What I would like to do is to have these items be sized no taller than they need to be.
The elements are absolutely positioned: set position: absolute with top and left and height and width values in-line. The problem is that the height values are not really very reliable.
Is it possible to set the size at something very short (say 3px), then increment the height until the scrollbars disappear? How can I tell when that occurs, and can I do it in a way that's reliable across browsers?
Code: http://github.com/artlung/ArtLung-Notes/blob/master/v2/index.js
In general, see Ext.util.TextMetrics.getHeight(). Note that you can't use the singleton for height determination.
However, I think that removing explicit height should generally solve your problem. That's unless you need to synchronize something like shadow overlay's size, though.
If an element's style.position is absolute and the style.width is determined, setting its style.height to 'auto' will make a containing box for its content and padding, with no scrollbars.