If you float it, you probably need to clear it. Any content that follows an element with a float
will wrap around that element until cleared. To clear floats, use one of the following techniques.
Use the micro clearfix to clear your floats with a separate class.
.clearfix:before,
.clearfix:after {
display: table;
content: "";
}
.clearfix:after {
clear: both;
}
Alternatively, specify overflow
, with auto
or hidden
, on the parent.
.parent {
overflow: auto; /* clearfix */
}
.other-parent {
overflow: hidden; /* clearfix */
}
Be aware that overflow
can cause other unintended side effects, typically around positioned elements within the parent.
Pro-Tip! Keep your future self and your coworkers happy by including a comment like /* clearfix */
when clearing floats as the property can be used for other reasons.
A parent element that has only floated content will have a computed height: 0;
. Add a clearfix to the parent to force browsers to compute a height.
Elements with a float
will automatically become display: block;
. Do not set both as there is no need and the float
will override your display
.
.element {
float: left;
display: block; /* Not necessary */
}
Fun fact: Years ago, we had to set display: inline;
for most floats to work properly in IE6 to avoid the double margin bug. However, those days have long passed.
Top and bottom margins on adjacent elements (one after the other) can and will collapse in many situations, but never for floated or absolutely positioned elements. Read this MDN article or the CSS2 spec's collapsing margin section to find out more.
Horizontally adjacent margins will never collapse.
Table rows, <tr>
s, do not receive border
s unless you set border-collapse: collapse;
on the parent <table>
. Moreover, if the <tr>
and children <td>
s or <th>
s have the same border-width
, the rows will not see their border applied. See this JS Bin link for an example.
For reasons unknown, Firefox applies a line-height
to submit and button <input>
s that cannot be overridden with custom CSS. You have two options in dealing with this:
- Stick to
<button>
elements - Don't use
line-height
on your buttons
Should you go with the first route (and I recommend this one anyway because <button>
s are great), here's what you need to know:
<!-- Not so good -->
<input type="submit" value="Save changes">
<input type="button" value="Cancel">
<!-- Super good everywhere -->
<button type="submit">Save changes</button>
<button type="button">Cancel</button>
Should you wish to go the second route, just don't set a line-height
and use only padding
to vertically align button text. View this JS Bin example in Firefox to see the original problem and the workaround.
Good news! It looks like a fix for this might be coming in Firefox 30. That's good news for our future selves, but be aware this doesn't fix older versions.
Firefox adds an inner outline to buttons (<input>
s and <button>
s) on :focus
. Apparently it's for accessibility, but its placement seems rather odd. Use this CSS to override it:
input::-moz-focus-inner,
button::-moz-focus-inner {
padding: 0;
border: 0;
}
You can see this fix in action in the same JS Bin example mentioned in the previous section.
Pro-Tip! Be sure to include some focus state on buttons, links, and inputs. Providing an affordance for accessibility is paramount, both for pro users who tab through content and those with vision impairments.
The default value is submit
, meaning any button in a form can submit the form. Use type="button"
for anything that doesn't submit the form and type="submit"
for those that do.
<button type="submit">Save changes</button>
<button type="button">Cancel</button>
For actions that require a <button>
and are not in a form, use the type="button"
.
<button class="dismiss" type="button">x</button>
Fun fact: Apparently IE7 doesn't properly support the value
attribute on <button>
s. Instead of reading the attribute's content, it pulls from the innerHTML (the content between the opening and closing <button>
tags). However, I don't see this as a huge concern for two reasons: IE7 usage is way down, and it seems rather uncommon to set both a value
and the innerHTML on <button>
s.
Internet Explorer 9 and below have a max of 4,096 selectors per stylesheet. There is also a limit of 31 combined stylesheets and <style></style>
includes per page. Anything after this limit is ignored by the browser. Either split your CSS up, or start refactoring. I'd suggest the latter.
As a helpful side note, here's how browsers count selectors:
/* One selector */
.element { }
/* Two more selectors */
.element,
.other-element { }
/* Three more selectors */
input[type="text"],
.form-control,
.form-group > input { }
Elements with position: fixed;
are placed relative to the browser viewport. Elements with position: absolute;
are placed relative to their closest parent with a position other than static
(e.g., relative
, absolute
, or fixed
).
Don't set width: 100%;
on an element that has position: [absolute|fixed];
, left
, and right
. The use of width: 100%;
is the same as the combined use of left: 0;
and right: 0;
. Use one or the other, but not both.
Browsers break position: fixed;
when an element's parent has a transform
set. Using transforms creates a new containing block, effectively forcing the parent to have position: relative;
and the fixed element to behave as position: absolute;
.
See the demo and read Eric Meyer's post on the matter.