Reasons HTML and CSS might make you say what the fuck. A curated list of commonly frustrating HTML and CSS quandaries, miscues, and dilemmas.
Created by @mdo.
<input>
buttonstype
on <button>
sAlways include a doctype. I recommend the simple HTML5 doctype:
<!doctype html>
Skipping the doctype can cause issues with malformed tables, inputs, and more as the page will be rendered in quirks mode.
Elements that have a set width
become wider when they have padding
and/or border-width
. To avoid these problems, make use of the now common box-sizing: border-box;
reset.
While Mobile Safari supports the use of rem
s in all property values, it seems to shit the bed when rem
s are used in dimensional media queries and infinitely flashes the page’s text in different sizes.
For now, use em
s in place of rem
s.
html {
font-size: 16px;
}
/* Causes flashing bug in Mobile Safari */
@media (min-width: 40rem) {
html {
font-size: 20px;
}
}
/* Works great in Mobile Safari */
@media (min-width: 40em) {
html {
font-size: 20px;
}
}
Help! If you have a link to an Apple or WebKit bug report for this, I’d love to include it. I’m unsure where to report this as it only applies to Mobile, and not Desktop, Safari.
Floated elements should always come first in the document order. Floated elements require something to wrap around, otherwise they can cause a step down effect, instead appearing below the content.
<div class="parent">
<div class="float">Float</div>
<div class="content">
<!-- ... -->
</div>
</div>
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.
<input>
buttonsFor 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:
<button>
elementsline-height
on your buttonsShould 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.
type
on <button>
sThe 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.