update TODO flags

book/CH08_TricksOfThehtmxMasters.adoc

@@ -54,7 +54,7 @@ In addition to these, `hx-swap` offers further control with the following modifi
 
 `settle`::
 Like `swap`, this allows you to apply a specific delay between when the content has been swapped into the DOM and when its attributes are "`settled`", that is, updated from their old values (if any) to their new values. 
-// check: This gives you fine control of css-transitions, for example.
+// TODO: check: This gives you fine control of css-transitions, for example.
 
 `show`::
 Allows you to specify an element that should be shown -- that is, scrolled into the viewport of the browser if necessary -- when a request is completed.
@@ -297,13 +297,13 @@ Consider the following
 scenario: your server-side team has decided that they want you to include a token for extra validation on every request.
 The token is going to be stored in `localStorage` in the browser, in the slot `special-token`.  The server-side team
 wants you to include this special token on every request made by htmx, as the `X-SPECIAL-TOKEN` header.
-// check: maybe, briefly show how to set the value in local storage
+// TODO: check: maybe, briefly show how to set the value in local storage
 How could you achieve this?  One way would be to catch the `htmx:configRequest` event and update the `detail.headers`
 object with this token from `localStorage`.
 
 In VanillaJS, it would look something like this:
 
-// check: In our Contact.app, for example, we would put this code... (where?) 
+// TODO: check: In our Contact.app, for example, we would put this code... (where?) 
 // Mention htmx helper for adding listeners like this? 
 .Adding the `X-SPECIAL-TOKEN` header
 [source,js]
