index add

book/CH02_ComponentsOfAHypermediaSystem.adoc

@@ -831,7 +831,7 @@ special nature of HTML, hypermedia and the web!
 :sectnums!:
 
 [.html-note]
-== HTML Note: HTML5 Soup
+== HTML Notes: HTML5 Soup
 
 [quote,Confucius]
 The beginning of wisdom is to call things by their right names.

book/CH07_ADynamicArchiveUIWithhtmx.adoc

@@ -3,8 +3,6 @@
 :chapter: 07
 :url: /a-dynamic-archive-ui/
 
-== A Dynamic Archive UI
-
 Contact.app has come a long way from a traditional web 1.0-style web application:
 we've added active search, bulk delete, some nice animations, and a slew of other features.  We have reached a level
 of interactivity that most web developers would assume requires some sort of Single-Page Application JavaScript framework,

book/CH09_ScriptingInAHypermediaApplication.adoc

@@ -489,8 +489,7 @@ As we web developers create more interactive, app-like websites, HTML's repertoi
 As we have seen, using CSS and JavaScript, we can endow existing elements with extended behavior and appearances, rivaling
 those of native controls.
 
-However, there is one thing web apps used to be unable to replicate. While these widgets are similar enough in appearance
-for most users to operate, assistive technology (e.g., screen readers) can only report the underlying HTML elements.
+However, there was one thing web apps couldn't replicate. While these widgets may _look_ similar enough to the real deal, assistive technology (e.g., screen readers) could only deal with the underlying HTML elements.
 
 Even if you take the time to get all the keyboard interactions right, some users often are unable to work with these custom
 elements easily.
@@ -501,33 +500,22 @@ a set of attributes you can add to HTML to make it meaningful to assistive softw
 ARIA has two main components that interact with one another:
 
 The first is the `role` attribute. This attribute has a predefined set of possible values:
-
-* `menu`
-* `dialog`
-* `radiogroup`
-* etc.
-
-The `role` attribute _does not add any behavior_ to HTML elements. Rather, it is a promise you make to the user.  When
+`menu, dialog, radiogroup` etc.
+The `role` attribute _does not add any behavior_ to HTML elements.
+Rather, it is a promise you make to the user.  When
 you annotate an element as `role='menu'`, you are saying: _I will make this element work like a menu._
 
-Because this is a promise you are making, if you add the `role` attribute to an element but you _don't_ uphold
-the promise, the experience for many users will be _worse_ than if the element had no `role` annotation on it at all.
-
-Because of this, it is written:
+If you add a `role` to an element but you _don't_ uphold the promise,
+the experience for many users will be _worse_ than if the element had no `role` at all.
+Thus, it is written:
 
 [quote, W3C, Read Me First | APG https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/]
 No ARIA is better than Bad ARIA.
 
-The second component of ARIA is a whole range of attributes, all sharing the `aria-` prefix:
-
-* `aria-expanded`
-* `aria-controls`
-* `aria-label`
-* etc.
-
+The second component of ARIA is the _states and properties_, all sharing the `aria-` prefix:
+`aria-expanded, aria-controls, aria-label` etc.
 These attributes can specify various things such as the state of a widget, the relationships between components, or
 additional semantics.
-
 Once again, these attributes are _promises_, not implementations.
 
 Rather than learn all the roles and attributes and try to combine them into a usable widget,
@@ -536,12 +524,11 @@ a web resource with practical information aimed directly at web developers.
 
 If you're new to ARIA, check out the following W3C resources:
 
- - https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/[ARIA Read Me First]
- - https://www.w3.org/WAI/ARIA/apg/patterns/[ARIA UI patterns]
- - https://www.w3.org/WAI/ARIA/apg/practices/[ARIA Good Practices]
+ - ARIA: Read Me First: https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/[]
+ - ARIA UI patterns: https://www.w3.org/WAI/ARIA/apg/patterns/[]
+ - ARIA Good Practices: https://www.w3.org/WAI/ARIA/apg/practices/[]
 
