Fixes for bsmth review comments

files/en-us/learn_web_development/core/structuring_content/basic_html_syntax/index.md

@@ -49,7 +49,7 @@ If we wanted the text to stand by itself, we could specify that it is a paragrap
 
 HTML lives inside text files called **HTML documents**, or just **documents**, with a `.html` file extension. Where previously we've talked about web pages, an HTML document contains the web page's content and specifies its structure.
 
-The most common HTML file you'll encounter is `index.html`, which is generally used to contain a website's home page content.
+The most common HTML file you'll encounter is `index.html`, which is generally used to contain a website's home page content. It's also common to see subfolders with their own `index.html`, so a website can have multiple index files in different places.
 
 > [!NOTE]
 > Tags in HTML are not case-sensitive. This means they can be written in uppercase or lowercase. For example, a {{htmlelement("title")}} tag could be written as `<title>`, `<TITLE>`, `<Title>`, `<TiTlE>`, etc., and it will work. However, it is best practice to write all tags in lowercase for consistency and readability.

files/en-us/learn_web_development/getting_started/web_standards/how_browsers_load_websites/index.md

@@ -161,23 +161,23 @@ The final output is as follows:
 
 {{EmbedLiveSample('Handling the JavaScript', '100%', 90)}}
 
-## What else happens?
+## What other rendering steps are there?
 
-There are several other things that happen during page rendering, but we won't discuss them all here. One notable additional occurrence worth mentioning is that an accessibility tree is built, based on the DOM, for assistive technologies (for example screen readers) to hook into, which enables people who are not able to see the rendered content to interact with it.
+Several other things happen during page rendering, but we won't discuss them all here. One notable additional occurrence worth mentioning is that an accessibility tree is built, based on the DOM, for assistive technologies (for example screen readers) to hook into, which enables people who are not able to see the rendered content to interact with it.
 
 You will learn more about this later on, in our [Accessibility](/en-US/docs/Learn_web_development/Core/Accessibility) module.
 
 ## The browser: a hostile _and_ an awesome programming environment
 
 Front-end web development can sometimes be frustrating, and some people consider the browser to be a hostile programming environment. This is because, unlike other programming environments, it is much harder to make guarantees about the environment your code will run on. You cannot know ahead of time all the different combinations of operating system, browser, language, location, network connection, CPU, GPU, memory, battery life, etc., that your users will have, therefore you cannot guarantee a perfect user experience for all of them.
 