@@ -316,15 +316,15 @@ document.body.addEventListener("htmx:configRequest", function(configEvent){
 
 As you can see, we add a new value to the `headers` property of the event's detail.  After the event handler executes,
 the `headers` property is read by htmx and used to construct the headers for an AJAX request.  
-// check: add basic info, is configEvent.detail.headers an htmx function? 
-// check: briefly explain what a header 'detail' refers to
+// TODO: check: add basic info, is configEvent.detail.headers an htmx function? 
+// TODO: check: briefly explain what a header 'detail' refers to
 So, with this bit of
 JavaScript code, we have added a new custom header to every AJAX request that htmx makes.  Slick!
-// check: explain the use case, something like 'this pattern of passing 
+// TODO: check: explain the use case, something like 'this pattern of passing 
 // and checking tokens is sometimes used for security' 
 You can also update the `parameters` property to change the parameters submitted by the request, change the target
 of the request, and so on.
-// check: an example parameter might be...
+// TODO: check: an example parameter might be...
 Full documentation for the `htmx:configRequest` event can be found
 https://htmx.org/events/#htmx:configRequest[on the htmx website].
 
@@ -397,7 +397,7 @@ a `POST` to the `/integrations/1` path, it will trigger a synchronization with t
 Now, this synchronization may or may not result in new contacts being created.  In the case where new contacts _are_
 created, we want to refresh our contacts table.  In the case where no contacts are created, we don't want to refresh
 the table.
-// check: show brief code, how to conditionally add HX-Trigger
+// TODO: check: show brief code, how to conditionally add HX-Trigger
 To implement this we could conditionally add an `HX-Trigger`
 response header with the value `contacts-updated`. This value would trigger the `contacts-updated` event on the button that
 made the AJAX request to `/integrations/1`.  We can then take advantage of the `from:` modifier of the `hx-trigger`

book/CH09_ScriptingInAHypermediaApplication.adoc

@@ -746,7 +746,7 @@ To get a flavor of AlpineJS, let's look at how to implement our counter example
 
 For the counter, the only state we need to keep track of is the current number, so let's declare a JavaScript object
 with one property, `count`, in an `x-data` attribute on the div for our counter:
-// check: removed class="counter" to avoid confusion
+// TODO: check: removed class="counter" to avoid confusion
 .Counter with Alpine, line 1
 [source,html]
 ----

book/CH10_JSONDataAPIs.adoc

@@ -96,7 +96,7 @@ By supporting both of these types of APIs separately you can get the strengths o
 styles of code and infrastructure needs cleanly split out.
 
 Let's contrast the needs of JSON APIs with Hypermedia APIs:
-// check: row spacing?
+// TODO: check: row spacing?
 [cols="a,a"]
 |===
 |JSON API Needs |Hypermedia API

book/CH11_HyperviewAMobileHypermedia.adoc

@@ -235,6 +235,9 @@ But as we will show at the end of this chapter, it doesn't take a lot of work to
 But before we get there, we need to introduce the concepts of elements and behaviors in Hyperview.
 Then, we'll re-build our contacts app in Hyperview.
 
+//TODO: consider advice to web developers wanting to go mobile
+// i.e., beyond the hypermedia concept, is this a path you recommend
+// when compared to alternatives? Avoid any sense of promotion
 
 == Introduction to HXML
 

book/CH12_BuildingAContactsAppWithHyperview.adoc

@@ -841,6 +841,7 @@ Luckily, there's a solution to this problem in Hyperview: events.
 Events are built into the behavior system, and allow lightweight communication between different parts of the UI.
 
 
+// TODO: consider an intro to events as 'html note' topic, earlier chapters
 .Event Behaviors
 ****
 Events are a client-side feature of Hyperview.
@@ -1116,7 +1117,7 @@ Any time you make a change in the HXML, just reload the screen to see the UI upd
 So we have the app running on a physical device, but it's still not production ready.
 To get the app into the hands of our users, there's a few things we need to do:
 
-// TODO: mention presentation here?
+// TODO: mention UI, presentation here?
 1. Deploy our backend in production.
 We need to use a production-grade web server like Gunicorn instead of the Flask development server.
 And we should run our app on a machine reachable on the Internet, most likely using a cloud provider like AWS or Heroku.

book/CH14_Conclusion.adoc

@@ -13,7 +13,7 @@ or a technology only appropriate for "`documents`" of links, text and pictures,
 building _applications_.  In this book you have seen how to build sophisticated user interfaces -- for both the web, with htmx,
 and for mobile applications, using Hyperview -- using hypermedia as a core underlying application technology.
 
-// check: edits
+// TODO: check: edits
 Many web developers view the links and forms of "`plain`" HTML as bygone tools
 from a less sophisticated age.  And, in some ways, they are right: there were definite usability issues with the
 original web. However, there are now JavaScript libraries that extend HTML by addressing its core limitations. Htmx, for example, allowed us to:
@@ -50,12 +50,12 @@ technology is going to change everything.  It tends to favor _sophistication_ ov
 _simplicity_.  People are scared to ask "`Is this too complex?`" because it sounds an awful lot like "`I'm not smart enough
 to understand this.`"
 
-// check: emphasize established, vs. old or past
+// TODO: check: emphasize established, vs. old or past
 The software industry tends, especially in web development, to lean far more towards innovating, rather than
 understanding existing technologies and building on them or within them.  We tend to look ahead for new, genius
 solutions, rather than looking to established ideas.  This is understandable: the technology world is necessarily
 a forward-looking industry.
-// check: refer back to Fielding? 
+// TODO: check: refer back to Fielding? 
 
 On the other hand -- as we saw with Roy Fielding's formulation of REST -- some early architects of the web had some great ideas which have been overlooked. We are old enough
 to have seen hypermedia come and go as the "`new new`" idea. It was a little shocking to us to see powerful ideas like REST discarded so cavalierly
@@ -64,12 +64,13 @@ by the industry. Fortunately, the concepts are still sitting there, waiting to b
 Perhaps, following Mark Twain's advice, it is time to pause and reflect.  Perhaps, for a few quiet moments, we can
 put the endless swirl of the "`new new`" aside, look back on where the web came from, and learn.
 
-// check: suggest this as the stronger concluding line
+// TODO: check: suggest this as the stronger concluding line
 Perhaps it's time to give hypermedia a chance.
 
 
 
 // TODO: check. Does this list accurately condense the work?
+// detract from the conclusion?
 [.design-note]
 .HTML Notes: Toward Effective HTML
 ****
@@ -79,7 +80,7 @@ Throughout the book we discuss a number of best practices for writing effective
 // TODO: maybe add. Aim for 'locality of behavior' in your markup, so that you or another developer can understand what each part of the page is doing just by looking at that part of the page.  
 * Make the full range of available tags part of your toolkit. 
 * Aim for good fit between tag specs and your use case; check the HTML specs when in doubt. 
-* When more specific tags don’t fit, it is usually better to step back to <div> than to use a tag incorrectly. 
+* When more specific tags don't fit, it is usually better to step back to <div> than to use a tag incorrectly. 
 * Stick with established libraries for UI interactions. If a use case requires an improvised solution, test carefully for keyboard interaction and accessibility.
 * Prefer components that extend HTML, rather than abstracting it away.
 * Test your HTML with screenreaders, with a keyboard, with different browsers and hardware, and run linters (while coding and/or in CI).