Changes front-end to frontend because no one cares (#318)

And if you disagree with me...

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing to the Front-End Playbook
+# Contributing to the Frontend Playbook
 
 If you're on this page because you'd like to contribute to the Playbook, that's fantastic! Thank you for getting involved ❤️
 
@@ -28,6 +28,6 @@ If you work at Springer Nature, please remember to keep discussion inside the is
 
 ### Publicising your changes
 
-A bot notifies the #frontend Slack room when work is merged, because changes to the playbook are relevant to all Front-End developers at Springer Nature.
+A bot notifies the #frontend Slack room when work is merged, because changes to the playbook are relevant to all Frontend developers at Springer Nature.
 
 We hope the wider development community will be interested in the work we have committed here. We welcome feedback and involvement from all - so feel free to link to your latest contribution on Twitter, or your social media platform of choice.

README.md

@@ -1,6 +1,6 @@
-# The Front-End Playbook
+# The Frontend Playbook
 
-This repo contains The Front-End Playbook. It details how we run software development and how we make web and mobile products together. It's filled with things we've learned based on our own experience and study of others' experiences.
+This repo contains The Frontend Playbook. It details how we run software development and how we make web and mobile products together. It's filled with things we've learned based on our own experience and study of others' experiences.
 
 This is a living document that we contribute to in a _public_ GitHub repo. Reasons for doing this in the open include (but are not limited to):
 
@@ -38,6 +38,6 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 ## License
 
-The Front-End Playbook is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
+The Frontend Playbook is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
 
 You should have received a copy of the license along with this work. If not, see [Creative Commons BY-NC-SA 4.0 license](http://creativecommons.org/licenses/by-nc-sa/4.0/).

performance/images.md

@@ -2,7 +2,7 @@
 
 This document describes best practices for the use of images on the web at Springer Nature.
 
-In a front-end workflow we typically deal with two kinds of image:
+In a frontend workflow we typically deal with two kinds of image:
 
 * **User interface images**, including icons, logos, and buttons. Usually managed by the frontend, these are stored with other client-side resources such as templates, CSS and JS. Like those resources, they may be shared between many different pages.
 

security/secure-markup.md

@@ -10,7 +10,7 @@
   * [Use the `type` & `typemustmatch` attribute for `object`s](#use-the-type--typemustmatch-attribute-for-objects)
 
 ## Scope of this document
-You should be aware of the security implications of your front-end code. This document outlines some steps you can take to reduce the risk of markup exposing us, or our users, to security flaws.
+You should be aware of the security implications of your frontend code. This document outlines some steps you can take to reduce the risk of markup exposing us, or our users, to security flaws.
 
 Note: this document does not cover JavaScript or interactions which may touch the server, e.g. XSS or HTTP headers. (It is assumed security-related headers are set in the HTTP headers, not in `meta` tag equivalents.)
 
@@ -51,7 +51,7 @@ Example markup (from the [MDN article on Subresource Integrity](https://develope
 
 Subresource Integrity can be used in conjunction with a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) but does not require a CSP to work.
 
-As Subresource Integrity should be relatively easy to add to a front-end build tool chain, you should use it for any `script` or `link` element, especially as [browser support for Subresource Integrity](https://caniuse.com/#feat=subresource-integrity) is good.
+As Subresource Integrity should be relatively easy to add to a frontend build tool chain, you should use it for any `script` or `link` element, especially as [browser support for Subresource Integrity](https://caniuse.com/#feat=subresource-integrity) is good.
 
 - [Gentle introduction to Subresource Integrity by keycdn.com](https://www.keycdn.com/support/subresource-integrity/)
 - [MDN article on Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity)

writing/house-style.md

@@ -1,9 +1,9 @@
 # Language style guide
 
 * [Writing style](#writing-style)
-    * [Tone of voice](#tone-of-voice)
-    * [Plain English](#plain-english)
-    * [Technical writing](#technical-writing)
+  * [Tone of voice](#tone-of-voice)
+  * [Plain English](#plain-english)
+  * [Technical writing](#technical-writing)
 * [Frontend or front-end](#frontend-or-front-end)
 
 
@@ -53,9 +53,7 @@ All of the advice in the [plain English](#plain-english) section applies. Additi
 
 ## Frontend or front-end
 
-* Use `front-end` when you need an adjective (e.g. "the front-end team", "front-end principles").
-* Use `frontend` when you need a noun (e.g. "the application's frontend"), when you refer to a repository, or in your code.
-
+Always use `frontend` regardless of the context. It's less confusing and error prone, and ensures consistency across all our documentation and portfolio of products.
 
 [writing-well]: http://writersdiet.com/?page_id=16
 [active-passive]: https://oxfordediting.com/the-active-verb-form-makes-academic-writing-more-readable/

writing/social-media.md

@@ -27,4 +27,4 @@ We do:
 We _don't_ do:
 > Released Shunter 1.2.3. Fixes a vulnerability which was caused by a bug in `nac`, breaking our project. https://github.com/springernature/shunter/blob/master/HISTORY.md#123-2017-03-08
 
-* Always provide links where people can find further information if interested. E.g. a changelog for a software release, a blog article, a link to the front-end playbook, etc.
+* Always provide links where people can find further information if interested. E.g. a changelog for a software release, a blog article, a link to the frontend playbook, etc.