-Modern browsers tend to implement web standards pretty consistently, but there is still a lot of uncertainty to navigate. As a web developer, you will need to embrace that uncertainty and learn to program defensively. This relies on adhering to the [best practices](/en-US/docs/Learn_web_development/Getting_started/Web_standards/The_web_standards_model#web_best_practices) outlined in the previous article.
+Modern browsers tend to implement web standards pretty consistently, but there is still a lot of uncertainty to navigate. As a web developer, you will need to embrace that uncertainty, programming defensively and being conservative with the features you use. This relies on adhering to the [best practices](/en-US/docs/Learn_web_development/Getting_started/Web_standards/The_web_standards_model#web_best_practices) outlined in the previous article.
 
 On the upside, the web is also an awesome programming environment, for many reasons.
 
-- For a start, it is designed with universal access in mind — its basic state is accessible and linkable. Some of these basics are harder to achieve in other environments.
+- For a start, it is designed with universal access in mind. The web's basic state is accessible and linkable. Some of these basics are harder to achieve in other environments.
 - App delivery across the web is simple and powerful. You don't need to take your users through a complicated installation process: you just point them to a web address and off they go.
-- As a result, app updates are also easy — in many cases, you can just reload the browser tab. You don't need to worry about getting your users to constantly download and install large packages.
+- App updates are usually straightforward. In many cases, visitors can see new versions of an application when they reload their browser tab. You don't need to worry about getting visitors to regularly download and install software updates.
 - The web community is vibrant and helpful. As we discuss later on in our [Research and learning](/en-US/docs/Learn_web_development/Getting_started/Soft_skills/Research_and_learning) article, there are lots of places you can do to ask for help, and great resources available to learn from.
 
 {{PreviousMenuNext("Learn_web_development/Getting_started/Web_standards/The_web_standards_model", "Learn_web_development/Getting_started/Soft_skills", "Learn_web_development/Getting_started/Web_standards")}}

files/en-us/learn_web_development/getting_started/web_standards/how_the_web_works/index.md

@@ -46,7 +46,7 @@ Computers connected to the internet are called **clients** and **servers**. A si
 ![Two circles representing client and server. An arrow labelled request is going from client to server, and an arrow labelled responses is going from server to client](simple-client-server.png)
 
 - Clients are the typical web user's internet-connected devices (for example, your computer connected to your Wi-Fi, or your phone connected to your mobile network) and web-accessing software available on those devices (usually a web browser like Firefox or Chrome).
-- Servers are computers that store webpages, sites, or apps. When a client device wants to access a webpage, a copy of the webpage code is downloaded from the server onto the client machine to rendered by the browser and displayed to the user.
+- Servers are computers that store webpages, sites, or apps. When a client wants to access a webpage, a copy of the webpage code is downloaded from the server onto the client machine to rendered by the browser and displayed to the user.
 
 ## The other parts of the toolbox
 
@@ -62,9 +62,9 @@ In order for data to get back and forth, we need the following things:
 - **TCP/IP**: **Transmission Control Protocol** and **Internet Protocol** (TCP/IP) are communication protocols that define how data should travel across the internet. This is like the transport mechanisms that let you place an order, go to the shop, and buy your goods. In our example, this is like a car or a bike (or however else you might travel along the road).
 - **DNS**: The **Domain Name System** (DNS) is like an address book for websites. When you type a web address in your browser, the browser looks at the DNS to find the website's IP address — the actual address the server is located at — before it can retrieve the website (see [DNS explained](#dns_explained) below for more information). The browser needs to find out which server the website lives on, so it can send HTTP messages to the right place (see below). This is like looking up the address of the shop before you visit it.
 - **HTTP**: **Hypertext Transfer Protocol** (HTTP) is an application {{Glossary("Protocol", "protocol")}} that defines a language for clients and servers to speak to each other. This is like the language you use to order your goods. See [HTTP basics](#http_basics) below.
-- **Component files**: A website is made up of many different files, which are like the different goods you buy from the shop. These files come in two main types:
+- **Files**: A website is made up of many different files, which are like the different goods you buy from the shop. These files come in two main types:
 
-  - **Code files**: Websites are built primarily from HTML, CSS, and JavaScript — the different programming languages websites are written in, which the browser interprets and assembles into a web page to display to a user.
+  - **Code**: Websites are built primarily from HTML, CSS, and JavaScript — the different programming languages websites are written in, which the browser interprets and assembles into a web page to display to a user.
   - **Assets**: This is a collective term for all the other items that appear on a website — such as images, music, video, Word documents, and PDFs — that aren't code that the browser interprets.
 
   > [!NOTE]
@@ -144,16 +144,16 @@ The full response is more complex than this, but we have omitted most of it for
 
 ### Other status codes
 
-Above, we met the `200` [status code](/en-US/docs/Web/HTTP/Status), which indicates that the HTTP request was successful. There are many other status code that you'll come across; the most common ones are:
+Above, we met the `200` [status code](/en-US/docs/Web/HTTP/Status), which indicates that the HTTP request was successful. There are many HTTP status codes with specific meanings and uses, but you will only commonly see a few:
 
 - `301`
   - : The requested resource has been permanently moved to a new location, which is provided in the response. This is used for redirecting content when it's moved.
 - `400`
-  - : The server cannot or will not process the request due to a problem with the request itself.
+  - : The server can't process the request. This usually happens when the request isn't in a format the server understands, or has errors in it.
 - `403`
-  - : The server will not give the client access to the requested resource because it does not have the necessary permissions to access it.
+  - : The server will not give the client access to the requested resource. This usually happens when the server knows who the client is, but they don't have permission to access the requested page.
 - `404`
-  - : The server cannot find the requested resource.
+  - : The server cannot find the requested resource. This status is commonly returned if the URL is wrong or if content is deleted without putting a redirect in place.
 - `503`
   - : The request cannot be handled due to a problem with the server. This is common when servers are offline for maintenance, and it's expected to be temporary.
 

files/en-us/learn_web_development/getting_started/web_standards/the_web_standards_model/index.md

@@ -210,14 +210,14 @@ There is another class of languages called back-end (or server-side) languages,
 
 Example server-side frameworks and languages include ASP.NET (C#), Django (Python), Laravel (PHP), and Next.js (JavaScript).
 
-These technologies are not considered to be "web standards" — they are developed by organizations outside the web standards processes of organization such as the W3C and WHATWG — although some of them will have processes that are similarly open.
+These technologies are not considered to be "web standards" — they are developed by organizations outside the web standards processes of organizations such as the W3C and WHATWG — although some of them will have processes that are similarly open.
 
 ### Static versus dynamic
 
 Another way that client-side and server-side languages are often described is **static** and **dynamic**:
 
 - A plain HTML file is stored on the server. When requested, it is delivered to the client, unchanged, and rendered by the browser. Because it does not change, it is referred to as "static".
-- Revisiting the server-side example we briefly described above, when some server-side code (for example, a Python script or an ASP.NET page) queries a database, generates some HTML to contain the data and then returns that HTML to the client for the browser to render and display, that HTML is the same page, but with some of the content changed depending on what inputs the server-side code received in the request. It is therefore referred to as "dynamic".
+- When server-side code (for example, a Python script or an ASP.NET page) generates some HTML containing data and returns that HTML to the client, the contents of the HTML change depending on what the server-side code does. It is therefore referred to as "dynamic".
 
 There is often a bit of overlap between the concepts of static and dynamic code. Server-side languages usually define HTML structures inside a template file, which tend to be mostly static HTML with some special dynamic sections included that change depending on what data needs to be inserted.