-Always remember to test your website for accessibility to ensure a maximum number of users can interact with it
-easily and effectively.
+Always remember to **test** your website for accessibility to ensure all users can interact with it easily and effectively.
 ****
 
 With this brief introduction to ARIA, let's return to our VanillaJS drop down menu.  We'll begin with the RSJS
@@ -720,6 +707,7 @@ more sense to use an off-the-shelf library, such as GitHub's https://github.com/
 But, for our relatively simple use case, vanilla JavaScript does a fine job, and we got to explore ARIA and RSJS while
 implementing it.
 
+
 == Alpine.js
 
 (((Alpine.js)))

book/CH10_JSONDataAPIs.adoc

@@ -3,9 +3,6 @@
 :chapter: 10
 :url: /json-data-apis/
 
-[partintro]
-== JSON Data APIs
-
 So far we have been focusing on using hypermedia to build Hypermedia-Driven Applications.  In doing so we are
 following and taking advantage of the native network architecture of the web, and building a RESTful system, in the original sense
 of that term.

book/CH11_HyperviewAMobileHypermedia.adoc

@@ -1333,26 +1333,46 @@ In the next two chapters we'll show how by turning the Contact.app web applicati
 :sectnums!:
 
 [.html-note]
-== HTML Notes: Maximize Your Server-Side Strengths
+== Hypermedia Notes: Maximize Your Server-Side Strengths
 
-A big advantage of the hypermedia-driven approach is that it makes the server-side environment far more important when building your web application. Rather than simply producing JSON, your back end is an integral component in the user experience of your web application.
+In the Hyperview sections of the book, since we aren't using HTML, we are going to make broader observations on hypermedia
+rather than offer HTML-specific advice and thoughts.
 
-Because of this, it makes sense to look deeply into the functionality available there. Many older web frameworks have incredibly deep functionality available around producing HTML. Features like server-side caching can make the difference between an incredibly snappy web application and a sluggish user experience.
+A big advantage of the hypermedia-driven approach is that it makes the server-side environment far more important when
+building your web application. Rather than simply producing JSON, your back end is an integral component in the user
+experience of your hypermedia application.
+
+Because of this, it makes sense to look deeply into the functionality available there. Many older web frameworks, for example,
+have incredibly deep functionality available around producing HTML. Features like server-side caching can make the
+difference between an incredibly snappy web application and a sluggish user experience.
 
 Take time to learn all the tools available to you.
 
-A good rule of thumb is to shoot to have responses in your application take less than 100ms to complete, and mature server side frameworks have tools to help make this happen.
+A good rule of thumb is to shoot to have server responses in your hypermedia-driven application take less than 100ms to
+complete, and mature server-side frameworks have tools to help make this happen.
 
-Server-side environments often have extremely mature mechanisms for factoring (or organizing) your code properly. The Model/View/Controller pattern is well-developed in most environments, and tools like modules, packages, etc. provide an excellent way to organize your code.
+Server-side environments often have extremely mature mechanisms for factoring (or organizing) your code properly. The
+Model/View/Controller pattern is well-developed in most environments, and tools like modules, packages, etc. provide an
+excellent way to organize your code.
 
-Whereas SPAs user interfaces are typically organized via components, hypermedia-driven applications are typically organized via template inclusion, where the server-side templates are broken up according to the HTML-rendering needs of the application, and then included in one another as needed. This tends to lead to fewer, chunkier files than you would find in a component-based application.
+Whereas today's SPA and mobile user interfaces are typically organized via components, hypermedia-driven applications
+are typically organized via template inclusion, where the server-side templates are broken up according to the
+hypermedia-rendering needs of the application, and then included in one another as needed. This tends to lead to fewer,
+chunkier files than you would find in a component-based application.
 
-Another technology to look for are Template Fragments, which allow you to render only part of a template file. This can reduce even further the number of template files required for your server-side application.
+Another technology to look for are Template Fragments, which allow you to render only part of a template file. This can
+reduce even further the number of template files required for your server-side application.
 
