From 9df96dcad40bf97f66b317ef6b6bbe64444569eb Mon Sep 17 00:00:00 2001 From: Joshua Chen Date: Mon, 23 Sep 2024 09:57:03 -0400 Subject: [PATCH] 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 * Update files/en-us/web/xslt/element/text/index.md Co-authored-by: Brian Thomas Smith --------- Co-authored-by: Brian Thomas Smith --- .../effective_connection_type/index.md | 2 +- files/en-us/glossary/literal/index.md | 2 +- .../web_mechanics/what_is_a_url/index.md | 2 +- .../learn/forms/your_first_form/index.md | 6 +++--- .../third_party_apis/index.md | 2 +- .../test_your_skills_colon__arrays/index.md | 2 +- .../django/authentication/index.md | 6 +++--- .../learn/server-side/django/forms/index.md | 12 +++++------ .../server-side/django/generic_views/index.md | 10 +++++----- .../server-side/django/home_page/index.md | 4 ++-- .../server-side/django/introduction/index.md | 4 ++-- .../server-side/django/sessions/index.md | 4 ++-- .../displaying_data/home_page/index.md | 2 +- .../express_nodejs/introduction/index.md | 2 +- .../express_nodejs/skeleton_website/index.md | 10 +++++----- .../client-server_overview/index.md | 8 ++++---- .../page_structures/syntax_sections/index.md | 2 +- .../web/mathml/element/semantics/index.md | 2 +- files/en-us/web/opensearch/index.md | 2 +- .../javascript_functionality/index.md | 4 ++-- .../web/security/same-origin_policy/index.md | 4 ++-- .../index.md | 6 +++--- .../web/xslt/element/decimal-format/index.md | 20 +++++++++---------- files/en-us/web/xslt/element/index.md | 2 +- files/en-us/web/xslt/element/message/index.md | 2 +- files/en-us/web/xslt/element/number/index.md | 4 ++-- files/en-us/web/xslt/element/output/index.md | 4 ++-- files/en-us/web/xslt/element/sort/index.md | 6 +++--- files/en-us/web/xslt/element/text/index.md | 8 ++++++-- .../en-us/web/xslt/element/value-of/index.md | 2 +- 30 files changed, 75 insertions(+), 71 deletions(-) diff --git a/files/en-us/glossary/effective_connection_type/index.md b/files/en-us/glossary/effective_connection_type/index.md index 7a2011090111b84..8750bf1f4240527 100644 --- a/files/en-us/glossary/effective_connection_type/index.md +++ b/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 | | --------- | ---------------------------------------------- | ---------------- | -------------------------------------------------------------------------------------------------------- | diff --git a/files/en-us/glossary/literal/index.md b/files/en-us/glossary/literal/index.md index 6036bd56bd64b67..6e53b526ff8777c 100644 --- a/files/en-us/glossary/literal/index.md +++ b/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"; diff --git a/files/en-us/learn/common_questions/web_mechanics/what_is_a_url/index.md b/files/en-us/learn/common_questions/web_mechanics/what_is_a_url/index.md index 7808d9674e49ab9..a48a12e176f75ae 100644 --- a/files/en-us/learn/common_questions/web_mechanics/what_is_a_url/index.md +++ b/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`. diff --git a/files/en-us/learn/forms/your_first_form/index.md b/files/en-us/learn/forms/your_first_form/index.md index 3fcbdb523c9ff65..5a0fd3ac26c7692 100644 --- a/files/en-us/learn/forms/your_first_form/index.md +++ b/files/en-us/learn/forms/your_first_form/index.md @@ -294,10 +294,10 @@ Let's look at some of our form code again: ``` -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. diff --git a/files/en-us/learn/javascript/client-side_web_apis/third_party_apis/index.md b/files/en-us/learn/javascript/client-side_web_apis/third_party_apis/index.md index 2cada03e94b7df1..b51dee2680a8717 100644 --- a/files/en-us/learn/javascript/client-side_web_apis/third_party_apis/index.md +++ b/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); diff --git a/files/en-us/learn/javascript/first_steps/test_your_skills_colon__arrays/index.md b/files/en-us/learn/javascript/first_steps/test_your_skills_colon__arrays/index.md index c57c7a3d39e132c..c5d18f7ae21c93f 100644 --- a/files/en-us/learn/javascript/first_steps/test_your_skills_colon__arrays/index.md +++ b/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: diff --git a/files/en-us/learn/server-side/django/authentication/index.md b/files/en-us/learn/server-side/django/authentication/index.md index 17e03eb1d6f4385..6bd650be9f36ddf 100644 --- a/files/en-us/learn/server-side/django/authentication/index.md +++ b/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: diff --git a/files/en-us/learn/server-side/django/forms/index.md b/files/en-us/learn/server-side/django/forms/index.md index 274f666ff780605..494663b0d904187 100644 --- a/files/en-us/learn/server-side/django/forms/index.md +++ b/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/_\_/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//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_()` 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 diff --git a/files/en-us/learn/server-side/django/generic_views/index.md b/files/en-us/learn/server-side/django/generic_views/index.md index da14dbe2480213e..27bc98fc233d221 100644 --- a/files/en-us/learn/server-side/django/generic_views/index.md +++ b/files/en-us/learn/server-side/django/generic_views/index.md @@ -68,7 +68,7 @@ class BookListView(generic.ListView): model = Book ``` -That's it! The generic view will query the database to get all records for the specified model (`Book`) then render a template located at **/django-locallibrary-tutorial/catalog/templates/catalog/book_list.html** (which we will create below). Within the template you can access the list of books with the template variable named `object_list` OR `book_list` (i.e. generically "`_list`"). +That's it! The generic view will query the database to get all records for the specified model (`Book`) then render a template located at **/django-locallibrary-tutorial/catalog/templates/catalog/book_list.html** (which we will create below). Within the template you can access the list of books with the template variable named `object_list` OR `book_list` (i.e. generically `_list`). > [!NOTE] > This awkward path for the template location isn't a misprint — the generic views look for templates in `/application_name/the_model_name_list.html` (`catalog/book_list.html` in this case) inside the application's `/application_name/templates/` directory (`/catalog/templates/)`. @@ -97,7 +97,7 @@ class BookListView(generic.ListView): return Book.objects.filter(title__icontains='war')[:5] # Get 5 books containing the title war ``` -We might also override `get_context_data()` in order to pass additional context variables to the template (e.g. the list of books is passed by default). The fragment below shows how to add a variable named "`some_data`" to the context (it would then be available as a template variable). +We might also override `get_context_data()` in order to pass additional context variables to the template (e.g. the list of books is passed by default). The fragment below shows how to add a variable named `some_data` to the context (it would then be available as a template variable). ```python class BookListView(generic.ListView): @@ -428,7 +428,7 @@ class BookDetailView(generic.DetailView): model = Book ``` -That's it! All you need to do now is create a template called **/django-locallibrary-tutorial/catalog/templates/catalog/book_detail.html**, and the view will pass it the database information for the specific `Book` record extracted by the URL mapper. Within the template you can access the book's details with the template variable named `object` OR `book` (i.e. generically "`the_model_name`"). +That's it! All you need to do now is create a template called **/django-locallibrary-tutorial/catalog/templates/catalog/book_detail.html**, and the view will pass it the database information for the specific `Book` record extracted by the URL mapper. Within the template you can access the book's details with the template variable named `object` OR `book` (i.e. generically `the_model_name`). If you need to, you can change the template used and the name of the context object used to reference the book in the template. You can also override methods to, for example, add additional information to the context. @@ -520,7 +520,7 @@ Though a little larger, almost everything in this template has been described pr - We extend our base template and override the "content" block. - We use conditional processing to determine whether or not to display specific content. - We use `for` loops to loop through lists of objects. -- We access the context fields using the dot notation (because we've used the detail generic view, the context is named `book`; we could also use "`object`") +- We access the context fields using the dot notation (because we've used the detail generic view, the context is named `book`; we could also use `object`) The first interesting thing we haven't seen before is the function `book.bookinstance_set.all()`. This method is "automagically" constructed by Django in order to return the set of `BookInstance` records associated with a particular `Book`. @@ -583,7 +583,7 @@ Astute readers will note that the method `BookInstance.get_status_display()` tha ``` This function is automatically created because `BookInstance.status` is a [choices field](https://docs.djangoproject.com/en/5.0/ref/models/fields/#choices). -Django automatically creates a method `get_FOO_display()` for every choices field "`Foo`" in a model, which can be used to get the current value of the field. +Django automatically creates a method `get_foo_display()` for every choices field `foo` in a model, which can be used to get the current value of the field. ## What does it look like? diff --git a/files/en-us/learn/server-side/django/home_page/index.md b/files/en-us/learn/server-side/django/home_page/index.md index 4976c2b39f4c2c2..ef037b0f229945e 100644 --- a/files/en-us/learn/server-side/django/home_page/index.md +++ b/files/en-us/learn/server-side/django/home_page/index.md @@ -166,7 +166,7 @@ A template is a text file that defines the structure or layout of a file (such a A Django application created using **startapp** (like the skeleton of this example) will look for templates in a subdirectory named '**templates**' of your applications. For example, in the index view that we just added, the `render()` function will expect to find the file **_index.html_** in **/django-locallibrary-tutorial/catalog/templates/** and will raise an error if the file is not present. -You can check this by saving the previous changes and accessing `127.0.0.1:8000` in your browser - it will display a fairly intuitive error message: "`TemplateDoesNotExist at /catalog/`", and other details. +You can check this by saving the previous changes and accessing `127.0.0.1:8000` in your browser - it will display a fairly intuitive error message: "TemplateDoesNotExist at /catalog/", and other details. > [!NOTE] > Based on your project's settings file, Django will look for templates in a number of places, searching in your installed applications by default. You can find out more about how Django finds templates and what template formats it supports in [the Templates section of the Django documentation](https://docs.djangoproject.com/en/5.0/topics/templates/). @@ -324,7 +324,7 @@ return render(request, 'index.html', context=context) #### Referencing static files in templates -Your project is likely to use static resources, including JavaScript, CSS, and images. Because the location of these files might not be known (or might change), Django allows you to specify the location in your templates relative to the `STATIC_URL` global setting. The default skeleton website sets the value of `STATIC_URL` to '`/static/`', but you might choose to host these on a content delivery network or elsewhere. +Your project is likely to use static resources, including JavaScript, CSS, and images. Because the location of these files might not be known (or might change), Django allows you to specify the location in your templates relative to the `STATIC_URL` global setting. The default skeleton website sets the value of `STATIC_URL` to `"/static/"`, but you might choose to host these on a content delivery network or elsewhere. Within the template you first call the `load` template tag specifying "static" to add the template library, as shown in the code sample below. You can then use the `static` template tag and specify the relative URL to the required file. diff --git a/files/en-us/learn/server-side/django/introduction/index.md b/files/en-us/learn/server-side/django/introduction/index.md index 76c225d50fe22ed..26c050627ce5212 100644 --- a/files/en-us/learn/server-side/django/introduction/index.md +++ b/files/en-us/learn/server-side/django/introduction/index.md @@ -185,7 +185,7 @@ class Team(models.Model): The Django model provides a simple query API for searching the associated database. This can match against a number of fields at a time using different criteria (e.g. exact, case-insensitive, greater than, etc.), and can support complex statements (for example, you can specify a search on U11 teams that have a team name that starts with "Fr" or ends with "al"). -The code snippet shows a view function (resource handler) for displaying all of our U09 teams. The `list_teams = Team.objects.filter(team_level__exact="U09")` line shows how we can use the model query API to filter for all records where the `team_level` field has exactly the text '`U09`' (note how this criteria is passed to the `filter()` function as an argument, with the field name and match type separated by a double underscore: **`team_level__exact`**). +The code snippet shows a view function (resource handler) for displaying all of our U09 teams. The `list_teams = Team.objects.filter(team_level__exact="U09")` line shows how we can use the model query API to filter for all records where the `team_level` field has exactly the text `U09` (note how this criteria is passed to the `filter()` function as an argument, with the field name and match type separated by a double underscore: **`team_level__exact`**). ```python ## filename: views.py @@ -199,7 +199,7 @@ def index(request): return render(request, '/best/index.html', context) ``` -This function uses the `render()` function to create the `HttpResponse` that is sent back to the browser. This function is a _shortcut_; it creates an HTML file by combining a specified HTML template and some data to insert in the template (provided in the variable named "`context`"). In the next section we show how the template has the data inserted in it to create the HTML. +This function uses the `render()` function to create the `HttpResponse` that is sent back to the browser. This function is a _shortcut_; it creates an HTML file by combining a specified HTML template and some data to insert in the template (provided in the variable named `context`). In the next section we show how the template has the data inserted in it to create the HTML. ### Rendering data (HTML templates) diff --git a/files/en-us/learn/server-side/django/sessions/index.md b/files/en-us/learn/server-side/django/sessions/index.md index beefaac5d59366f..666f88e28d4ac2f 100644 --- a/files/en-us/learn/server-side/django/sessions/index.md +++ b/files/en-us/learn/server-side/django/sessions/index.md @@ -66,7 +66,7 @@ This session attribute represents the specific connection to the current user (o The `session` attribute is a dictionary-like object that you can read and write as many times as you like in your view, modifying it as wished. You can do all the normal dictionary operations, including clearing all data, testing if a key is present, looping through data, etc. Most of the time though, you'll just use the standard "dictionary" API to get and set values. -The code fragments below show how you can get, set, and delete some data with the key "`my_car`", associated with the current session (browser). +The code fragments below show how you can get, set, and delete some data with the key `my_car`, associated with the current session (browser). > [!NOTE] > One of the great things about Django is that you don't need to think about the mechanisms that tie the session to your current request in your view. If we were to use the fragments below in our view, we'd know that the information about `my_car` is associated only with the browser that sent the current request. @@ -96,7 +96,7 @@ By default, Django only saves to the session database and sends the session cook request.session['my_car'] = 'mini' ``` -If you're updating some information _within_ session data, then Django will not recognize that you've made a change to the session and save the data (for example, if you were to change "`wheels`" data inside your "`my_car`" data, as shown below). In this case you will need to explicitly mark the session as having been modified. +If you're updating some information _within_ session data, then Django will not recognize that you've made a change to the session and save the data (for example, if you were to change `wheels` data inside your `my_car` data, as shown below). In this case you will need to explicitly mark the session as having been modified. ```python # Session object not directly modified, only data within the session. Session changes not saved! diff --git a/files/en-us/learn/server-side/express_nodejs/displaying_data/home_page/index.md b/files/en-us/learn/server-side/express_nodejs/displaying_data/home_page/index.md index bca178973cecaa3..f747ed60c562433 100644 --- a/files/en-us/learn/server-side/express_nodejs/displaying_data/home_page/index.md +++ b/files/en-us/learn/server-side/express_nodejs/displaying_data/home_page/index.md @@ -130,7 +130,7 @@ block content li #[strong Genres:] !{genre_count} ``` -The view is straightforward. We extend the **layout.pug** base template, overriding the `block` named '**content**'. The first `h1` heading will be the escaped text for the `title` variable that was passed into the `render()` function—note the use of the '`h1=`' so that the following text is treated as a JavaScript expression. We then include a paragraph introducing the LocalLibrary. +The view is straightforward. We extend the **layout.pug** base template, overriding the `block` named '**content**'. The first `h1` heading will be the escaped text for the `title` variable that was passed into the `render()` function—note the use of the `h1=` so that the following text is treated as a JavaScript expression. We then include a paragraph introducing the LocalLibrary. Under the _Dynamic content_ heading we list the number of copies of each model. Note that the template values for the data are the keys that were specified when `render()` was called in the route handler function. diff --git a/files/en-us/learn/server-side/express_nodejs/introduction/index.md b/files/en-us/learn/server-side/express_nodejs/introduction/index.md index eff98e61c1fbfc5..c64cce05f780a99 100644 --- a/files/en-us/learn/server-side/express_nodejs/introduction/index.md +++ b/files/en-us/learn/server-side/express_nodejs/introduction/index.md @@ -431,7 +431,7 @@ These can return any content required, but must be called after all other `app.u Express comes with a built-in error handler, which takes care of any remaining errors that might be encountered in the app. This default error-handling middleware function is added at the end of the middleware function stack. If you pass an error to `next()` and you do not handle it in an error handler, it will be handled by the built-in error handler; the error will be written to the client with the stack trace. > [!NOTE] -> The stack trace is not included in the production environment. To run it in production mode you need to set the environment variable `NODE_ENV` to '`production'`. +> The stack trace is not included in the production environment. To run it in production mode you need to set the environment variable `NODE_ENV` to `"production"`. > [!NOTE] > HTTP404 and other "error" status codes are not treated as errors. If you want to handle these, you can add a middleware function to do so. For more information see the [FAQ](https://expressjs.com/en/starter/faq.html#how-do-i-handle-404-responses). diff --git a/files/en-us/learn/server-side/express_nodejs/skeleton_website/index.md b/files/en-us/learn/server-side/express_nodejs/skeleton_website/index.md index 14df7ac3f2731b9..53c9d67918ef94e 100644 --- a/files/en-us/learn/server-side/express_nodejs/skeleton_website/index.md +++ b/files/en-us/learn/server-side/express_nodejs/skeleton_website/index.md @@ -284,7 +284,7 @@ We can now start the server in almost exactly the same way as previously, but us > [!NOTE] > Now if you edit any file in the project the server will restart (or you can restart it by typing `rs` on the command prompt at any time). You will still need to reload the browser to refresh the page. > -> We now have to call "`npm run `" rather than just `npm start`, because "start" is actually an npm command that is mapped to the named script. We could have replaced the command in the _start_ script but we only want to use _nodemon_ during development, so it makes sense to create a new script command. +> We now have to call `npm run ` rather than just `npm start`, because "start" is actually an npm command that is mapped to the named script. We could have replaced the command in the _start_ script but we only want to use _nodemon_ during development, so it makes sense to create a new script command. > > The `serverstart` command added to the scripts in the **package.json** above is a very good example. Using this approach means you no longer have to type a long command to start the server. Note that the particular command added to the script works for macOS or Linux only. @@ -462,7 +462,7 @@ const usersRouter = require("./routes/users"); > [!NOTE] > At this point, we have just _imported_ the module; we haven't actually used its routes yet (this happens just a little bit further down the file). -Next, we create the `app` object using our imported _express_ module, and then use it to set up the view (template) engine. There are two parts to setting up the engine. First, we set the '`views`' value to specify the folder where the templates will be stored (in this case the subfolder **/views**). Then we set the '`view engine`' value to specify the template library (in this case "pug"). +Next, we create the `app` object using our imported _express_ module, and then use it to set up the view (template) engine. There are two parts to setting up the engine. First, we set the `"views"` value to specify the folder where the templates will be stored (in this case the subfolder **/views**). Then we set the `"view engine"` value to specify the template library (in this case "pug"). ```js const app = express(); @@ -493,7 +493,7 @@ app.use("/users", usersRouter); ``` > [!NOTE] -> The paths specified above (`'/'` and '`/users'`) are treated as a prefix to routes defined in the imported files. +> The paths specified above (`"/"` and `"/users"`) are treated as a prefix to routes defined in the imported files. > So for example, if the imported **users** module defines a route for `/profile`, you would access that route at `/users/profile`. We'll talk more about routes in a later article. The last middleware in the file adds handler methods for errors and HTTP 404 responses. @@ -540,12 +540,12 @@ router.get("/", (req, res, next) => { module.exports = router; ``` -The route defines a callback that will be invoked whenever an HTTP `GET` request with the correct pattern is detected. The matching pattern is the route specified when the module is imported ('`/users`') plus whatever is defined in this file ('`/`'). In other words, this route will be used when a URL of `/users/` is received. +The route defines a callback that will be invoked whenever an HTTP `GET` request with the correct pattern is detected. The matching pattern is the route specified when the module is imported (`"/users"`) plus whatever is defined in this file (`"/"`). In other words, this route will be used when a URL of `/users/` is received. > [!NOTE] > Try this out by running the server with node and visiting the URL in your browser: `http://localhost:3000/users/`. You should see a message: 'respond with a resource'. -One thing of interest above is that the callback function has the third argument '`next`', and is hence a middleware function rather than a simple route callback. While the code doesn't currently use the `next` argument, it may be useful in the future if you want to add multiple route handlers to the `'/'` route path. +One thing of interest above is that the callback function has the third argument `next`, and is hence a middleware function rather than a simple route callback. While the code doesn't currently use the `next` argument, it may be useful in the future if you want to add multiple route handlers to the `'/'` route path. ### Views (templates) diff --git a/files/en-us/learn/server-side/first_steps/client-server_overview/index.md b/files/en-us/learn/server-side/first_steps/client-server_overview/index.md index 0e92783c4e6e174..36957d5e44084d3 100644 --- a/files/en-us/learn/server-side/first_steps/client-server_overview/index.md +++ b/files/en-us/learn/server-side/first_steps/client-server_overview/index.md @@ -50,7 +50,7 @@ This request includes: - `POST` data. `POST` requests add new resources, the data for which is encoded within the request body. - Client-side cookies. Cookies contain session data about the client, including keys that the server can use to determine their login status and permissions/accesses to resources. -Web servers wait for client request messages, process them when they arrive, and reply to the web browser with an HTTP Response message. The response contains an [HTTP Response status code](/en-US/docs/Web/HTTP/Status) indicating whether or not the request succeeded (e.g. "`200 OK`" for success, "`404 Not Found`" if the resource cannot be found, "`403 Forbidden`" if the user isn't authorized to see the resource, etc.). The body of a successful response to a `GET` request would contain the requested resource. +Web servers wait for client request messages, process them when they arrive, and reply to the web browser with an HTTP response message. The response contains an [HTTP Response status code](/en-US/docs/Web/HTTP/Status) indicating whether or not the request succeeded (e.g., {{HTTPStatus("200", "200 OK")}} for success, {{HTTPStatus("404", "404 Not Found")}} if the resource cannot be found, {{HTTPStatus("403", "403 Forbidden")}} if the user isn't authorized to see the resource, etc.). The body of the response to a successful `GET` request contains the requested resource. When an HTML page is returned it is rendered by the web browser. As part of processing, the browser may discover links to other resources (e.g. an HTML page usually references JavaScript and CSS files), and will send separate HTTP Requests to download these files. @@ -171,7 +171,7 @@ The main difference is that the URL doesn't have any parameters. As you can see, #### The response -The response from the request is shown below. The status code of "`302 Found`" tells the browser that the post succeeded, and that it must issue a second HTTP request to load the page specified in the `Location` field. The information is otherwise similar to that for the response to a `GET` request. +The response from the request is shown below. The status code of `302 Found` tells the browser that the post succeeded, and that it must issue a second HTTP request to load the page specified in the `Location` field. The information is otherwise similar to that for the response to a `GET` request. ```http HTTP/1.1 302 FOUND @@ -203,7 +203,7 @@ Let's recap on how this works, by looking again at the static site architecture ![A simplified diagram of a static web server.](basic_static_app_server.png) -When a user wants to navigate to a page, the browser sends an HTTP `GET` request specifying the URL of its HTML page. The server retrieves the requested document from its file system and returns an HTTP response containing the document and an [HTTP Response status code](/en-US/docs/Web/HTTP/Status) of "`200 OK`" (indicating success). The server might return a different status code, for example "`404 Not Found`" if the file is not present on the server, or "`301 Moved Permanently`" if the file exists but has been redirected to a different location. +When a user wants to navigate to a page, the browser sends an HTTP `GET` request specifying the URL of its HTML page. The server retrieves the requested document from its file system and returns an HTTP response containing the document and an [HTTP Response status code](/en-US/docs/Web/HTTP/Status) of `200 OK` (indicating success). The server might return a different status code, for example `404 Not Found` if the file is not present on the server, or `301 Moved Permanently` if the file exists but has been redirected to a different location. The server for a static site will only ever need to process GET requests, because the server doesn't store any modifiable data. It also doesn't change its responses based on HTTP Request data (e.g. URL parameters or cookies). @@ -255,7 +255,7 @@ Server-side web frameworks make writing code to handle the operations described One of the most important operations they perform is providing simple mechanisms to map URLs for different resources/pages to specific handler functions. This makes it easier to keep the code associated with each type of resource separate. It also has benefits in terms of maintenance, because you can change the URL used to deliver a particular feature in one place, without having to change the handler function. -For example, consider the following Django (Python) code that maps two URL patterns to two view functions. The first pattern ensures that an HTTP request with a resource URL of `/best` will be passed to a function named `index()` in the `views` module. A request that has the pattern "`/best/junior`", will instead be passed to the `junior()` view function. +For example, consider the following Django (Python) code that maps two URL patterns to two view functions. The first pattern ensures that an HTTP request with a resource URL of `/best` will be passed to a function named `index()` in the `views` module. A request that has the pattern `/best/junior`, will instead be passed to the `junior()` view function. ```python # file: best/urls.py diff --git a/files/en-us/mdn/writing_guidelines/page_structures/syntax_sections/index.md b/files/en-us/mdn/writing_guidelines/page_structures/syntax_sections/index.md index 4de9608b0eb941e..d05bd6f85bc1318 100644 --- a/files/en-us/mdn/writing_guidelines/page_structures/syntax_sections/index.md +++ b/files/en-us/mdn/writing_guidelines/page_structures/syntax_sections/index.md @@ -105,7 +105,7 @@ new Date(year, monthIndex, day, hours, minutes, seconds, milliseconds) Formal syntax notation (using [BNF](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form)) should not be used in the Syntax section — instead use the expanded multiple-line format [described above](#multiple_linesoptional_parameters). -While the formal notation provides a concise mechanism for describing complex syntax, it is not familiar to many developers, and can _conflict_ with valid syntax for particular programming languages. For example, "`[ ]`" indicates both an "optional parameter" and a JavaScript {{jsxref("Array")}}. You can see this in the formal syntax for {{jsxref("Array.prototype.slice()")}} below: +While the formal notation provides a concise mechanism for describing complex syntax, it is not familiar to many developers, and can _conflict_ with valid syntax for particular programming languages. For example, `[ ]` indicates both an "optional parameter" and a JavaScript {{jsxref("Array")}}. You can see this in the formal syntax for {{jsxref("Array.prototype.slice()")}} below: ```js-nolint arr.slice([begin[, end]]) diff --git a/files/en-us/web/mathml/element/semantics/index.md b/files/en-us/web/mathml/element/semantics/index.md index bb6b346670c6426..a02ebed7eb12ba3 100644 --- a/files/en-us/web/mathml/element/semantics/index.md +++ b/files/en-us/web/mathml/element/semantics/index.md @@ -25,7 +25,7 @@ By default, only the first child of the `` element is rendered while > - `"SVG1.1"` > - `"text/html"` > - `"image/svg+xml"` -> - `"application/xml`". +> - `"application/xml"` > > Note that `"application/mathml+xml"` is _not_ mentioned here as it does not distinguish between Content or Presentation MathML. diff --git a/files/en-us/web/opensearch/index.md b/files/en-us/web/opensearch/index.md index 02d0ddf01c5563a..d0bd88dcb561389 100644 --- a/files/en-us/web/opensearch/index.md +++ b/files/en-us/web/opensearch/index.md @@ -138,7 +138,7 @@ If there is a mistake in your Search Plugin XML, you could run into errors when - You **must** include a `text/html` URL — search plugins including only Atom or [RSS](/en-US/docs/Glossary/RSS) URL types (which is valid, but Firefox doesn't support) will also generate the "could not download the search plugin" error. - Remotely fetched favicons must not be larger than 10KB (see [Firefox bug 361923](https://bugzil.la/361923)). -In addition, the search plugin service provides a logging mechanism that may be useful to plugin developers. Use `about:config` to set the pref '`browser.search.log`' to `true`. Then, logging information will appear in Firefox's [Browser Console](https://firefox-source-docs.mozilla.org/devtools-user/browser_console/index.html) (Tools ➤ Browser Tools ➤ Browser Console) when search plugins are added. +In addition, the search plugin service provides a logging mechanism that may be useful to plugin developers. Use `about:config` to set the pref `browser.search.log` to `true`. Then, logging information will appear in Firefox's [Browser Console](https://firefox-source-docs.mozilla.org/devtools-user/browser_console/index.html) (Tools ➤ Browser Tools ➤ Browser Console) when search plugins are added. ## Reference Material diff --git a/files/en-us/web/progressive_web_apps/tutorials/cycletracker/javascript_functionality/index.md b/files/en-us/web/progressive_web_apps/tutorials/cycletracker/javascript_functionality/index.md index 6c77a332b20e78e..7e0e4859faaced6 100644 --- a/files/en-us/web/progressive_web_apps/tutorials/cycletracker/javascript_functionality/index.md +++ b/files/en-us/web/progressive_web_apps/tutorials/cycletracker/javascript_functionality/index.md @@ -21,7 +21,7 @@ At the end of this lesson, you will have a fully functional app. In future lesso When a user visits the page, we check if they have existing data stored in local storage. The first time a user visits the page, there won't be any data. When a new user selects two dates and submits the form, we need to: -1. Create a "`

