Fix the text-flicker-on-hover Safari issue

and, in doing so, justify a directory of shameful CSS rules.

Author: pyrrho

dynamic/css/main.scss

@@ -45,3 +45,7 @@
   'pages/index',
   'pages/developing/getting-started',
   'pages/learning/use-cases';
+
+// 7. Styles so shameful they get their own directory
+@import
+  'shame/safari-text-flicker-fix';

dynamic/css/shame/README.md

@@ -0,0 +1,12 @@
+# Shame
+
+If you write a rule that should not be written, a work-around for non-compliant
+browser behavior, a fix the standard should be fixing itself, a hack that makes
+you ashamed of yourself as you're writing it... That rule belongs here.
+
+Hopefully the rules written here will be temporary (for some definition of
+"temporary"), and browsers and the CSS standard will eventually be robust enough
+that we don't need to be ashamed of ourselves. Until then, we should sequester
+the worst of our rules somewhere s.t. we know what should be fixed first.
+
+This is not part of the 7-1 architecture, and so has no reference.

dynamic/css/shame/_safari-text-flicker-fix.scss

@@ -0,0 +1,17 @@
+/**
+ * An issue was observed in Safari where hovering over sub-headings -- which
+ * would case a doc icon's opacity to transition from 0 to 1 -- was causing all
+ * of the text in the main article to flicker. More specifically, it was losing,
+ * and then regaining a certain amount of clarity.
+ *
+ * It turns this was caused by Safari changing the entire element from a 2D
+ * object to a 3D object for the duration of the transition.
+ *
+ * This rule sets the entire element to a 3D object _at load time_ to prevent
+ * the change from occurring. How stupid is that?
+ *
+ * Fix found on http://stackoverflow.com/questions/30637358
+ */
+.main-article {
+  -webkit-transform: translate3d(0, 0, 0);
+}