-A related tip is to take advantage of direct access to the data store. When an application is built using the SPA approach, the data store typically lives behind a JSON API. This level of indirection often prevents front end developers from being able to take full advantage of the tools available in the data store. GraphQL can help address this issue, but comes with security-related issues that do not appear to be well understood by many developers.
+A related tip is to take advantage of direct access to the data store. When an application is built using a thick client
+approach, the data store typically lives behind a data API (e.g. JSON). This level of indirection often prevents front
+end developers from being able to take full advantage of the tools available in the data store. GraphQL, for example,
+can help address this issue, but comes with security-related issues that do not appear to be well understood by many developers.
 
-When you produce your HTML on the server side, on the other hand, the developer creating that HTML can have full access to the data store and take advantage of, for example, joins and aggregation functions in SQL stores.
+When you produce your hypermedia on the server side, on the other hand, the developer creating that hypermedia can have
+full access to the data store and take advantage of, for example, joins and aggregation functions in SQL stores.
 
-This puts far more expressive power directly in the hands of the developer producing the HTML. Because your hypermedia API can be structured around your UI needs, you can tune each endpoint to issue as few data store requests as possible.
+This puts far more expressive power directly in the hands of the developer producing the final hypermedia. Because your
+hypermedia API can be structured around your UI needs, you can tune each endpoint to issue as few data store requests as possible.
 
-A good rule of thumb is that every request should shoot to have three or fewer data-store accesses.
+A good rule of thumb is that every request to your server should shoot to have three or fewer data-store accesses.  If
+you follow this rule of thumb, your hypermedia-driven application should be extremely snappy.

book/CH12_BuildingAContactsAppWithHyperview.adoc

@@ -1336,13 +1336,19 @@ In the next chapter we'll implement custom behaviors and UI elements to finish o
 :sectnums!:
 
 [.html-note]
-== HTML Notes: API Endpoints
+== Hypermedia Notes: API Endpoints
 
-Unlike a JSON API, the hypermedia API you produce for your hypermedia-driven application should feature endpoints specialized for your particular application’s UI needs.
+Unlike a JSON API, the hypermedia API you produce for your hypermedia-driven application should feature endpoints
+specialized for your particular application’s UI needs.
 
-Because hypermedia APIs are not designed to be consumed by general-purpose clients you can set aside the pressure to keep them generalized and produce the content specifically needed for your application.
-Your endpoints should be optimized to support your particular applications UI/UX needs, not for a general-purpose data-access model for your domain model.
+Because hypermedia APIs are not designed to be consumed by general-purpose clients you can set aside the pressure to keep
+them generalized and produce the content specifically needed for your application. Your endpoints should be optimized to
+support your particular applications UI/UX needs, not for a general-purpose data-access model for your domain model.
 
-A related tip is that, when you have a hypermedia-based API, you can aggressively refactor your API in a way that is heavily discouraged when writing JSON API-based SPAs. Because hypermedia-based applications use Hypermedia As The Engine Of Application State, you are able and, in fact, encouraged, to change the shape of them as your application developers and as use cases change.
+A related tip is that, when you have a hypermedia-based API, you can aggressively refactor your API in a way that is
+heavily discouraged when writing JSON API-based SPAs or mobile clients. Because hypermedia-based applications use
+Hypermedia As The Engine Of Application State, you are able and, in fact, encouraged, to change the shape of them as
+your application developers and as use cases change.
 
-A great strength of the hypermedia approach is that you can completely rework your API to adapt to new needs over time without needing to version the API or even document it.
+A great strength of the hypermedia approach is that you can completely rework your API to adapt to new needs over
+time without needing to version the API or even document it.  Take advantage of it!

book/CH13_ExtendingTheHyperviewClient.adoc

@@ -737,23 +737,19 @@ Yes, there is a story for Hypermedia-Driven Applications on mobile.
 :sectnums!:
 
 [.html-note]
