diff --git a/book/CH00_Introduction.adoc b/book/CH00_Introduction.adoc index 1f721e8..a79d582 100644 --- a/book/CH00_Introduction.adoc +++ b/book/CH00_Introduction.adoc @@ -43,7 +43,7 @@ system of the web. To explain what a hypermedia-driven application looks like, and to contrast it with the popular SPA approach of today, we need to first explore the entire _hypermedia system_ of the web, beyond just discussing HTML. We need to look at the _network architecture_ of the original web, including how a web server delivers a hypermedia API, and how to effectively -use the hypermedia features available in the hypermedia _client_ (e.g. the browser). +use the hypermedia features available in the hypermedia _client_ (e.g., the browser). Each of these are important aspects of building an effective hypermedia-driven application, and it is the entire _hypermedia system_ that comes together to make hypermedia such a powerful architecture. diff --git a/book/CH01_HypermediaAReintroduction.adoc b/book/CH01_HypermediaAReintroduction.adoc index 5981710..a2062c6 100644 --- a/book/CH01_HypermediaAReintroduction.adoc +++ b/book/CH01_HypermediaAReintroduction.adoc @@ -65,8 +65,8 @@ hypertexts such as HTML, the Hypertext Markup Language, or HXML, a hypertext us system. Hypertexts like HTML function alongside other technologies crucial for making an entire hypermedia system work: network -protocols like HTTP, other media types such as images, videos, hypermedia servers (i.e. servers providing hypermedia APIs), -sophisticated hypermedia clients (e.g. web browsers), and so on. +protocols like HTTP, other media types such as images, videos, hypermedia servers (i.e., servers providing hypermedia APIs), +sophisticated hypermedia clients (e.g., web browsers), and so on. Because of this, we prefer the broader term _hypermedia systems_ when describing the underlying architecture of applications built using hypertext, to emphasize the system architecture over the particular hypermedia being used. @@ -144,7 +144,7 @@ The system that Berners-Lee, Fielding and many others had created revolved aroun hypermedia, used to publish (at first) academic documents. These documents were linked together via anchor tags which created _hyperlinks_ between them, allowing users to quickly navigate between documents. -When HTML 2.0 was released, it introduced the notion of the `form` tag, joining the anchor tag (i.e. hyperlink) as a +When HTML 2.0 was released, it introduced the notion of the `form` tag, joining the anchor tag (i.e., hyperlink) as a second hypermedia control. The introduction of the form tag made building _applications_ on the web viable by providing a mechanism for _updating_ resources, rather than just reading them. diff --git a/book/CH02_ComponentsOfAHypermediaSystem.adoc b/book/CH02_ComponentsOfAHypermediaSystem.adoc index a460254..7b6feb5 100644 --- a/book/CH02_ComponentsOfAHypermediaSystem.adoc +++ b/book/CH02_ComponentsOfAHypermediaSystem.adoc @@ -228,7 +228,7 @@ HTTP breaks response codes up into various categories: Redirection responses indicating that the request should be sent to some other URL. `400`-`499`:: - Client error responses indicating that the client made some sort of bad request (e.g. asking for something that didn't + Client error responses indicating that the client made some sort of bad request (e.g., asking for something that didn't exist in the case of `404` errors). `500`-`599`:: diff --git a/book/CH04_BuildingASimpleWebApplication.adoc b/book/CH04_BuildingASimpleWebApplication.adoc index 156a9b0..d2533d2 100644 --- a/book/CH04_BuildingASimpleWebApplication.adoc +++ b/book/CH04_BuildingASimpleWebApplication.adoc @@ -89,7 +89,7 @@ with a route. Let's create our first route definition, a simple "`Hello Flask`" route. In the following python code you will see the `@app` symbol. This is the flask decorator that allows us to set up our routes. Don't worry too much about how decorators work in Python, just know that this feature allows us to map a given _path_ to a particular function -(i.e. handler). The Flask application, when started, will take HTTP requests and look up the matching handler and +(i.e., handler). The Flask application, when started, will take HTTP requests and look up the matching handler and invoke it. .A simple "`Hello World`" route @@ -561,7 +561,7 @@ our handler logic will get, even when we look at adding more sophisticated htmx- The next piece of functionality we will implement is the detail page for a Contact. The user will navigate to this page by clicking the "`View`" link in one of the rows in the list of contacts. This will take them to the path -`/contact/` (e.g. `/contacts/42`). +`/contact/` (e.g., `/contacts/42`). This is a common pattern in web development: contacts are treated as resources and the URLs around these resources are organized in a coherent manner. diff --git a/book/CH05_ExtendingHTMLAsHypermedia.adoc b/book/CH05_ExtendingHTMLAsHypermedia.adoc index f292501..dad04f7 100644 --- a/book/CH05_ExtendingHTMLAsHypermedia.adoc +++ b/book/CH05_ExtendingHTMLAsHypermedia.adoc @@ -738,16 +738,16 @@ The `hx-include` attribute and, in fact, most attributes that take a CSS selecto These allow you to specify a CSS selector _relative_ to the element it is declared on. Here are some examples: `closest`:: -Find the closest parent element matching the given selector, e.g. `closest form`. +Find the closest parent element matching the given selector, e.g., `closest form`. `next`:: -Find the next element (scanning forward) matching the given selector, e.g. `next input`. +Find the next element (scanning forward) matching the given selector, e.g., `next input`. `previous`:: -Find the previous element (scanning backwards) matching the given selector, e.g. `previous input`. +Find the previous element (scanning backwards) matching the given selector, e.g., `previous input`. `find`:: -Find the next element within this element matching the given selector, e.g. `find input`. +Find the next element within this element matching the given selector, e.g., `find input`. `this`:: The current element. diff --git a/book/CH06_htmxPatterns.adoc b/book/CH06_htmxPatterns.adoc index bbe0802..fda3ad5 100644 --- a/book/CH06_htmxPatterns.adoc +++ b/book/CH06_htmxPatterns.adoc @@ -663,16 +663,16 @@ an extension to normal CSS. Htmx supports prefixes that will find targets _rela .Relative Positional Expressions in Htmx **** `next`:: -Scan forward in the DOM for the next matching element, e.g. `next .error` +Scan forward in the DOM for the next matching element, e.g., `next .error` `previous`:: -Scan backwards in the DOM for the closest previous matching element, e.g. `previous .alert` +Scan backwards in the DOM for the closest previous matching element, e.g., `previous .alert` `closest`:: -Scan the parents of this element for matching element, e.g. `closest table` +Scan the parents of this element for matching element, e.g., `closest table` `find`:: -Scan the children of this element for matching element, e.g. `find span` +Scan the children of this element for matching element, e.g., `find span` `this`:: the current element is the target (default) diff --git a/book/CH07_MorehtmxPatterns.adoc b/book/CH07_MorehtmxPatterns.adoc index 4468f7b..1414c31 100644 --- a/book/CH07_MorehtmxPatterns.adoc +++ b/book/CH07_MorehtmxPatterns.adoc @@ -201,7 +201,7 @@ So we need some way to determine exactly which of these two different types of r made, in order to know exactly which content we want to render. It turns out that htmx helps us distinguish between these two cases by including a number of HTTP _Request Headers_ when -it makes requests. Request Headers are a feature of HTTP, allowing clients (e.g. web browsers) to include name/value pairs +it makes requests. Request Headers are a feature of HTTP, allowing clients (e.g., web browsers) to include name/value pairs of metadata associated with requests to help the server understand what the client is requesting. Here is an example of (some of) the headers the FireFox browser issues when requesting `https://manning.com`: @@ -406,7 +406,7 @@ application. One subtle aspect of the approach we are taking here, using headers to determine the content of what we return, is a feature baked into HTTP: caching. In our request handler, we are now returning different content depending on the value of the `HX-Trigger` header. If we were to use HTTP Caching, we might get into a situation where someone makes -a _non-htmx_ request (e.g. refreshing a page) and yet the _htmx_ content is returned from the HTTP cache, resulting +a _non-htmx_ request (e.g., refreshing a page) and yet the _htmx_ content is returned from the HTTP cache, resulting in a partial page of content for the user. The solution to this problem is to use the HTTP Response `Vary` header and call out the htmx headers that you are using @@ -500,7 +500,7 @@ the element from view, while at the same time not disrupting the layout of the p When an htmx request is triggered that points to this indicator, another class, `htmx-request` is added to the indicator which transitions its opacity to 1. So you can use just about anything as an indicator, and it will be hidden by default. Then, when a request is in flight, it will be shown. This is all done via standard CSS classes, allowing you to control -the transitions and even the mechanism by which the indicator is shown (e.g. you might use `display` rather than +the transitions and even the mechanism by which the indicator is shown (e.g., you might use `display` rather than `opacity`). .Use Request Indicators!