You can see an example here. If You’ll inspect the “search” button in the end of the left sidebar, and float it to the left, it will totally get out of the box, but if you will give it’s parent element, display: inline-block and width: 100%. The problem will be solved.
About the clear: both; I have read several times that a floated element can at lease in some cases, drag elements are one stage above in the DOM, and these could no longer be dragged if they are cleared respectively.
No, I remember clearly putted it there and clicked enter but it didn’t saved for some reason. In the second it automatically appeared in the end of the text but now in the third edit It appeared fine. Wired. Anyway, you are invited to take a look.
That’s because your initial setup is quite unusual and should not work properly.
The input element has display: block but its parent has display: inline.
So you have a block element inside an inline element, that should not happen and should not be expected to work.
Of course changing the parent to a valid display type to contain a block will fix things.
I believe I partially answered this in one of your other threads but here are the details again.
When you float an element it is removed from the flow. That means that the parent no longer accounts for that element being within its boundaries. So when you float the search button the containing parent says ‘search button’ no longer exists as far as I am concerned.
If you apply clear:both to the search-button it will make no difference to the parent because search button is still floated. If you apply clear:both to a non floated static block element that is after the floated search button but still within the parent div then the parent div will recognise that static element and encompass it correctly. This is effectively what the clearfix technique does. It places an element at the end of the parent and clears it.
Now on to more complicated rules:
Some properties on elements create new block formatting contexts and in this context they will automatically contain any child floats. The properties are : overflow other than auto, absolutely positioned elements, floats, elements with a display of table-cell and inline-blocks. If a parent element has any of these properties applied then it will automatically contain its floated children. The most useful of these being overflow:hidden (invented by me as a clearing mechanism years ago) when you don’t require visible overflow.
Understanding block formatting contexts is the key to understanding the various behaviours of floated elements.
Sam, I didn’t see any parent with display:inline and it would not have any effect on the question answered so I think you may have got the wrong end of the stick (or I have).
Benos asked about floating the search button which will make the gray background not wrap around the element. Then adding display:inline-block to a parent will create a new block formatting context which will ensure that the parent once again encompasses its child float. I believe that was the crux of the post.
The site is in a character set I don’t understand, never mind the language, so I had to guess which was the search button.
The element I guessed to be it was the yellow input button at the bottom of the sidebar. Its div container has display: inline.
Ah ok I see it now, I looked at the other search button.
It will make no difference to what I said though and adding display:inline to the parent of a block element will effectively do nothing in this case but is not invalid (an anonymous block box will be created but is a question for another day as is rather complex).
I never asked here on display-float relationship before (I’m trying to understand if there is one) but I did ask about clearing floats - A thing I tried with the previous element which comes before the search button. That is:
<div id="edit-actions--2" ...>
Very important for me to know: Did you meant that one by “after the floated search button” ? I guess you did since everything that comes after it is either hidden or unrelated to the sidebar so I don’t see how it will interrupt the floated button.
BTW, it’s a premium theme… Maybe the themer did a mistake there, I really don’t know. When I’ll have enough knowledge I plan to create my own theme from a framework (so wait for that)…
Clearing floats its a different question to containing floats although they have things in common.
My previous post #7 explains exactly the process so I suggest you read it again and again until it makes sense. Floats are not as straight forward as they may seem but eventually it will all sink in
Adding clear:both to a parent of a float** does nothing for the parent to contain a child float.** Adding clear:both to a parent will ensure that the parent starts after any other floats. If the parent is a non floated element then all other floats above it in the html will now be contained within the same parent. It will do nothing for any floats that follow (are after) the element that was cleared.
Any non floated html content (static block elements) that are after the floated search button in the html but within the same parent as the float can be used to contain the floats to the same parent by applying clear both to aforementioned content.
…another div with clear:both to this block element
…end of divparent
Using an empty element to achieve this is not recommended so you use one of the other methods already mentioned.
I’ve read the aforementioned comment again. It did made more sense to me. I think I misunderstood the concept of a possible occurrence of a floated element dragging the very next element as “the very previous” element since when I read about it in Hebrew (I think) it was was “Ze she Aharav\אחריו” which might sometimes be interpreted as “the (one that is) behind it” — up in the DOM.