negative margins = bad?

Hi, I use a lot of negative margins on my website and was wondering if this is a bad thing to do...

thanks.

 

The use of negative margins, like anything else, can be a good or bad thing, depending on how it's used. It's maily used as a positioning aid (like with how the SPAN element "rides up" in the Gilder/Levin image replacement technique, or with flow-order based multi-column CSS layouts), but it does have other uses as well.

 

There's nothing bad about it unless you are positioning elements off screen, in which case it can look spammy to the search engines.

 

Actually that's what absolute positioning and display: none; are often used for. Negative margins (when used that way) will just expand the container (usually the viewport), wkhich can cause unnecessary (and often unsightly) scrollbars to appear.

 

no, no. it's only used for positioning certain elements. thanks for the input.

 

Very often, if you're using negative margins to tweak positioning, it's indicative of some issue that you don't fully understand. Consider closely the why of what you're doing.

cheers,

gary

 

it's mainly used to position a text-input box with an image beside it... negative margins seems to be the only fix I've found. the only problem is declaring different negative margin values for different browsers

 

Try setting the margins and padding of every element in your page to 0 by placing this at the very top of your stylesheet (you'll have to remove the margin: 0; padding: 0; rules from elsewhere in your stylesheet, then adjust your individual margins and paddings to taste, since this will strip everything of their margins and padding):

* {
    margin: 0;
    padding: 0;
}

Code (markup):

There's no need to use this to strip every element of their borders (since they have none by default, save for some form elements - and doing so will cause problems with form elements, so it's best to just strip the margins and padding with this technique.; and no, it's not an IE hack - it works cross browser).

 

That's not necessarily true. Just because the CSS validate, doesn't mean that the right code for the job has been used, or that the right code has been used, but in the wrong manner. Its one of those things that can only be determined through actual experience.

 

negative margins are absolutely vital. Just for a quick example. It isn't possible to absolutely position an element in the middle of a page without negative margins. (text-align:center + margin:auto != absolute positioning)

Say if you want a 200x200 div to appear in the center of the page you could use this.

div{
position:absolute;
width:200px;
height:200px;
left:50%;
top:50%;
margin:-100px 0 0 -100px;
}

The left and top 50% will place the upper left corner of the div in the center. To get the center of the div in the middle you need to use negative margins.

 

You could use that method, but it's very brittle, breaking easily. If you don't know the size of the centered box, it doesn't work. If the visitor decides to change font size, it could break. If the window is reduced to smaller than the centered box, half the overflow is lost and is not scrollable. Being absolute position, the centered box is not a part of the flow and may be in conflict with other elements' positions.

Here, simplified, is a more robust solution:

.outer {
    position: relative;
    display: table;
    vertical-align: middle;
    height: 300px;
    width: 300px;
    margin: 25px auto 0;
    border: 1px solid black;
    }

.inner {
    position: relative;
    display: table-cell;
    vertical-align: middle;
    width: 100%;
    }

.mid {
    border: 1px dashed silver; /*for clarity*/
    }

/*Now the hack for obsolete browsers-ok, just IE*/

* html .inner {
    top: 50%;
    left: 0;
    }

* html .inner .mid {
    position: relative;
    top: -50%;
    }
============
   <div class="outer">
      <div class="inner">
        <div class="mid">
          <p>and some text</p>
        </div><!-- end mid -->
      </div><!-- end inner -->
    </div><!-- end outer -->

Code (markup):

The .outer div can be treated as any block level container. It,
obviously must have a height declared, but otherwise you can do
pretty much what you want. I gave it a width, and centered it side
to side. It could just as well have been floated or left to use all
available width.

cheers,

gary

 

Pardon my ignorance Gary, but what's with the table display tricks? (It's what I consider using a style for something other than its intended purpose to do something that should be done via other means, a pet peeve of mine - in this case using table displays on non-tabular elements.)

 

Dan, you're confusing what an element is, html markup, with how an element is displayed, css.

cheers,

gary

 

Actually I'm not. To me, using table displays with CSS on non-tabular markup is about as bad as using DIVs to mark up a list of links.

 

You're kinda wrong on this one, Dan. You are definitely confusing the two. HTML and css are orthogonal to one another, intersecting only at the DOM.

HTML is simply a tagging to describe what an element is. There is no implication of how it might be displayed or what characteristics that display may have. To prove that to yourself, go to wherever you have Firefox, and in the res directory find a file named html.css. Rename that file, but don't lose it. Now open an html page that has a goodly variety of markup, with the author styles turned off. Tables, lists, links, everything becomes a totally unformatted inline text stream. All html does is tell the UA what something is. There is no implication of how it should be presented. OK, fix the name on html.css before you forget.

Now, css is a presentational markup language. It doesn't care which structural/semantic markup it's working against, only that the UA builds a proper DOM for it to be applied to. That's why we can make a link display as a block element, an inline element or an inline-block or whichever display characteristics we need. We simply have a bunch of property/value pairs that we can apply pretty much as needed. Because html doesn't care about how it's presented, and css doesn't care what it's presenting.

In the example above, I needed a container that could automagically center its content vertically. If we present that container using the table-cell model, we can use the vertical-align property to center its content. To take advantage of the table-cell model, its container needs the characteristics of the table model. In no way do we say that the construct is a table, only that it has those visual characteristics.

Another example of the use of the table display model would be for displaying poetry. Typographic convention calls for poetry to be aligned left, ragged right, and centered on its longest line. Poetry uses preformatted text, so we mark it with the pre element. But, pre must display with block characteristics, which means its width is determined, but not by line length. So it won't center as we want. We need a container that will be a block type and will shrink-wrap its content. Floats, absolute positioned items and tables are our options. AP elements and floats won't work for unknown widths, but that is a table characteristic. So, we wrap the pre text in a container with {display: table; margin: 0 auto;}. It's still not a table, it just has some characteristics of the table container.

Would you feel better about it were the values table and table-cell named block2 and block3? They could have been and it wouldn't have made a lick of difference. The terms we have for the property values are simply descriptive names for sets of characteristics. They do not affect the semantic value of the html markup.

cheers,

gary