Remove quotes around code spans 1 (#35992)

* Remove quotes around code spans 1

* Update files/en-us/learn/server-side/first_steps/client-server_overview/index.md

Co-authored-by: Brian Thomas Smith <[email protected]>

* Update files/en-us/web/xslt/element/text/index.md

Co-authored-by: Brian Thomas Smith <[email protected]>

---------

Co-authored-by: Brian Thomas Smith <[email protected]>

files/en-us/glossary/effective_connection_type/index.md

@@ -8,7 +8,7 @@ page-type: glossary-definition
 
 **Effective connection type** (ECT) refers to the measured network performance, returning a cellular connection type, like 3G, even if the actual connection is tethered broadband or Wi-Fi, based on the time between the browser requesting a page and effective type of the connection.
 
-The values of '`slow-2g`', '`2g`', '`3g`', and '`4g`' are determined using observed round-trip times and downlink values.
+The values of `slow-2g`, `2g`, `3g`, and `4g` are determined using observed round-trip times and downlink values.
 
 | ECT       | Minimum {{Glossary("Round Trip Time", "RTT")}} | Maximum downlink | Explanation                                                                                              |
 | --------- | ---------------------------------------------- | ---------------- | -------------------------------------------------------------------------------------------------------- |

files/en-us/glossary/literal/index.md

@@ -36,7 +36,7 @@ The following are examples of string literals:
 
 An object literal is a list of zero or more pairs of property names and associated values of an object, enclosed in curly braces (`{}`).
 
-The following is an example of an object literal. The first element of the `car` object defines a property, `myCar`, and assigns to it a new string, "`Toyota`"; the second element, the `getCar` property, is immediately assigned the result of invoking the function `carTypes('Honda')`; the third element, the `special` property, uses an existing variable (`sales`).
+The following is an example of an object literal. The first element of the `car` object defines a property, `myCar`, and assigns to it a new string, `"Toyota"`; the second element, the `getCar` property, is immediately assigned the result of invoking the function `carTypes('Honda')`; the third element, the `special` property, uses an existing variable (`sales`).
 
 ```js
 const sales = "BMW";

files/en-us/learn/common_questions/web_mechanics/what_is_a_url/index.md

@@ -123,7 +123,7 @@ Let's examine what the distinction between _absolute_ and _relative_ means in th
 
 The required parts of a URL depend to a great extent on the context in which the URL is used. In your browser's address bar, a URL doesn't have any context, so you must provide a full (or _absolute_) URL, like the ones we saw above. You don't need to include the protocol (the browser uses HTTP by default) or the port (which is only required when the targeted Web server is using some unusual port), but all the other parts of the URL are necessary.
 
-When a URL is used within a document, such as in an HTML page, things are a bit different. Because the browser already has the document's own URL, it can use this information to fill in the missing parts of any URL available inside that document. We can differentiate between an _absolute URL_ and a _relative URL_ by looking only at the _path_ part of the URL. If the path part of the URL starts with the "`/`" character, the browser will fetch that resource from the top root of the server, without reference to the context given by the current document.
+When a URL is used within a document, such as in an HTML page, things are a bit different. Because the browser already has the document's own URL, it can use this information to fill in the missing parts of any URL available inside that document. We can differentiate between an _absolute URL_ and a _relative URL_ by looking only at the _path_ part of the URL. If the path part of the URL starts with the `/` character, the browser will fetch that resource from the top root of the server, without reference to the context given by the current document.
 
 Let's look at some examples to make this clearer. Let's assume that the URLs are defined from within the document located at the following URL: `https://developer.mozilla.org/en-US/docs/Learn`.
 

files/en-us/learn/forms/your_first_form/index.md

@@ -294,10 +294,10 @@ Let's look at some of our form code again:
 </form>
 ```
 
-In our example, the form will send 3 pieces of data named "`user_name`", "`user_email`", and "`user_message`".
-That data will be sent to the URL "`/my-handling-form-page`" using the [HTTP `POST`](/en-US/docs/Web/HTTP/Methods/POST) method.
+In our example, the form will send 3 pieces of data named `user_name`, `user_email`, and `user_message`.
+That data will be sent to the URL `/my-handling-form-page` using the [HTTP `POST`](/en-US/docs/Web/HTTP/Methods/POST) method.
 
-On the server side, the script at the URL "`/my-handling-form-page`" will receive the data as a list of 3 key/value items contained in the HTTP request.
+On the server side, the script at the URL `/my-handling-form-page` will receive the data as a list of 3 key/value items contained in the HTTP request.
 The way this script will handle that data is up to you.
 Each server-side language (PHP, Python, Ruby, Java, C#, etc.) has its own mechanism of handling form data.
 It's beyond the scope of this guide to go deeply into that subject, but if you want to know more, we have provided some examples in our [Sending form data](/en-US/docs/Learn/Forms/Sending_and_retrieving_form_data) article later on.

files/en-us/learn/javascript/client-side_web_apis/third_party_apis/index.md

@@ -205,7 +205,7 @@ First, you'll need to make a connection between the API and your app. In the cas
 
    Replace the existing API key with the actual API key you got in the previous section.
 
-2. Add the following line to your JavaScript, below the "`// Event listeners to control the functionality`" comment. This runs a function called `submitSearch()` when the form is submitted (the button is pressed).
+2. Add the following line to your JavaScript, below the `// Event listeners to control the functionality` comment. This runs a function called `submitSearch()` when the form is submitted (the button is pressed).
 
    ```js
    searchForm.addEventListener("submit", submitSearch);

files/en-us/learn/javascript/first_steps/test_your_skills_colon__arrays/index.md

@@ -50,7 +50,7 @@ For this array task, we provide you with a starting array, and you will work in
 1. Remove the last item in the array.
 2. Add two new names to the end of the array.
 3. Go over each item in the array and add its index number after the name inside parentheses, for example `Ryu (0)`. Note that we don't teach how to do this in the Arrays article, so you'll have to do some research.
-4. Finally, join the array items together in a single string called `myString`, with a separator of "`-`".
+4. Finally, join the array items together in a single string called `myString`, with a separator of `"-"`.
 
 Try updating the live code below to recreate the finished example:
 

files/en-us/learn/server-side/django/authentication/index.md

@@ -453,7 +453,7 @@ Open the base template (**/django-locallibrary-tutorial/catalog/templates/base_g
 
 As you can see, we use `if` / `else` / `endif` template tags to conditionally display text based on whether `\{{ user.is_authenticated }}` is true. If the user is authenticated then we know that we have a valid user, so we call `\{{ user.get_username }}` to display their name.
 
-We create the login link URL using the `url` template tag and the name of the `login` URL configuration. Note also how we have appended `?next=\{{ request.path }}` to the end of the URL. What this does is add a URL parameter `next` containing the address (URL) of the _current_ page, to the end of the linked URL. After the user has successfully logged in, the view will use this "`next`" value to redirect the user back to the page where they first clicked the login link.
+We create the login link URL using the `url` template tag and the name of the `login` URL configuration. Note also how we have appended `?next=\{{ request.path }}` to the end of the URL. What this does is add a URL parameter `next` containing the address (URL) of the _current_ page, to the end of the linked URL. After the user has successfully logged in, the view will use this `next` value to redirect the user back to the page where they first clicked the login link.
 
 The logout template code is different, because from Django 5 to logout you must `POST` to the `admin:logout` URL, using a form with a button.
 By default this would render as a button, but you can style the button to display as a link.
@@ -497,7 +497,7 @@ class MyView(LoginRequiredMixin, View):
     # …
 ```
 
-This has exactly the same redirect behavior as the `login_required` decorator. You can also specify an alternative location to redirect the user to if they are not authenticated (`login_url`), and a URL parameter name instead of "`next`" to insert the current absolute path (`redirect_field_name`).
+This has exactly the same redirect behavior as the `login_required` decorator. You can also specify an alternative location to redirect the user to if they are not authenticated (`login_url`), and a URL parameter name instead of `next` to insert the current absolute path (`redirect_field_name`).
 
 ```python
 class MyView(LoginRequiredMixin, View):
@@ -707,7 +707,7 @@ Testing on permissions in views and templates is then very similar to testing on
 
 ### Models
 
-Defining permissions is done on the model "`class Meta`" section, using the `permissions` field.
+Defining permissions is done on the model `class Meta` section, using the `permissions` field.
 You can specify as many permissions as you need in a tuple, each permission itself being defined in a nested tuple containing the permission name and permission display value.
 For example, we might define a permission to allow a user to mark that a book has been returned as shown:
 

files/en-us/learn/server-side/django/forms/index.md

@@ -235,7 +235,7 @@ urlpatterns += [
 The URL configuration will redirect URLs with the format **/catalog/book/_\<bookinstance_id>_/renew/** to the function named `renew_book_librarian()` in **views.py**, and send the `BookInstance` id as the parameter named `pk`. The pattern only matches if `pk` is a correctly formatted `uuid`.
 
 > [!NOTE]
-> We can name our captured URL data "`pk`" anything we like, because we have complete control over the view function (we're not using a generic detail view class that expects parameters with a certain name). However, `pk` short for "primary key", is a reasonable convention to use!
+> We can name our captured URL data anything we like, because we have complete control over the view function (we're not using a generic detail view class that expects parameters with a certain name). However, `pk` short for "primary key", is a reasonable convention to use!
 
 ### View
 
@@ -351,9 +351,9 @@ If the form is valid, then we can start to use the data, accessing it through th
 > [!WARNING]
 > While you can also access the form data directly through the request (for example, `request.POST['renewal_date']` or `request.GET['renewal_date']` if using a GET request), this is NOT recommended. The cleaned data is sanitized, validated, and converted into Python-friendly types.
 
-The final step in the form-handling part of the view is to redirect to another page, usually a "success" page. In this case, we use `HttpResponseRedirect` and `reverse()` to redirect to the view named `'all-borrowed'` (this was created as the "challenge" in [Django Tutorial Part 8: User authentication and permissions](/en-US/docs/Learn/Server-side/Django/Authentication#challenge_yourself)). If you didn't create that page consider redirecting to the home page at URL '`/`').
+The final step in the form-handling part of the view is to redirect to another page, usually a "success" page. In this case, we use `HttpResponseRedirect` and `reverse()` to redirect to the view named `'all-borrowed'` (this was created as the "challenge" in [Django Tutorial Part 8: User authentication and permissions](/en-US/docs/Learn/Server-side/Django/Authentication#challenge_yourself)). If you didn't create that page consider redirecting to the home page at URL `/`).
 
-That's everything needed for the form handling itself, but we still need to restrict access to the view to just logged-in librarians who have permission to renew books. We use `@login_required` to require that the user is logged in, and the `@permission_required` function decorator with our existing `can_mark_returned` permission to allow access (decorators are processed in order). Note that we probably should have created a new permission setting in `BookInstance` ("`can_renew`"), but we will reuse the existing one to keep the example simple.
+That's everything needed for the form handling itself, but we still need to restrict access to the view to just logged-in librarians who have permission to renew books. We use `@login_required` to require that the user is logged in, and the `@permission_required` function decorator with our existing `can_mark_returned` permission to allow access (decorators are processed in order). Note that we probably should have created a new permission setting in `BookInstance` (`can_renew`), but we will reuse the existing one to keep the example simple.
 
 The final view is therefore as shown below. Please copy this into the bottom of **django-locallibrary-tutorial/catalog/views.py**.
 
@@ -427,7 +427,7 @@ Most of this will be completely familiar from previous tutorials.
 
 We extend the base template and then redefine the content block. We are able to reference `\{{ book_instance }}` (and its variables) because it was passed into the context object in the `render()` function, and we use these to list the book title, borrower, and the original due date.
 
-The form code is relatively simple. First, we declare the `form` tags, specifying where the form is to be submitted (`action`) and the `method` for submitting the data (in this case an "HTTP `POST`") — if you recall the [HTML Forms](#html_forms) overview at the top of the page, an empty `action` as shown, means that the form data will be posted back to the current URL of the page (which is what we want). Inside the tags, we define the `submit` input, which a user can press to submit the data. The `{% csrf_token %}` added just inside the form tags is part of Django's cross-site forgery protection.
+The form code is relatively simple. First, we declare the `form` tags, specifying where the form is to be submitted (`action`) and the `method` for submitting the data (in this case a `POST`) — if you recall the [HTML Forms](#html_forms) overview at the top of the page, an empty `action` as shown, means that the form data will be posted back to the current URL of the page (which is what we want). Inside the tags, we define the `submit` input, which a user can press to submit the data. The `{% csrf_token %}` added just inside the form tags is part of Django's cross-site forgery protection.
 
 > [!NOTE]
 > Add the `{% csrf_token %}` to every Django template you create that uses `POST` to submit data. This will reduce the chance of forms being hijacked by malicious users.
@@ -527,7 +527,7 @@ Note that this template code can only run inside the `{% for %}` loop, because t
 ```
 
 > [!NOTE]
-> Remember that your test login will need to have the permission "`catalog.can_mark_returned`" in order to see the new "Renew" link added above, and to access the linked page (perhaps use your superuser account).
+> Remember that your test login will need to have the permission `catalog.can_mark_returned` in order to see the new "Renew" link added above, and to access the linked page (perhaps use your superuser account).
 
 You can alternatively manually construct a test URL like this — `http://127.0.0.1:8000/catalog/book/<bookinstance_id>/renew/` (a valid `bookinstance_id` can be obtained by navigating to a book detail page in your library, and copying the `id` field).
 
@@ -584,7 +584,7 @@ class Meta:
 ```
 
 To add validation you can use the same approach as for a normal `Form` — you define a function named `clean_<field_name>()` and raise `ValidationError` exceptions for invalid values.
-The only difference with respect to our original form is that the model field is named `due_back` and not "`renewal_date`".
+The only difference with respect to our original form is that the model field is named `due_back` and not `renewal_date`.
 This change is necessary since the corresponding field in `BookInstance` is called `due_back`.
 
 ```python