Do you really need a width on floated element? - javascript

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.

Related

CSS Grid Container Height Covers Other Content

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.

How does jQuery Slidedown get final height of hidden item before showing it?

I'm trying to replicate jQuery slideDown() in GSAP and I'm having trouble working out how jQuery calculates the height of an item which is currently hidden as if it was set to height:auto.
I've tried trawling the code on GitHub but can't find any code which seems to be doing this in jQuery.fn.slideDown or jQuery.fn.animate which it calls.
There are several similar questions on SO and several solutions proposed, all of which seem to have their own problems:
Clone the element, position it off screen and calculate its height. This won't work if the element or any of its child elements have a height set by CSS styles which require the element to be in its original place in the DOM (e.g. an .accordianItem might only be styled if it's inside its .accordian).
Display the item, remove height:0 and quickly calculate the height before hiding the element again and then stating the animation. This might flash the content quickly while calculating the height.
Use visibility:true to show it in place while calculating the height. This would stop the flash and still keep the element in the same position in the DOM for correct height calculation, but it would still push other items below it down because visibility:false items still have a height.
Calculate the height of an item before it's hidden and store it in a data attribute so we know it when we want to open the item later. This won't work if any dynamic content changes the height of the item whilst it's hidden.
jQuery slideDown() "just works" every time so I'd be really interested to know how it works, but I just can't work out where it's doing this. I'm also surprised that GSAP can't do this out of the box, or that nobody has shared a proper solution to this before.
Any help would really be appreciated.
It turns out that if you use $.height() to get the height of an element with display:none it doesn't return 0 as you would expect, it actually sets visibility:hidden, position:absolute etc. and sets display to block to give you the correct height back. I assume this is what's being used internally when doing a slidedown.
This answer helped me a lot.
jQuery: height()/width() and "display:none"
Just to be clear about how this seems to avoid all the problems in my original question. It's basically doing number (3) but avoiding the problem of pushing lower content down the page because it's also set to position:absolute while the height is being calculated. A very simple elegant solution

How to troubleshoot a bad jQuery animation

Recently, I was writing code for a website template that required some element animation. Naturally, I decided to get my jQuery on and use some of its standard libraries to animate my div. In this case, I wanted to use the slideUp() function. When I coded it up and ran a trial, I noticed that the animation was very choppy, so I decided to look for clues here and on the internet and came up fairly short.
The question Div slideUp and slideDown animation choppy with inline-block display provided some hints, but nothing that I would end up actually using. So I am wondering: how have you dealt with this, per scenario, in the past? I will be posting an answer with the solutions I found to be helpful.
The Terrible min-height/min-width
The first and most common bug I have run into is the use of min-height or min-width. As noted here, it will cause the animation to be jumpy regardless of your standard height setting. Why does this happen?
Let's say you have a div that has a height of 75 pixels and a min-height of 50 pixels, and you wish to use some animation function that reduces the height of that div to zero (such as slideUp()) When the animation starts, it will begin to subtract from the total known height. When it reaches the set min-height, it will attempt to set the div height lower, but will not be able to and stick there until the display:none is added to the element's style, causing that presumed "choppy animation". It's not actually choppy: it's failing. If you were to run a standard animate() such as $("div").animate({ height:'0px' )}) on a div with a min height set (greater than 0), you would find that the animation simply sticks at the set min-height.
The solution to this problem is to simply unset any min-height for the div in css or to set min-height: 0; if the min-height is declared elsewhere.
The unfortunate no height/width
Another common bug is to simply set no height (or width, depending on the direction of the animation) on the object at all. This can cause the animation function to jump because of an incorrectly calculated height that it needs to adjust for. An unset width/height can have varying results and might succeed or fail depending on the DOM around and contained in it. It is best practice to set a height and width on any element one wants to animate. Percentage heights/widths are fine.
Padding/Margin Bloody Padding/Margin
You might run into a problem with choppy animations caused by collapsing padding/margins of the element you are attempting to animate, or any elements inside it. This is a simple problem fixed by adding a border: 1px solid transparent; to the element you are animating. This creates a bounding for jQuery to use so that it essentially ignores the collapsing padding/margins.

Flexible width on d3.js graph?

Please see http://jsbin.com/okUxAvE/28/
This has a width of 500px. The graph works as intended, with the nodes adjusting their position to stay in view as necessary.
How can I have this width be the arbitrary width of its parent instead of the specific 500px? For example, when viewing on a given device, the width might need to be 300px instead of 500px, but except for the change in width, everything should continue to work as in the example (i.e. no resizing of nodes).
Note that I don't care much about when the user resizes the window, although for orientation change it could be useful; so if anyone knows that it's a bonus, but not my main issue.
UPDATE, for clarification: I need 100% of the parent container, not 500px. I can't just use 100%. I know I could get the width of the parent, stick it into a variable and use that, but I'd like to know if there is a better way.

Size element so it is exactly as tall as it needs to be to not scroll

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.

Categories