-== HTML Notes: Good-Enough UX and Islands of Interactivity
+== Hypermedia Notes: Good-Enough UX and Islands of Interactivity
 
-A problem many SPA developers face when coming to the HDA approach is that they look at their current SPA application and imagine implementing it exactly using hypermedia. While htmx and other hypermedia-oriented libraries significantly close the interactivity gap between hypermedia-based applications and SPAs, that gap still exists.
+A problem many SPA and native mobile developers face when coming to the HDA approach is that they look at their current
+application and imagine implementing it exactly using hypermedia. While htmx and HyperView significantly improve the
+user experience available via the hypermedia-driven approach, there are still times when it won't be easy to pull of
+a particular user experience.
 
-As we saw in Chapter Two, Roy Fielding noted this tradeoff with respect to the web’s RESTful network architecture, where "information is transferred in a
-standardized form rather than one which is specific to an application's needs."
+As we saw in Chapter Two, Roy Fielding noted this tradeoff with respect to the web’s RESTful network architecture,
+where "information is transferred in a standardized form rather than one which is specific to an application's needs."
 
-Accepting a slightly less efficient and interactive solution to a particular UX can save you a tremendous amount of complexity when building a web application.
+Accepting a slightly less efficient and interactive solution to a particular UX can save you a tremendous amount of
+complexity when building your applications.
 
-Do not let the perfect be the enemy of the good.
-
-Still, there may come a point in your application where the hypermedia approach, on its own, just doesn’t cut it.
-
-A good example of this is re-ordering a list of things. This can be done in “`pure`” hypermedia by clicking up and down arrows or having order # drop-downs next to items.
-
-But this experience stinks compared to what people are used to: drag-and-drop.
-
-In cases like this, it is perfectly fine to use a front-end heavy approach, such as SortableJS, as an “`Island of Interactivity.`”
-
-This is an excellent way to encapsulate richer UX within an HDA.
+Do not let the perfect be the enemy of the good.  Many advantages are to be gained by accepting a slightly less
+sophisticated user experience in some cases, and tools like htmx and HyperView make that compromise much more palatable
+when they are used properly.

book/INDEX.adoc

@@ -4,20 +4,19 @@
 
 * accessibility	154, 207
 * AJAX	21, 86, 98, 102
-* Alpine.js	213
-** installing	213
-** x-data	213
-** x-if	216
-** x-model	216
-** x-on:click	214
-** x-text	214
-* anchor tag, <a>	17, 81
-* Angular	23
-* Archiver	159
+* Alpine.js	212
+** installing	212
+** x-data	212
+** x-if	215
+** x-model	215
+** x-on:click	213
+** x-text	213
+* anchor tag, <a>	17, 80
+* Archiver	157
 * ARIA	154, 207
 * authentication	239
 * auto-download	172
-* back button	98
+* back button	97
 * Berners-Lee, Tim	15
 * browser history	97, 136
 * caching	39, 136
@@ -25,47 +24,46 @@
 * complexity	24
 * complexity budget	31
 * components	72, 74, 222
-* conditional rendering	136, 161
+* conditional rendering	135, 161
 * Contact.app 
 ** model 59
 ** specs 57
 * content negotiation	309-13
 * Content Security Policy (CSP)	193
 * CRUD	37, 57
-* CSS Transitions	149, 170
-* Data API, endpoint	314
-* debouncing	118
+* CSS Transitions	149, 169
+* Data APIs	229
+* debouncing	119
 * display: none	126
 * Document Object Model (DOM)	80
 * DOM, partial updates	83, 86
-* endpoints	68, 161, 234, 314
+* endpoints	161, 234, 314
 * event bubbling	92
-* event filters 
-** example	92
+* event filters
+** example	91
 ** security	193
 * event modifier, changed	120
 * event, change (see hx-trigger, change)	
 * event, keyup (see hx-trigger, keyup)	
 * event, click (see hx-trigger, click)	
