Common reasons your HTML and CSS may be fucked.

  • By Mark Otto
  • Last update: Dec 18, 2022
  • Comments: 15

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.

Start reading ☞


Contribute

Open an issue or a pull request to suggest changes or additions.

License

MIT licensed. Copyright 2014 @mdo.

Translations

Translations are maintained by their creators and may not always be up to date with the original here.

Have a translation you'd like to link to? Open a pull request to add it here. Be sure to keep it alphabetical.

<3

Github

https://github.com/mdo/wtf-html-css

Comments(15)

  • 1

    The buttons line-height is fixed since Firefox 30

    Hi @mdo!

    The buttons line-height is 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-height on buttons ;)

    Cheers, Thomas.

  • 2

    Collapsing margins

    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:

    http://stackoverflow.com/questions/1394724/css-margin-top-when-parents-got-no-border

    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.

  • 3

    Spaces between inline-block elements affect layout

  • 4

    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.

  • 5

    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.

  • 6

    transparent in Firefox css gradients

    When you use the transparent as one of the values in css gradient (linear or radial), it doesn't acts as one would expected. Only appears in Firefox.

    E. g. 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 transparent itself, 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.

  • 7

    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

  • 8

    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 :before to add a transparent gradient above the element. Then you need only transition the background from one solid color to another.

  • 9

    Fix emphasis in already emphasized paragraph.

    Markdown (or at least Github's parser) seems to struggle with nested emphasis markup.

    • Both *[…]* and **[…]** 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 <strong>[…]</strong>.

    reStructuredText's admonitions would nicely avoid this.

  • 10

    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 button elements, 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:

    button::-moz-focus-inner {
      padding: 0;
      border: none;
    }
    

    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.

  • 11

    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-wrap, and 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.

  • 12

    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:

    bildschirmfoto am 2017-03-07 um 17 03 30

  • 13

    Replaced elements absolutely positionned

    Hi,

    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:

    Don't use width… except if you are in the case of a replaced element that is absolutely positionned. I this case, there are some weird and difficult to understand rules that apply. Specially in this case, the browser will ignore the right value. It is not a bug, it is a feature of the spec.

    Here is a pen that explains it : http://codepen.io/nico3333fr/pen/wBQJWe

    Do you want a PR for this ?

    See you, Nicolas

  • 14

    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.

  • 15

    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.