Why no rule for un-collapsing margins - css

There are circumstances under which elements' vertical margins will collapse. Sometimes the author doesn't want this to happen, and I understand that the only way to "un-collapse" margins is to:
Set a border sized >= 1px
Set a padding sized >= 1px
These workarounds make sense to me, but they are just that: workarounds, and they have drawbacks. I'm surprised that there's not some kind of css3 property like margin-collapse: none;, similar to border-collapse.
Is it really true that setting a border/padding is the only way to uncollapse margins?

No, there are numerous other ways, including floating, clearance, absolute positioning, setting overflow to values other than visible, setting a certain min-height, etc, which you can determine based on what the spec says.
But you're right in that all of these are workarounds with various side effects and disadvantages, and there is no true "off switch" available in CSS like margin-collapse, not even in the CSS3 Box Model module. A possible rationale is that margin collapse is supposed to happen naturally, and therefore the only way it can be prevented is as a side effect, but that's just my guess, as I agree there are several cases where it isn't intuitive or appropriate.
That said, if you're feeling adventurous you could make a suggestion on the www-style mailing list, and see what they say. I don't think you're going to have much luck, though.

Related

css positioning far right - with minimum width

I am a mostly skilled server-end developer, and am creating an ambitious website project - all by myself. I know c#, MVC, T-SQL, LINQ, and ASP.NET pretty well. Obviously, since I'm working by myself, I have knowledge in design too. I'm obviously good with html (who isn't?). And I absolutely love jQuery! The thing is, I'm decent in my understanding of css, but css is my least knowledgeable trait. I understand programming, I also am good in design, not just because I have a decent level of knowledge in css (and jQuery) - but also because I just know what looks good (I can draw and paint on real paper too).
The thing is, I know I can probably do this with jQuery code, but I was wondering if this could also be done with css alone. On my main design (Views/Shared/_Layout.cshtml) - I made the body to have a "min-width: (my value);" attribute, which, obviously isn't supported with older browsers, so I also included a transparent image of a default width of 1px that I set to stretch to my desired width also - it works in controlling the width of the page (to the minimum I desired). But - I have a site header div which resides at the top of the page. I have a part of that header div with elements positioned on the far right - which is nice when the browser is on a device that is large enough and the browser is in decent size, but once the browser is set to a size less than my desired minimum width, then the scroll bar shows up, and I can move it around as expected. But, the elements in that header div do not stay to the far right in conjunction with my minimum width - but stay on the right of the current window size instead. I have the main div holding the elements itself set to be in fixed position, I tried making those elements relative with no success. I tried a few ideas, the problem still persists.
So, as I said, I am well aware of concepts using jQuery that can do what I have previously described I desire in these regards, but, as I also said, I know a decent amount of css, but am the least close to an "expert" in css than anything else I know. I just have a strong suspicion what I desire here can be done with css and css alone (also, it would be nice to have it compatible with most browsers, or at the least most browsers made after the year 2008).
Can someone please give me some good information in these regards?
I just remembered asking this question.
I actually found a way to go about doing what I wrote I desired here through some experimentation that eventually got me to where I needed to be. What I did was instead of using relative positioning - which I thought was the proper way of doing this, I used absolute positioning inside the absolute positioned top header div. I didn't think this would be the solution at the time of asking the question, I assumed setting something as absolute positon - even inside something that is already absolute positioned - would put it in a new context of absolute positioning like any absolute positioned element inside the body tag. What I discovered was if I put an absolute positioned element inside another absolute positioned element - the context of the absolute positioning was based on the original absolute positioned element - so top (or left for that matter) 0px wasn't 0px from the context of the body (the very top of the page) - but - 0px from the element that the element is inside of. I think that's a pretty explanation of it, so I'll end explaining it here.
I'm sure there's plenty of people that know css much more than I do, and think this issue I had here is so basic, but, I did ask the question, and I might as well answer it based upon the solution I used. I could've posted an example on jsfiddle like asked for in a comment, but I thought my explanation was good enough, and since no one offered an answer based on my question alone, I decided to try to address the issue with experimentation, which I had success with.

Padding vs children with margins

Let's just start with saying I understand the box model. Throughout my short time as a developer, I've tried to stick very closely to semantic html and use responsive design practices. I recently got a job at a new company as Jr. Developer, and my Sr. is religiously against padding. Like he doesn't want it used in any case whatsoever. He wants me to use set heights and widths on everything, and if I need to simulate padding, I have to add a child div using margins. For example:
<div class="caption" style="padding: 5px;">
Caption
</div>
Would need to become
<div class="caption">
<div class="captionContainer" style="margin:5px;">
Caption
</div>
</div>
I've tried to figure out why this would be, and how I could possibly explain why I think that's bad, but it doesn't work. It just seems so wrong to me. He's said that it's because padding stretches the width of an element, to which I responded with box-sizing:border-box.
I have to do what he says, but sometimes we talk about it, and he does seem somewhat receptive to my suggestions, but I don't think I'm saying the right things. Is it actually better? If it's not, why?
This question may get closed for being kinda discussion-y but this has been driving me crazy, and I don't know where else to turn.
Thanks in advance!
It's anything but better. There is no sense in trying to add padding to a box using other methods when a CSS property made for this exact purpose, padding, has existed since pretty much forever.
Anyway, one counter-example I can think of is the fact that adjoining vertical margins can collapse.
There are several ways to cancel margin collapse (heck, giving an element padding is one!), but these methods aren't designed for preventing margin collapse as much as they do so as a side effect, and there is no simple "off switch" for collapsing.
Authors who don't understand the nature and the purpose of collapsing will find themselves having a world of trouble dealing with it. If you're going to use margins to simulate padding you may be in for a hard time. It's not worth it.
Your given markup is a prime example of when margin collapse can happen unexpectedly and cause headaches: if there are no other styles on your .caption element (like borders or padding), the margins of .captionContainer will combine with those of .caption, resulting in something like this happening. In the same vein, it's a great counter-example of when trying to simulate padding using margins ends up backfiring.
Compared to the potential issues caused by margin collapse, I honestly find your suggestion of using box-sizing: border-box a good case against using margins to simulate padding, while preserving the exact widths that you need because it's designed to solve that problem. Browser support is fairly decent too (IE8+), so unless you're designing for really old browsers, it should be OK to use it.
There are several other potential pitfalls of using margins to do things that padding was clearly made to do, but margin collapse is one of the biggest issues you'll face.
Explain him this way:
Margin is on the outside of block elements while padding is on the inside.
Use margin to separate the block from things outside it, and padding to move the contents away from the edges of the block.

