Re: .clearfix

On 10/18/13 12:08 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Fri, Oct 18, 2013 at 11:52 AM, Kang-Hao (Kenny) Lu
><kanghaol@oupeng.com> wrote:
>> (2013/10/19 2:00), Tab Atkins Jr. wrote:
>>> On Fri, Oct 18, 2013 at 9:31 AM, Kang-Hao (Kenny) Lu
>>> <kanghaol@oupeng.com> wrote:
>>>> Given Alan's compliant, that's start a new thread.
>>>>
>>>> (2013/10/18 23:47), Tab Atkins Jr. wrote:
>>>>> Getting a container element to contain its floats has been addressed
>>>>> directly in the Sizing spec, though it hasn't gotten implementation
>>>>> yet.  You can set "min-height: contain-floats;" to make it work:
>>>>> <http://dev.w3.org/csswg/css-sizing/#the-contain-floats-value>.
>>>>
>>>> Unless I am missing something, "getting a container element to contain
>>>> its floats" is not the requirement, the requirement is "getting the
>>>> parent of the targeted element to contain its floats". Note that the
>>>> targeted element is different.
>>>
>>> Why is this important?  Why can't you just target the parent directly?
>>
>> Since I don't have much Web development expereince, I can't quite anwser
>> that. My guess is that for new 'float' users, it's not easy to think of
>> a 'float'ed element as something out of the normal flow. For example,
>> [1] mentions this question
>>
>>   If I understand it right clear float is automatic in most modern
>>   browsers right?

No Kenny, it's not the case. The notion that clearfix is/was a patch for
older
browser is actually a misconception in people's mind. Probably due to the
'fix' part of the word.
http://www.impressivewebs.com/clearing-floats-why-necessary/

>> from a CSS newbie. In other words, it might be more natural to have a
>> mode in the 'float' property that doesn't exclude the element form the
>> normal flow, say, something like
>>
>>   float: left in-flow;
>
>Floats are intrinsically not in-flow.  What we really need is to
>continue the implementation of Flexbox and Grid and similar things,
>which'll make most of the use-cases for floats and clearfixing go
>away.

Indeed. I began to understand this concept myself much more clearly, only
recently.
"left in-flow" is what inline-block does. But inline-block present its
own inter-block spacing problems for use as "pre-cleared blocks".
http://css-tricks.com/fighting-the-space-between-inline-block-elements/

>
>> But I really don't know. Bruno, in
>>
>> (2013/10/18 16:38), Bruno Racineux wrote:
>>> I believe (or rather assume) that Flexbox does fix the problem 'within
>>> the flex layout', but that does not give a native clearfix property
>>> outside of the Flex scope. The need to clearfix can apply to other
>>> situations.
>>
>> , what are those situations and are they fixed by 'min-height:
>> contain-floats'?

What I mean is that Flex boxes will still co-exist be side by side with
other display types not necessarily Flex themselves.
And apparently it turns out that 'min-height:contain-floats' do not
substitute
for a good clearfix yet...

Just to try and broadly explain the dilemma that always plagues css
designers here.
The two most common spacing issues people encounter (including myself,
over and over again, before I got a better grasp of the specs on this) are:

1. Realizing that inline-block(s) are not floated, but aligned in the
flow, with left and right spacing issues. As best explained by the
css-tricks article.

The double solution to reliably using inline-block(s) in a wrapper is:

.wrapper {
  font-family: monospace;
  letter-spacing: -0.63em;
  font-size: 0;
}

This deprives the wrapper itself from having its text-flow and keep the
inline-blocks (or inline-tables) cleared of spacing issue.



While this works, this is a hurdle, and difficult to understand for
newbies. Therefore, we instead often resort to using floated blocks
instead, which introduces the added caveat of having to clear floats. Or
worse, we end up floating everything.


2. Having issues with background colors not filling blocks, or spacing
issues caused by uncleared floats. For that, overflow:hidden is very
useful because it fixes both (as well as previously addressing old IE6/7
issues along the way)

And if you happen to wrap both inline-block(s) and float(s), both
"patches" have to apply at the container level.


I see some work here with other attempts at new display keywords:
http://dev.w3.org/csswg/css-box/#display


Also specs in the works on a 'clear-after' property:
http://dev.w3.org/csswg/css-box/#clear-after


A new "display:cleared-block" type could be much more suited to address
both 'background filling' and 'clearing the float" without the unnecessary
headaches I think.
Perhaps it's what the 'container' keyword attempt to achieve there? Not
sure.
There a lot of questions and issues there, and it's very large document to
parse...

The inline-block case is more peculiar, maybe 'display:inflow-block'?

>> Scotts in [1] says
>>
>>   That ('min-height: contain-floats') basically solves the clearing
>>   problem, as long as you have a parent wrapper. A nice note for the
>>   future.
>>
>> . I wonder
>>
>>   1) how much chance do you get a wrapper?
>
>The definition of clearfixing is making a wrapper grow to contain the
>float.  If you're trying to "clearfix", you have a container in mind
>that you're trying to clear, which can accept styling.
>
>>   2) is that the case that adding a dummy class="contain-floats" might
>>      be the problem (say, you can't change HTML)?
>
>The types of things that are "significant containers" that need to
>grow in these cases are the kinds of things that are generally easy to
>target in CSS, as they probably have other reasonable classes on
>themselves.

That is true. But because of their wicked nature. It is extremely
difficult for a novice to understand the need to "clearfix" or those
inline-block spacing issues.

We are using either a floated block, an inline-block or a non-floated
block with a clearfix hack, often mainly in order to simply have blocks
vertically stacked (e.g. header, nav, main, footer) without any unwanted
"freaking" spacing issues or background holes. You'd think one could very
simple things like that by now with no hacks.



>~TJ

Received on Monday, 21 October 2013 09:10:24 UTC