normalize.css and vertical margins for block elements - html

I am imagining there is a good explanation for this but so far it has more annoyed me than helped.
Normalize.css adds 1em margins to elements (and some others). While I see the point from the visual side, it means it often prevents block elements to "touch" each other. I am overriding this at present but would love to understand the reasoning for the vertical margins or if there is a trick I am missing to counteract this side-effect. I am sure some good thinking went into that tweak.
p {
margin: 1em 0;
}
Here is a fiddle reproducing what I mean:
http://jsfiddle.net/d6njL0zn/
Thanks!

Most browsers come standard with 1em vertical margins on elements. That is why Normalize.css also has it. Normalize just takes the normal css defaults in a browser and makes them more consistent across all browsers.
If you would like complete control over how your css is set up, consider using reset.css

HTML2 developed in 1995 had margins for the p and pre tags. The default CSS values are to make those pages which do not use CSS display the same as they did back when they were written. I could be mistaken but I believe the default margin for the body tag of 8 pixels was Microsoft's idea.

Related

Can CSS margin be avoided altogether in favor of padding?

As I am sensitive to sensory overloads and get confused with too many visual details, I would like to simplify my palette of CSS features to a managable toolkit but without really compromising too much of the aesthetic appeal. In light of that, I seem to be hopelessly lost balancing between margin and padding of my HTML elements.
So I am contemplating to stop using margin altogether in favor of padding. To me, who is not a visual/HTML expert by any means (I am more of a backend programmer by experience), it seems doable, however, I am sure there is a reason the distinction exists.
By this post, I am asking gurus to please explain the cons of using and not using both margin and padding and whether reasonably elegant design can be accomplished by using only one of the two. It would also be great if someone could submit examples to illustrate something that can be accomplished with one and not the other.
No not in every aspect.
Margin and padding are two completely different things. Padding will add to the overall size of the objects width or height whereas margin will not.
Imagine you have a set of links that are floated left. Just using padding on the links will cause the anchor element to be very big and quite possibly not what you would want. Whereas using a little padding and also a margin to increase the space between the anchors would be more suited.
Using margin ensures that something is so far from something else.
Using padding ensures that the content of something is so far from its own edge.
If you had a layout of boxes on a page and you wanted to have spacing between each box and also a border, using padding alone would not suffice so you would have to use margin as well.
As a general rule use each when it is needed. I know what you mean about things getting messy in your css but there are ways to simplify things. For a simple site I have done the following before.
css
.leftMargin {margin-left: 10px;}
.rightMargin {margin-right: 10px;}
.topMargin {margin-top: 10px;}
.bottomMargin {margin-bottom: 10px;}
.leftPadding {padding-left: 10px;}
.rightPadding {padding-right: 10px;}
.topPadding {padding-top: 10px;}
.bottomPadding {padding-bottom: 10px;}
Then you can easily set universal padding and margin rules without too much bother. But then again you could argue that this creates unmanageable html markup.
It is really something that you have to work out for yourself. Something to consider though is using only margins can have very undesirable affects! More to the point of collapsing margins Why does this CSS margin-top style not work?.
Hope this helped.
Well I would say that you cannot avoid using margin and that they have different uses.
Padding should be used to create space between the edge of your element and the content whereas Margin should be used to separate elements.
If you never use borders then arguably you could do away with 1 of them but if for instance you have 2 divs next to each other, both with borders but you don't want them touching, how do you plan on separating them? It is possible to position them but often margins are the best way.
Also consider that the total element width is width + padding whereas you could argue the margin size is 'outside' the element although still technically part of it.
I have a lot of style markup and use padding and margin equally
The simplest example I could make, to show you the differences between both concepts is this one.
Notice that margin is the space between the border (red color) and the surroundings, while padding is the space between the contents (in the example is the text) and the border.
Usually you will need to use both of them. However in the few cases when you don't need to use a border at all, you can manage pretty well by just setting one of them.
No, not if you want to do complex designs
The holy grail of web design uses a combination of margin and padding
Even though margin and padding can at times do similar things, the purpose of each is different.
margin refers to the space required on the side of an element relative to other elements
padding refers to space between the content of the element and its border
The power having margin and padding is realized when you use both together.

float:left; vs display:inline; vs display:inline-block; vs display:table-cell;