prevent layout breaking in zoom-in/zoom-out of the browser - not the usual div thing

So I did notice that zoom related layout problems are commonly being dealt with, but I couldn't find an answer to my case - I wrote a WEB calc, and the buttons just slide out of place when zooming in and out, in Chrome and Firefox but not in IE. What is the way to fix it?
Give width:220px to your #main div
If you closely look at your CSS you will see that the buttons together(5 in a line) actually have more width than the Main div while resizing. Increasing the width to 220px solves that problem. Another solution could be to give max-width and max-height to all elements, another can be to properly layout your elements and don't just rely on the browser's positioning. Doing the latter is an trivial task.
For the sake of searchers, my solutions was to use a table to make the calculator eventually. I know using tables for layout is considered a bad practice, but considering a calculator shape is not supposed to adjust to new contents or to the size of the end-user's screen (at least in my case) it seemed to be the best implementation. It was the only way to avoid losing the layout shape in zoom-in zoom-out, which is kind of what div's are all about.

Disadvantages to using CSS word-wrap globally?

Are there any disadvantages to using word-wrap:break-word in the following way?
body
{
word-wrap: break-word;
}
The descriptions of the values for this property are as follows:
normal: Break words only at allowed break points
break-word: Allows unbreakable words to be broken
Now, this only makes a difference in the breaking of unbreakable words (i.e. continuous strings that are longer than their containers). Otherwise, it'll make no difference for 99% of text anywhere.
So, are there any disadvantages to using this globally? It can certainly solve a lot of layout issues without (at least as far as I can see) having any adverse effects. It seems better to do this once than to have to apply it everywhere you could possibly have overflowing text that would mess up your layout.
I can't think of any disadvantages since, if you want to have some other kind of word-wrap elsewhere, you'll always be able to override this global style.
That said, if you can at all narrow down the situations in which this will be necessary, using a broad class would be preferable. There's no telling what rare but very frustrating bugs a global break-word style will cause (and in what browsers).
I can't see any advantages of making it global on a page if the page is anything other than a test page.
For me I would not want words that are unbreakable to break at all. It's easier to read when they are not broken up. However if you want to make your text fit a div without using text-align:justify; and leaving gaps in between letters or words it might be nice.
The reason why I said in other than a test page was because sometimes, when I wanted to use place holder text besides "lorum ipsum" I would type gibberish but the div would always stretch. But since I wouldn't be using that text on the live site, I probably wouldn't use it.
I think the only consideration would be support in IE8.
According to this, word-wrap: break-word; doesn't work in all scenarios.
This property applies to elements that have layout. An element has
layout when it is absolutely positioned, is a block element, or is an
inline element with a specified height or width.
Of course, this seems quite easily rectified, but it should be known in case you need to support IE8 and you intend to apply this to items that do not "have layout".
Interesting are the new CSS3 properties:
http://www.w3.org/TR/css3-text/#word-break
http://www.w3.org/TR/css3-text/#word-wrap

Can you explain css code like below?

margin-left:-500px;margin-right:-500px;
What's the meaning ?Why do it like that ?
Read this nice article: The Definitive Guide to Using Negative Margins
Negative margins are usually applied in small doses but as you’ll see later on, it’s capable of so much more. A few things to note about negative margins are:
1. They are extremely valid CSS
I’m not kidding on this one. W3C even says that, “Negative values for
margin properties are allowed…” ‘Nuff said. Check out the article for
more details.
2. Negative margins are not a hack
This is especially true. It’s because of not understanding negative margins
properly that it got its hackish image. It only becomes a hack if you use it
to fix an error you made elsewhere.
3. It goes with the flow
It does not break the flow of the page if applied to elements without floats.
So if you use a negative margin to nudge an element upwards, all succeeding
elements will be nudged as well.
4. It is highly compatible
Negative margins are wholly supported across all modern browsers (and IE6
in most cases).
5. It reacts differently when floats are applied
Negative margins are not your everyday CSS so they should be applied with
care.
6. Dreamweaver doesn’t understand it
Negative margins don’t show up in the Design View of DW. Why are you even
checking your site in Design View anyway?
It probably cancels out the 500px padding on the parent element:
<div style="padding-left: 500px; padding-right: 500px;">
<div style="margin-left:-500px;margin-right:-500px;"></div>
</div>
i read once (reference forgotten) that negative margins are supposed to send elements out of the way, sending them to the left most side of the browser. It is meant to hide elements out of the browser if you dont want to use
style="display:none"
does the element with the negative margins behave this way?

Resources