Flexbox item wrapping

#41

It looks like I was wrong about that last comment. What I was referring too as 'remaining space available' is actually different for flex grow and flex shrink.

Looking back at the Codrops Flexbox Reference they define the space as 'free space'.

flex-grow distributes the positive free space
while
flex-shrink distributes the negative free space

The conditions which create those spaces are the opposite. As Paul explained above the positive free space is created when the total content does not fill the parent's width.

It appears that negative free space is defined as total content space that exceeds the parent's width.

According to the flex-shrink summary at codrops, they define the negative free space as...

If the sum of the main sizes (see concepts and terminology) of all flex items is greater than the main size of the flex container, you can specify just by how much you want to “shrink” the flex items. The amount by which the flex items’ main sizes exceed the container’s main size is the negative space. Using the flex-shrink property, you can distribute this negative space over the flex items. The negative space is distributed in proportion to flex-basis multiplied by the flex-shrink ratio, where the flex basis is the initial main size of the flex item, before free space is distributed according to the flex factors.

So the flex factor vs. free space condition's are opposite between flex grow and flex shrink.

I suspect the intention of the flex-shrink default value being (1) is that it will be needed more often than than flex grow will. 

Initial value of the flex shorthand:

flex-grow: 0
flex-shrink: 1
flex-basis: auto

"The devil is in the details", I think I got it right this time. :neutral_face:

One thing I do know, is that the best way for ME to learn is when the code I write actually does what the specs say it should be doing. Then it sinks in and gets logged in my noodle.

#42

You should not being using important, it is really reserved for using when there is no other possible way to override an element. Usually only needed when you have to override styles from an external source.

I suspect you've got a specificity problem elsewhere, your not writing IDs' back into your page again are you?

#44

no I used class but rule was not applying to it for some reason. Rule only took effect when I applied !important to that tag

#45

You are missing the point and specificity can always be overridden without using !important as far as external styles are concerned (i.e. styles in the head or external stylesheets but not styles that are inline in the tag itself that are using the style attribute).

You just need to look at your web inspector and see where the rule gets its styling from and then match that rule when you want to over-ride it.

e.g.

If you say #content .myClass{display:none} then you will need to say #content .myClass{display:block} to over-ride it where the latter rule in the stylesheet wins out because the specificity is now the same. You can always make sure your rule wins out without using !important unless you used !important in the original rule.

Most times you don't need !important unless you know why you are using it. It's never to be used as a band-aid simply because you failed to work out the specificity. That is a lazy and error prone approach that leads to worse specificity problems along the line (e.g. everything needs !important in order to over-ride the !important).

I don't say never use !important because sometimes when working with third party (or other peoples) code you may have a rule defined in multiple states with multiple selectors and to match specificity you would need to use all their nonsensical convoluted rules when a simple !important will do the trick. You will also need !important to over-rule styles that are in the style attribute as there is no other way to do that.

Lastly !important is good to use as a debugging tool because sometimes a rule doesn't seem to work and you may think there is a specificity issue so adding !important can be used to tell if you are targeting the right element or maybe just have a typo. Once resolved you can remove the !important and fix the issue properly.

So 99% of the time don't add !important :slight_smile:

#46

Why does using image 300x200 as anchor pushes image up?

#47

Hi,
You would need to post a link to your relevant code, I assume that is where you have an anchor or something pushing the image.

The code in my post #23 that you replied from doesn't use an anchor.

#48

ok so I have rule which I am applying to page A

.my_rule {
   display: flex;
}

Can I do this or do I just create new class for page B?

.my_rule {
   display: block;
}

I can always just call this class differently on page B

#49

so what I did is I added 

id="myID"

to my HTML element on page B and then used selector

#myID.my_rule {
   display: flex;
}

That seems to work, Did I do this correctly?

#50

How many times have we told you not to use ids for styling now ? :slight_smile:

You could have just used a new class or two classes if you are modifying the existing rule.

The bigger question is why you need to change the rule on different pages and if so shouldn’t they just be different classes to start with

However as you don’t supply a context we can’t say whether your approach is right or wrong but it looks dubious to me :slight_smile:

#51

Bad habit I guess (

I want to use same rule from page A in page B with only difference that now I want this div to be block instead of flex box.

So in cases like that should I just use new class and new rule or override it with adding another class to this element?

#52

You can add a class to the body tag of page B to target any rules on that page differently.

<body class="pageB">

.my_rule {
   display: flex;
}

.pageB .my_rule {
   display: block;
}
#53

If page b is different from page a then why use the same rule at all?

You are only making things harder in the long run because if you make other changes to the original rule then it will affect both pages again and you will have to undo styles once more.

Generally it is considered bad practice to over-ride rules because it means you were too specific to start with and had not thought the process through. Additional classes should be additive rather than negative for easier maintenance.

In the end we are probably all guilty of throwing in an extra class to correct something but it does make long term maintenance more difficult. :slight_smile:

Again without seeing the HTML and css for both pages I am just making broad assumptions. It may be ok for you to over-ride in this instance but only you will know that:)

closed #54

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.