Asked  7 Months ago    Answers:  5   Viewed   44 times

Say you have a div, give it a definite width and put elements in it, in my case an img and another div.

The idea is that the content of the container div will cause the container div to stretch out, and be a background for the content. But when I do this, the containing div shrinks to fit the non-floating objects, and the floating objects will be either all the way out, or half out, half in, and not have any bearing on the size of the big div.

Why is this? Is there something I'm missing, and how can I get floated items to stretch out the height of a containing div?



The easiest is to put overflow:hidden on the parent div and don't specify a height:

#parent { overflow: hidden }

Another way is to also float the parent div:

#parent { float: left; width: 100% }

Another way uses a clear element:

<div class="parent">
   <img class="floated_child" src="..." />
   <span class="clear"></span>


span.clear { clear: left; display: block; }
Tuesday, June 1, 2021
answered 7 Months ago

You can use CSS3's flexible box layout to do this pretty intuitively:

.parent-div {
    display: flex;

.text-div {
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;    

    min-width: 0;

.icon-div {
    flex: 1;


Thursday, June 17, 2021
answered 6 Months ago

2 possibilities to get "below minimum":

  1. float range:

    Typical float numbers have 2 ranges: full precision (normal range) from FLT_MAX down to FLT_MIN and a 2nd range with reducing precision from FLT_MIN down to FLT_TRUE_MIN. This 2nd range, called "subnormal" typically provides about 10^-7 more range.

    FLT_TRUE_MIN is the "minimum positive floating-point number"

    FLT_MIN is the "minimum normalized positive floating-point number"

    FLT_MIN_10_EXP is the "minimum negative integer such that 10 raised to that power is in the range of normalized floating-point numbers"

    C11dr ยง5.

    In general 0 < FLT_TRUE_MIN <= FLT_MIN <= 10^FLT_MIN_10_EXP <= 10^-37

  2. Math performed as double.

    printf() coverts each float passed to it to a double. C allows code to optimize such that the value passed to printf() may be the double product of FLT_MIN * 0.0000004.

    float underflow = FLT_MIN * 0.0000004;
    printf("%en", underflow);

    Had the output been 4.701976e-45 rather than 4.203895e-45, this would have been the case.

Note on "subnormal". A compelling reason for subnormal (or denormal) numbers lies in the following problem.

float a,b;
... // somehow a and b are set.

// Are the 2 below equivalent?
if (a == b) foo();
if ((a - b) == 0) foo();

Without subnormal numbers, 2 nearly the same value numbers near FLT_MIN would have a non-zero mathematical difference much below FLT_MIN and the result would round to 0.0.

With subnormal numbers, the difference of every pair of different floats is representable by something other than 0.0. **

** Except +0.0, -0.0. Signed zeros have their own peculiarities.

Wednesday, August 11, 2021
answered 4 Months ago

I didn't find the other answers satisfying. Sure, .1 has no finite binary expansion, so our hunch is that representation error is the culprit. But that hunch alone doesn't really explain why math.floor(.5/.1) yields 5.0 while .5 // .1 yields 4.0.

The punchline is that a // b is actually doing floor((a - (a % b))/b), as opposed to simply floor(a/b).

.5 / .1 is exactly 5.0

First of all, note that the result of .5 / .1 is exactly 5.0 in Python. This is the case even though .1 cannot be exactly represented. Take this code, for instance:

from decimal import Decimal

num = Decimal(.5)
den = Decimal(.1)
res = Decimal(.5/.1)

print('num: ', num)
print('den: ', den)
print('res: ', res)

And the corresponding output:

num:  0.5
den:  0.1000000000000000055511151231257827021181583404541015625
res:  5

This shows that .5 can be represented with a finite binary expansion, but .1 cannot. But it also shows that despite this, the result of .5 / .1 is exactly 5.0. This is because floating point division results in the loss of precision, and the amount by which den differs from .1 is lost in the process.

That's why math.floor(.5 / .1) works as you might expect: since .5 / .1 is 5.0, writing math.floor(.5 / .1) is just the same as writing math.floor(5.0).

So why doesn't .5 // .1 result in 5?

One might assume that .5 // .1 is shorthand for floor(.5 / .1), but this is not the case. As it turns out, the semantics differ. This is even though the PEP says:

Floor division will be implemented in all the Python numeric types, and will have the semantics of

    a // b == floor(a/b)

As it turns out, the semantics of .5 // .1 are actually equivalent to:

floor((.5 - mod(.5, .1)) / .1)

where mod is the floating point remainder of .5 / .1 rounded towards zero. This is made clear by reading the Python source code.

This is where the fact that .1 can't be exactly represented by binary expansion causes the problem. The floating point remainder of .5 / .1 is not zero:

>>> .5 % .1

and it makes sense that it isn't. Since the binary expansion of .1 is ever-so-slightly greater than the actual decimal .1, the largest integer alpha such that alpha * .1 <= .5 (in our finite precision math) is alpha = 4. So mod(.5, .1) is nonzero, and is roughly .1. Hence floor((.5 - mod(.5, .1)) / .1) becomes floor((.5 - .1) / .1) becomes floor(.4 / .1) which equals 4.

And that's why .5 // .1 == 4.

Why does // do that?

The behavior of a // b may seem strange, but there's a reason for it's divergence from math.floor(a/b). In his blog on the history of Python, Guido writes:

The integer division operation (//) and its sibling, the modulo operation (%), go together and satisfy a nice mathematical relationship (all variables are integers):

a/b = q with remainder r

such that

b*q + r = a and 0 <= r < b

(assuming a and b are >= 0).

Now, Guido assumes that all variables are integers, but that relationship will still hold if a and b are floats, if q = a // b. If q = math.floor(a/b) the relationship won't hold in general. And so // might be preferred because it satisfies this nice mathematical relationship.

Thursday, October 28, 2021
answered 2 Months ago

You can try with:

display:table,table-row, table-cell

In this case you will be able to use vertical-align property:

You can check updated example here:

Unfortunately this doesn't work in IE6. In case of IE6, you can position buttons with javascript.

Monday, November 29, 2021
answered 1 Week ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :