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.

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

Hello!

Just a quick note about this:

Fun fact: Years ago, we had to set display: inline; for floats to work properly in IE6. However, those days have long passed.

Floats would work fine in IE6, the use of display: inline; was to avoid the famous Double Margin bug.

But yeah, those days have long passed. Thank **** for that.

Apple might fix the bug eventually. Stating the most-recently-checked-affected-version will aid in keeping the section accurate & up-to-date.

No doctype triggers quirks mode for IE?

Source: https://twitter.com/bundyo/status/448001482601025536

Mention blank spaces and how to deal with those.

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.

I think padding is being doubled from the body and the container. Should consolidate.

Context: twbs/bootstrap#12832, twbs/bootstrap#12256 (among others)

https://bugzilla.mozilla.org/show_bug.cgi?id=697451#c43

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.

Because my pet peeve is no block level elements within a paragraph. Why would I want that? I work in publishing, and we often have documents where the original text was something like:

<p> Some paragraph text

<blockquote> obvious block quoted material from another source</blockquote>

a continuation of the same parent paragraph.</p>

This causes problems when it comes to the HTML. Part of our office are old school SGML guys who preach the wonder that is XML. But the resulting HTML from this is invalid and the browsers through a fit as it will be translated as follows:

<p> Some paragraph text</p>

<blockquote> obvious block quoted material from another source</blockquote>

a continuation of the same parent paragraph.

maybe I'm just not finding the right XSLT for my situation, or maybe I am still won over on the argument that my HTML should be semantic. If it is all the same paragraph shouldn't it be contained within the same p? Secunia with this solution I now have to use something like data-id, because id's need to be unique, but we need to associate the three parts together. It's really a WTF situation.

Due to privacy concerns, browsers limit the way a:hover states can be styled, and computed styles report normal state, to avoid leaking browser history.

More information:

• MDN - Privacy and the :visited selector
• Impresive Webs - Limitations on Styling Visited Linkslinks/

I just spend 2 hours debugging a margin-collapse issue. I think it deserves to be added

In the Internet Explorer's selector limit section, add that IE 9 and below the limit combined number of style tags and stylesheet references to 31 (and ignore everything after that).

See http://philipwalton.com/articles/what-no-one-told-you-about-z-index/

In case you are still interested, here is the link for reporting bugs to Apple about Safari and other issues.

Apple Bug Reporter

Caveat: Must be registered in the Apple Developer Program to submit, it is open to all but it is an extra step 😒

While at it, tried to submit the bug, but couldn't reproduce this issue in Safari for iOS 7 and iOS 6.1. on an iPad or iPhone. ?

I've tested on every browser version I could get my hands on, and :focus isn't working on any of them. Has anyone else ran into this bug before?

There are multiple factors leading to the problems WebKit has with rem in media queries. Have a look at http://stackoverflow.com/questions/12201003/media-queries-with-rem-units-in-chrome, that discussion contains links to specs, test cases and bug reports.

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

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

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.

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

http://wisercoder.com/firefox-displaytable-cell-and-absolute-positioning/

https://bugzilla.mozilla.org/show_bug.cgi?id=63895

While it's a great idea and resource, one problem with this site is that it has some vulgar language on it. Not that I'm for this type of censorship in general, but I would like to link to this resource (e.g. to co-workers) but owing to the language, it would probably be inappropriate. Others (in Hacker News comments) have expressed this sentiment too, so I'm not unique in this regard. It seems like an unnecessary barrier to dissemination.

I stumbled into a situation where

text-decoration: none;

applied to ::after didn't have any effect if the parent had

text-decoration: underline;

But if we apply overline to just the pseudoelement, it works.

I am aware that nested children within a parent having an underline behaves the same way.

Here is the codepen
http://codepen.io/hoodwink73/pen/HzeKd

2 side by side elements at 50% width will not float next to each other unless there is no whitespace in the HTML http://codepen.io/tevko/pen/dsKjf/

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.

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:

Come cool tips about letter-spacing you should add :) Magic of CSS

Using the button element, as suggested in the "Firefox and buttons" section can cause problems in IE6-7 if you also want to use a value on a button.

In these versions of IE, any value you assign will be ignored, and the innerHTML of the button will be used instead. If you don't use values on buttons you may not be affected by this, but it is something that is worth being aware of.

Inline vs inline-block and their margin and padding.