My Question(s)
Are any of these methods preferred by a professional web designer?
Are any of these methods prefereed by a web browser when drawing the website?
Is this all just personal preference?
Are there other techniques I'm missing?
Note: Above questions are in regards to designing a multi-column layout
float:left;
http://jsfiddle.net/CDe6a/
This is the method I always use when creating column layouts, and it seems to work just fine. The parent does collapse on itself though, so you just need to remember to clear:both; afterwards. Another con that I just found was the inability to align text vertically.
display:inline;
This seems to correct the problem of the collapsing parent, but adds whitespace.
http://jsfiddle.net/CDe6a/1/
Removing whitespace from html seems to be the easiest fix this problem, but is not desired if you are really picky about your html.
http://jsfiddle.net/CDe6a/2/
display:inline-block;
Seems to behave exactly like display:inline;.
http://jsfiddle.net/CDe6a/3/
display:table-cell;
http://jsfiddle.net/CDe6a/4/
Works perfect.
My thoughts:
I'm sure I'm missing a ton of stuff, like certain exceptions that will break the layout but, display:table-cell; seems to work the best, and I think I will start replacing float:left; as I always seem to mess up on clear:both;. I've read many articles and blogs about this on the web, but none of them give me a definite answer on what I should use when laying out my website.
Of the options you asked about:
float:left;
I dislike floats because of the need to have additional markup to clear the float. As far as I'm concerned, the whole float concept was poorly designed in the CSS specs. Nothing we can do about that now though. But the important thing is it does work, and it works in all browsers (even IE6/7), so use it if you like it.
The additional markup for clearing may not be necessary if you use the :after selector to clear the floats, but this isn't an option if you want to support IE6 or IE7.
display:inline;
This shouldn't be used for layout, with the exception of IE6/7, where display:inline; zoom:1 is a fall-back hack for the broken support for inline-block.
display:inline-block;
This is my favourite option. It works well and consistently across all browsers, with a caveat for IE6/7, which support it for some elements. But see above for the hacky solution to work around this.
The other big caveat with inline-block is that because of the inline aspect, the white spaces between elements are treated the same as white spaces between words of text, so you can get gaps appearing between elements. There are work-arounds to this, but none of them are ideal. (the best is simply to not have any spaces between the elements)
display:table-cell;
Another one where you'll have problems with browser compatibility. Older IEs won't work with this at all. But even for other browsers, it's worth noting that table-cell is designed to be used in a context of being inside elements that are styled as table and table-row; using table-cell in isolation is not the intended way to do it, so you may experience different browsers treating it differently.
Other techniques you may have missed? Yes.
Since you say this is for a multi-column layout, there is a CSS Columns feature that you might want to know about. However it isn't the most well supported feature (not supported by IE even in IE9, and a vendor prefix required by all other browsers), so you may not want to use it. But it is another option, and you did ask.
There's also CSS FlexBox feature, which is intended to allow you to have text flowing from box to box. It's an exciting feature that will allow some complex layouts, but this is still very much in development -- see http://html5please.com/#flexbox
I usually use float: left; and add overflow: auto; to solve the collapsing parent problem (as to why this works, overflow: auto will expand the parent instead of adding scrollbars if you do not give it explicit height, overflow: hidden works as well). Most of the vertical alignment needs I had are for one-line of text in menu bars, which can be solved using line-height property. If I really need to vertical align a block element, I'd set an explicit height on the parent and the vertically aligned item, position absolute, top 50%, and negative margin.
The reason I don't use display: table-cell is the way it overflows when you have more items than the site's width can handle. table-cell will force the user to scroll horizontally, while floats will wrap the overflow menu, making it still usable without the need for horizontal scrolling.
The best thing about float: left and overflow: auto is that it works all the way back to IE6 without hacks, probably even further.
I'd say it depends on what you need it for:
If you need it just to get 3 columns layout, I'd suggest to do it with float.
If you need it for menu, you can use inline-block. For the whitespace problem, you can use few tricks as described by Chris Coyier here http://css-tricks.com/fighting-the-space-between-inline-block-elements/.
If you need to make a multiple choice option, which the width needs to spread evenly inside a specified box, then I'd prefer display: table. This will not work correctly in some browsers, so it depends on your browser support.
Lastly, what might be the best method is using flexbox. The spec for this has changed few times, so it's not stable just yet. But once it has been finalized, this will be the best method I reckon.
I prefer inline-block, although float is also useful. Table-cell isn't rendered correctly by old IEs (neither does inline-block, but there's the zoom: 1; *display: inline hack that I use frequently). If you have children that have a smaller height than their parent, floats will bring them to the top, whereas inline-block will screw up sometimes.
Most of the time, the browser will interpret everything correctly, unless, of course, it's IE. You always have to check to make sure that IE doesn't suck-- for example, the table-cell concept.
In all reality, yes, it boils down to personal preference.
One technique you could use to get rid of white space would be to set a font-size of 0 to the parent, then give the font-size back to the children, although that's a hassle, and gross.
For the record only, to add to Spudley's answer, there is also the possibility to use position: absolute and margins if you know the column widths.
For me, the main issue when chossing a method is whether you need the columns to fill the whole height (equal heights), where table-cell is the easiest method (if you don't care much for older browsers).
I prefer inline-block, but float are still useful way to put together HTML elemenets, specially when we have elements which one should stick to the left and one to the right, float working better with writing less lines, while inline-block working well in many other cases.

What is the purpose of this CSS snippet?

I have the following snippet in my stylesheet. What is the impact or purpose?
* {
margin:0;
padding:0;
top: 0px;
left: 0px;
}
It is a reset. All elements will have 0 margin, padding, etc. after that.
Such resets are useful to normalize behavior (some browsers come with predefined margins, paddings, etc.) and to increase visual consistency across browsers.
It's a reset CSS. It's purpose is to remove default non-zero spacings for all (*) elements. All browsers have some default style sheet and they're not very consistent with each other. Take <form> as an example.
Note: Setting the left and top properties to 0px doesn't look right to me. It will most probably cause problems with absolute positioning. When positioning an element absolutely you may want to define only it's vertical or horizontal offset (not both), leaving the other offset unchanged. That reset CSS doesn't allow that because it gives values for both vertical and horizontal. Also you may want to position an element from the bottom. If you have that reset it will have both bottom and top which in most cases is not wanted and may alter the height of the element or not respect one of the offsets. In any case it will give you something not intended and break your layout.
For those who want to learn more: http://www.w3.org/TR/CSS2/visuren.html#absolute-positioning
It applies the rules contained within to all elements of the page; creating a predictible baseline for cascading rules.
The technique is called a "reset" (google for "CSS Reset") and is an approach to resolve different browsers using different default CSS rules.
These rules should applied as early as possible, typically at the start of the first-loaded CSS sheet.
The purpose of your snippet is to reset the margin, padding and set the position to the top-left corner of the viewport in your web-browser.
The Estric simbol is known as all /everything so the meaning of this is the CSS will be implemented over all elemetns and set the values as parametered.

Is there a need for zero-out DIV's margin and padding?

I wonder if on any browser div element comes with a preset margin/padding value other than zero. As far as I know, div and span come with zero padding and margin values by standard to make them suitable canvas for style decoration.
Even better, is there a definite standard for default styles for all elements that is cross-browser which we can make assumptions upon? For instance FORM comes with top/bottom margins, OL/UL come with padding-left's.
I occasionally see a
* {
margin: 0;
padding: 0;
}
and this just looks like a dirty hack without knowing the reasons or consequences. Anyone has any better approach to this?
Different browsers have different defaults -- this is why using CSS resets like these
http://meyerweb.com/eric/tools/css/reset/
http://developer.yahoo.com/yui/reset/
are popular in order to insure that browsers are treating all the elements equally. It gives you a baseline and then expects you to define all the relevant styling.

Not using widths & padding/margins on the same element?

I've seen numerous people mentions that you shouldn't use widths and padding or margins on the same element with CSS. Why is that?
Because some browsers treat the width as the total width of the element including the padding and the margins, and others treat the width as the base width to which the padding and margins are added. As a result your design will look different in different browsers.
For more information, see the W3C page on Box Model and quirksmode's take.
A lot of people still cling to notions about faulty box-models in IE and reckon that if you start messing around with element widths, padding and margins, you're going to get into trouble.
That's pretty outdated advice - assuming you're using a correct doctype, all fairly modern browsers (including IE6+) will work to the same box model, and you shouldn't really have too many issues related to it.
This being CSS, you will obviously have a million other cross-browser issues, but the infamous IE box-model is becoming a thing of the past.
I've never come across a problem caused by using width, padding and/or margin together.
So long as you have a valid DOCTYPE and are not in Quirks Mode, you will have a predictable box model and therefor should use whichever is most appropriate out of margin/padding to represent what you are trying to do.
Note:
Margin applies outside of borders, padding applies inside of borders.
Width means inner width of the container, the Total width = margin+border+padding+width (remembering that the first three are added for both left and right hand side).
Are you stating that padding and/or margin values shouldn't co-exist with a DOM element that also has a width value assigned to it? If so, that is only true if you do not want to write CSS that is compatible with both IE as well as browsers which implement web standards (e.g. Firefox). It would be difficult to achieve the layout you're looking for usually without some margin or padding value. But I suggest that you write CSS that is compatible for both browsers. If this is not what you are asking, then please correct me :)
The reason may be the famous box model problem.
Summary: IE renders width different then the standard rendering if padding and margin used with width or height.
I can think of 2 reasons:
1) the old "box model" of IE is really flaky, so when you have an element with the style { width: 300px; padding: 30px; margin: 20px;} it's outline might not actually match up to the expected 400px (300 px size, plus 2 30px padding, plus 2 20 px margin. I think its actual width would be 340, as it rolls the padding into the width calculation.
which brings is to...
2) Some people find the calculations a little confusing.
That said, I personally use widths along with padding and margins and have no problems with it. If you limit yourself to not using widths when using paddings/margins, that means you are peppering your code with a lot of non-semantic cruft. It does mean you have to be aware of what the various browsers are going to do with the element, but this is why we browsertest.
One important point to note is that it can make using percentage widths almost impossible. Take this for example, if you want your "content" div to take the full width, but have a 10px padding:
#content {
width: 100%;
padding: 0 10px;
}
That works in the (sensible, but incorrect) IE model, but in standards compliant browsers your div will occupy a width of 100% + 20px which is no good. The solution is to use another "inner" container.
<div id="content">
<div class="inner">
content here.
</div>
</div>
#content {
width: 100%;
}
#content .inner {
padding: 0 10px;
}
It's a bit annoying have the extra markup, but it makes a lot of things easier in the long run.