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.

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.

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:

• Fighting the Space Between Inline Block Elements
• Remove Whitespace Between Inline-Block Elements

...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.

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.

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.

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 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.

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.

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.

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.

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:

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

Yay! See http://www.mozilla.org/en-US/firefox/30.0/releasenotes/ The "Firefox and <input> buttons" entry should be updated accordingly.

.... 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.