-event, submit (see hx-trigger, submit)	
+* event, submit (see hx-trigger, submit)
 * events	90, 181, 189, 301
 ** debugging	190
 ** listeners	93, 182, 215, 302
-* factoring	72, 133, 277
+* factoring	72, 133, 278
 * Fetch API	21
-* Fielding, Roy	8, 16, 42-52, 228
+* Fielding, Roy	8, 16, 42-52, 227
 * Flash of Unstyled Content (FOUC)	104
-* Flask	55,
+* Flask	55
 ** decorators	55
 ** handlers	55, 58
-** redirect	57, 108
+** redirect	57, 108-109
 ** routes	55
 ** send_file()	169
-* for loop	134,
+* for loop	134
 * form tag, <form>	16, 18
-** in tables	
 * forms	94, 152
-* GET request	18 
+* GET request	17
 * HATEOAS	47, 279
 * HDA (see Hypermedia-Driven Application)	
 * Hotwire	84
@@ -74,10 +72,10 @@ event, submit (see hx-trigger, submit)
 ** <details>	155
 ** 2.0	16, 25
 ** history of	16
-** inputs	114, 137
+** inputs	113, 137
 ** opportunities	94
 * htmx	
-** about 83, 343
+** about 83
 ** browser history	97
 ** configuration	193
 ** debugging	190
@@ -106,27 +104,27 @@ event, submit (see hx-trigger, submit)
 **  boosting	102
 **  bulk delete	151
 **  click to load	122
-**  confirmation dialog	111
-**  delete	108
+**  confirmation dialog	111-112
+**  delete	107
 **  download archive	157
 **  infinite scroll	125
 **  inline delete	144
 **  inline validation	115, 118
-**  integration using events	226
-**  HX-Request	39
+**  integration using events	225
+**  HX-Request	39-40
 **  keyboard shortcut	93
 **  lazy loading	139
-**  pagination	120-122
+**  pagination	120-124
 **  request indicator	137, 143
 **  server-triggered events	189
 
 * htmx-indicator	138, 143
-* htmx-swapping	150
+* htmx-swapping	149
 
-* htmx attributes	85, 176
+* htmx attributes	85, 175
 ** attribute inheritance	104
 ** hx-boost	102-107
-*** disabling	173
+*** disabling	172
 ** hx-confirm	112, 152
 ** hx-delete	85, 90, 107, 145
 ** hx-disable	180, 193
@@ -135,7 +133,7 @@ event, submit (see hx-trigger, submit)
 ** hx-indicator	138, 143
 ** hx-patch	85
 ** hx-post	85
-** hx-preserve	179
+** hx-preserve	180
 ** hx-push-url	98, 111, 136, 179
 ** hx-put, about	85
 ** hx-select, example	124
@@ -149,16 +147,15 @@ event, submit (see hx-trigger, submit)
 ***  focus-scroll	176
 ***  innerHTML	88
 ***  none	89
-***  outerHTML	88, 124, 146
+***  outerHTML	88, 124, 147
 ***  scroll	176
 ***  settle	176
 ***  show	176
 ** hx-swap-oob	188
 ** hx-sync	180
-** hx-target 87, 110,129, 176	
+** hx-target 87, 110, 129, 176
 ** hx-trigger 90, 93, 177
 *** defaults	90, 177
-*** change	
 *** changed	120, 177
 *** consume	178
 *** delay	119, 128, 177
@@ -317,7 +314,7 @@ event, submit (see hx-trigger, submit)
 ** share	271
 ** styling	258
 ** swipe gesture	324-333
-** XML namespaces
+** XML namespaces 317-20
 
 * input values	153
 * Islands of interactivity	334
@@ -361,7 +358,7 @@ event, submit (see hx-trigger, submit)
 ** API	233
 ** constraints	42-58
 
-* RSJS guidelines	204
+* RSJS guidelines	205
 * scripting, hypermedia friendly	196
 * search	94
 * security	192