Past periods

`" header +1. Create a `

Past periods

` header 2. Create an {{HTMLelement("ul")}} 3. Populate the `
    ` with a single {{HTMLelement("li")}} containing information about that cycle 4. Save the data to local storage @@ -36,7 +36,7 @@ For each subsequent form submission, we need to: Existing users will have existing data in local storage. When a user comes back to our webpage with the same browser on the same device, we need to: 1. Retrieve the data from local storage -2. Create a "`

    Past periods

    `" header +2. Create a `

    Past periods

    ` header 3. Create an {{HTMLelement("ul")}} 4. Populate the `
      ` with an {{HTMLelement("li")}} for every menstrual cycle saved in local storage. diff --git a/files/en-us/web/security/same-origin_policy/index.md b/files/en-us/web/security/same-origin_policy/index.md index 5d4d6eb11cb2b37..6d820e7a66ecc19 100644 --- a/files/en-us/web/security/same-origin_policy/index.md +++ b/files/en-us/web/security/same-origin_policy/index.md @@ -52,11 +52,11 @@ For example, assume a script from the document at `http://store.company.com/dir/ document.domain = "company.com"; ``` -Afterward, the page can pass the same-origin check with `http://company.com/dir/page.html` (assuming `http://company.com/dir/page.html` sets its `document.domain` to "`company.com`" to indicate that it wishes to allow that - see {{domxref("document.domain")}} for more). However, `company.com` could **not** set `document.domain` to `othercompany.com`, since that is not a superdomain of `company.com`. +Afterward, the page can pass the same-origin check with `http://company.com/dir/page.html` (assuming `http://company.com/dir/page.html` sets its `document.domain` to `"company.com"` to indicate that it wishes to allow that - see {{domxref("document.domain")}} for more). However, `company.com` could **not** set `document.domain` to `othercompany.com`, since that is not a superdomain of `company.com`. The port number is checked separately by the browser. Any call to `document.domain`, including `document.domain = document.domain`, causes the port number to be overwritten with `null`. Therefore, one **cannot** make `company.com:8080` talk to `company.com` by only setting `document.domain = "company.com"` in the first. It has to be set in both so their port numbers are both `null`. -The mechanism has some limitations. For example, it will throw a "`SecurityError`" [`DOMException`](/en-US/docs/Web/API/DOMException) if the [`document-domain`](/en-US/docs/Web/HTTP/Headers/Permissions-Policy/document-domain) [`Permissions-Policy`](/en-US/docs/Web/HTTP/Headers/Permissions-Policy) is enabled or the document is in a sandboxed [`