WTF, HTML and CSS?
WTF, HTML and CSS? is a list of reasons HTML and CSS might make you say what the fuck. It's a curated list of commonly frustrating HTML and CSS quandaries, miscues, and dilemmas, created with the goal of making them less common.
Open an issue or a pull request to suggest changes or additions.
MIT licensed. Copyright 2014 @mdo.
Translations are maintained by their creators and may not always be up to date with the original here.
- French - Translated by mathieuhays
- Italian - Translated by uncasually
- Japan - Translated by makotot
- Korean - Translated by Snack
- Portuguese - Translated by webfatorial
- Spanish - Translated by uncasually
- Russian - Translated by ElForastero
- Chinese Simplified - Translated by lizheming
Have a translation you'd like to link to? Open a pull request to add it here. Be sure to keep it alphabetical.
The buttons line-height is fixed since Firefox 30
line-heightis actually fixed since Firefox 30, so I turned the "Good news" from future to past.
This is a small improvment, but perhaps you would completly remove this advice? I see that PrimerCSS & Github buttons use
line-heighton buttons ;)
Collapsing margins can cause unwanted behaviors, such as pushing a parent down when a top margin is applied to one of its children. Like in this example:
A common solution is to apply overflow: hidden (or overflow:auto) to the container element, in order to force the creation of a new Block Formatting Context, thus preventing margins from collapsing.
Spaces between inline-block elements affect layout
Proper formatting of code uses spaces, and if you use inline-block for layout you'll come across 'extra' spaces, which are actually one space between every two elements.
There are workaround and solutions for this, other than resolving to floats:
Updated margin collapsing title and subtext
...for clarity. I found myself reading it several times as I was misunderstanding. I knew which margins collapsed but what I was reading (or the way I was reading it) wasn't lining up with what I knew so this is to eliminate any ambiguity.
Update Carbon Ad Code
Replace legacy Fusion ad code with Carbon ad code. We still see some impressions every month, so it's worth replacing the ad code to keep the site error free.
transparent in Firefox css gradients
When you use the
transparentas one of the values in css gradient (linear or radial), it doesn't acts as one would expected. Only appears in Firefox.
linear-gradient(to right, #ccc, transparent 20%, transparent 80%, #ccc);creates gray full-width background instead of fading on sides. It works if you use
rgba(204, 204, 204, 0)instead of
transparent, but doesn't if you use
transparentitself, or even for example
rgba(0, 0, 0, 0).
This was quite a WTF moment for me, so I'm mentioning it here.
Please correct me if I'm wrong and this is desired behavior.
Useful Console Drop-in for Calculating a Page's Selector Count
Just thought you might like to add a link to this useful console drop-in I've found and used for calculating a page's CSS selector count... https://coderwall.com/p/owhdga
Gradients cannot be transitioned
Gradients won't transition to other gradients, some folks might not know and think their code is wrong when it isn't working.
A possible workaround is to make the background color of the element a solid color, and use
:beforeto add a transparent gradient above the element. Then you need only transition the background from one solid color to another.
Fix emphasis in already emphasized paragraph.
Markdown (or at least Github's parser) seems to struggle with nested emphasis markup.
**[…]**are not parsed correctly.
<em>[…]</em>is visually the same in this context.
<em style="font-style: normal;">[…]</em>is still italic, and ugly.
So I went with
reStructuredText's admonitions would nicely avoid this.
Firefox still needs a reset for button elements
In “Firefox and
<input>buttons”, the advice “Just use the
<button>element” is wrong.
Firefox does add a pseudo-element in the shadow dom (I think) of
buttonelements, and the fix that is mentioned for
<input>buttons should be applied to
<button>elements as well.
Last tested on http://fvsch.com/code/button-css/ with Firefox 30 (Aurora) on OS X. How to reproduce: go to that page using Firefox 30-, use the Style Editor in the devtools, go to the inline stylesheet and remove this code:
The black button should expand by a few pixels. In my test it was 239×27 pixels with the reset, and 245×29 pixels without the reset.
white-space vs nowrap vs pre-wrap vs pre-line
Is this only about things that require workarounds? One really annoying WTF for me is the inconsistent dashes between
white-space("whitespace" is a word, who the fuck uses a dash?!),
nowrap(they're 2 separate words! "nowrap" isn't a word! This is where there should be a dash!),
pre-line(unlike "no-", "pre-" is an actual prefix and not using a dash possibly makes sense).
The workaround is just using the specced keywords, of course.
CSS does not define default text and background colors
Firefox even has a setting (not in about:config but in the normal settings, a.k.a. about:preferences) for it under Content > Colors... (button). And the best thing? This very site ignores that fact and sets the text color but not background color, leading to the following with my current Firefox setup:
Replaced elements absolutely positionned
just below "Position and width", it could be good to mention "replaced elements absolutely positionned", which is quite… wtf.
Here is the text you could add:
Here is a pen that explains it : http://codepen.io/nico3333fr/pen/wBQJWe
Do you want a PR for this ?
See you, Nicolas
input buttons line-height fix shipped in Firefox 30.0
Yay! See http://www.mozilla.org/en-US/firefox/30.0/releasenotes/ The "Firefox and
<input>buttons" entry should be updated accordingly.
Adding overview of z-index, and the aspects of it that can catch you out...
.... When I saw your page, I thought it might benefit an entry on z-index, as that is definitely an area that can cause a lot of head-scratching. Here's my attempt at that.