Merge pull request #709 from ember-learn/amy/fix-markdown-italic

Make markdown display as italic

source/2013-01-18-this-week-in-ember-js-4.markdown

@@ -68,7 +68,7 @@ emerged in the community, which we rolled into "Router v1."
 
 However, despite the fact that developers appreciated conventions around
 app structure, their reaction to the first version of the API could
-generously be described as _horrified_. Indeed, the router for large
+generously be described as <span style="font-style: italic;">horrified</span>. Indeed, the router for large
 applications began to look like the twisted amalgams of views in old
 SproutCore applications. We knew we had to head back to the drawing
 board with the lessons we had learned.

source/2013-08-29-ember-1-0-rc8.md

@@ -5,6 +5,7 @@ tags: Releases, Version 1.x, 2013
 responsive: true
 ---
 
+<!--alex disable just-->
 With Ember 1.0 RC8, we have reached the final RC before 1.0 final, which
 we hope to release this weekend if all goes well.
 
@@ -343,7 +344,7 @@ cat.get('isDead');
 
 After we have asked the cat object for its `isDead` property, we can
 categorically say which it is. But before we ask, the value of the
-computed property doesn't really _exist_.
+computed property doesn't really <span style="font-style: italic;">exist</span>.
 
 Now, let's introduce observers into the mix. If the value of a computed
 property doesn't exist yet, should observers fire if one of its

source/2013-08-31-ember-1-0-released.md

@@ -5,6 +5,7 @@ tags: Releases, 2013, Version 1.x, Router, Testing, Performance
 responsive: true
 ---
 
+<!--alex disable just easy nuts manhours special gals-men-->
 Today, we're excited to announce the final release of Ember.js 1.0.
 
 The first commit to the repository that would become Ember.js happened on April
@@ -29,7 +30,7 @@ it's clear that this strategy turned out to be the right one.
 
 As we began work on Ember.js, however, we soon realized that there was a
 fundamental problem. Just having templates that were bound to models was
-not enough. We also needed to help developers decide _which_ templates and
+not enough. We also needed to help developers decide <span style="font-style: italic;">which</span> templates and
 models to display at any given time.
 
 While struggling to figure out the best solution, we couldn't help but notice

source/2013-12-17-whats-coming-in-ember-in-2014.md

@@ -5,6 +5,7 @@ tags: Recent Posts, Roadmap, 2013
 responsive: true
 ---
 
+<!--alex disable just host-hostess-->
 Every few months, the Ember core team likes to get together to discuss
 issues face-to-face and set our priorities for the following quarter.
 
@@ -57,7 +58,7 @@ Two notable projects have come out of this work:
 It's important to note that we have been planning for module support for
 some time. In fact, one of the last features that was blocking our
 initial 1.0 release was to have the entire framework go through an object
-called the _resolver_.
+called the <span style="font-style: italic;">resolver</span>.
 
 The resolver is the part of our dependency injection system that is
 responsible for determining naming conventions. For example, imagine a
@@ -169,7 +170,7 @@ tossed around are:
 Here is a rough example of the kind of layout you might see when
 initializing a new Ember app via the CLI:
 
-```
+```text
 app/
   controllers/
   models/
@@ -193,7 +194,7 @@ modules/           // non-MVC stuff
 Right now, many Ember projects have adopted a Rails-style directory
 layout where everything is grouped by type:
 
-```
+```text
 app/
   controllers/
     post.js
@@ -211,7 +212,7 @@ app/
 We discussed moving this to a layout where related features are
 grouped together in "pods" of functionality:
 
-```
+```test
 app/
   config/
     application.js

source/2016-01-23-core-team-face-to-face-january-2016.md

@@ -5,6 +5,7 @@ tags: Core Team Meeting Minutes, Recent Posts, 2016
 responsive: true
 ---
 
+<!--alex disable easy just of-course obvious-->
 Ember is a truly community-driven framework, with contributors and core
 team members who live all over the world and work for many different
 companies. The vast majority of our collaboration happens online via
@@ -142,7 +143,7 @@ individually, then compose together into one large app.
 
 But what about medium-size apps? These apps may not have enough people
 working on them that they'd want to break it apart using engines, but
-they _are_ starting to accumulate many UI components. Reasoning about
+they <span style="font-style: italic;">are</span> starting to accumulate many UI components. Reasoning about
 which components are used where is getting difficult.
 
 The answer to this problem is something that we've called the pods
@@ -211,7 +212,7 @@ on 1.12 and 1.13, and what we can do to address them.
 
 Of course, some teams are happy to stick with a 1.x version that works
 for them; we won't be able to get everyone to upgrade to 2.x, at least
-right away. Rather, our goal is that anyone on 1.12 or 1.13 who _wants_
+right away. Rather, our goal is that anyone on 1.12 or 1.13 who <span style="font-style: italic;">wants</span>
 to be on 2.x should have a way to get there.
 
 One of the biggest issues we've heard reported is that, while the new
@@ -262,7 +263,7 @@ horizon.
 That said, we've heard from developers at more conservative
 organizations that the pace of new releases can feel overwhelming. Those
 developers are happy with the features they have, but are apprehensive
-about _not_ upgrading because they don't want to be left behind.
+about <span style="font-style: italic;">not</span> upgrading because they don't want to be left behind.
 
 To help those developers, [we announced in the Ember 2.0 release blog
 post][ember-2-0-post] that we would be introducing Long-Term Support

source/2016-02-25-announcing-embers-first-lts.md

@@ -5,6 +5,7 @@ tags: Recent Posts, 2016, Roadmap, Announcement
 responsive: true
 ---
 
+<!--alex disable of-course just-->
 Currently, Ember uses [release channels](http://emberjs.com/blog/2013/09/06/new-ember-release-process.html)
 to help users balance between a desire for new features (canary or beta
 channels) with stability (the release channel). While semver guarantees mean
@@ -135,7 +136,7 @@ or October with the release of Ember 2.8 LTS.
 ### See You Soon
 
 LTS releases are just one of the many things we've been working on; the core
-team has had a _long_ couple of months and we're excited to share everything.
+team has had a <span style="font-style: italic;">long</span> couple of months and we're excited to share everything.
 There will be more announcements and plans shared at [EmberConf](http://emberconf.com/)
 (March 29-30 in Portland), looking forward to seeing so many of you there!
 

source/2017-10-10-glimmer-progress-report.md

@@ -5,6 +5,7 @@ author: Tom Dale
 tags: Recent Posts, glimmer, 2017
 ---
 
+<!--alex disable easy just gal-guy of-course nuts white host-hostess-->
 At EmberConf in March of this year, [we announced Glimmer.js][ann-glimmer-js], a
 library for building modern UI components optimized for the mobile web. I wanted
 to give an update on what we've been working on since then.
@@ -36,8 +37,8 @@ One of the themes we discussed in our keynote was a new focus on _unlocking
 experimentation_, that is, allowing people to easily try out and share unproven
 ideas on top of the stable Ember core.
 
-Unlocking experimentation doesn't just allow for _more_ ideas; it also leads to
-_better_ ideas, because you can try things without worrying about breaking
+Unlocking experimentation doesn't just allow for <span style="font-style: italic;">more</span> ideas; it also leads to
+<span style="font-style: italic;">better</span> ideas, because you can try things without worrying about breaking
 changes. With Glimmer.js, we wanted to eat our own experimental dogfood.
 
 We've wanted to overhaul the component API in Ember for some time now. But
@@ -671,4 +672,4 @@ stuff into your hands. We are looking forward to seeing what the community can
 build with these powerful primitives. We'll post again once we've released the
 next version of Glimmer.js with these features integrated, so stay tuned to the
 blog. And if you've got any questions or want to help out, leave a comment below
-or come see us on GitHub!
+or come see us on GitHub!

source/2019-01-26-emberjs-native-class-update-2019-edition.md

@@ -152,9 +152,9 @@ peterParker.friends.push('Tony Stark');
 console.log(wandaMaximoff.friends); // ['Tony Stark']
 ```
 
-By contrast, when using `class ... extends`, only _methods_ and
-_getters/setters_ are assigned to the prototype. Class fields are assigned to the
-_instance_ of the class:
+By contrast, when using `class ... extends`, only <span style="font-style: italic;">methods</span> and
+<span style="font-style: italic;">getters/setters</span> are assigned to the prototype. Class fields are assigned to the
+<span style="font-style: italic;">instance</span> of the class:
 
 ```js
 class Person extends EmberObject {

source/2019-03-11-update-on-module-unification-and-octane.md

@@ -213,7 +213,7 @@ In the meantime, enough of Module Unification was shipping behind feature
 flags (and in Glimmer.js) that we were able to get feedback from early
 adopters. While overall people really liked the new file system and really
 appreciated not dealing with frustrating name collisions, something felt
-_off_.
+<span style="font-style: italic;">off</span>.
 
 One common theme in the feedback was that MU felt too rigid and frequently
 got in the way of simple tasks. To understand why, it's important to
@@ -225,7 +225,7 @@ don't leak into the rest of the app. If we have a component called
 `list-paginator` and it has a child component called `paginator-control`, MU
 allows us to organize them like this:
 
-```
+```text
 src
 ├── ui
 │   ├── components
@@ -241,7 +241,7 @@ In this example, the `list-paginator` template can invoke
 `{{paginator-control}}` to render its child component. However, if you try to
 invoke `{{paginator-control}}` from any template outside the `list-paginator`
 directory, you'll get an error. In other words, `paginator-control` is
-_local_ to `list-paginator`.
+<span style="font-style: italic;">local</span> to `list-paginator`.
 
 MU, then, is about scope, and controlling who has access to what. Where a
 module lives in the MU file system determines what it can see to and who

source/2020-03-27-the-ember-times-issue-141.md

@@ -153,7 +153,7 @@ To follow the detailed steps please read the [full blog post](https://mehulkar.c
 ## [Achieve consistent decorator positioning with a new eslint plugin ↕️](https://github.com/NullVoxPopuli/eslint-plugin-decorator-position)
 
 Ever had to **put up with** inconsistent decorator positions in pull requests, because there wasn't a lint rule for that?
-_Now_ there is! 🎉 [eslint-plugin-decorator-position](https://github.com/NullVoxPopuli/eslint-plugin-decorator-position)
+<span style="font-style: italic;">Now</span> there is! 🎉 [eslint-plugin-decorator-position](https://github.com/NullVoxPopuli/eslint-plugin-decorator-position)
 provides some configuration with some recommended defaults to help your project achieve that last bit of consistency.
 
 ---