Fielding defined hypermedia controls as the mechanism by which a hypermedia system presents affordances to users, allowing the user to make choices and interact with that system [20]. He describes hypermedia controls (Fielding uses the term "action controls") as a defining technical characteristic of distributed hypermedia, with hypermedia controls being found "within" the presentation of information in that media [21]. 1

Hypermedia clients (in WWW terms, User Agents) in a hypermedia system present affordances [26, 44], visual or otherwise, based on this control information to users, giving the users mechanisms by which they can select interactions with or within the hypermedia.

In the absence of an extension mechanism [29], hypermedia controls must be agreed to in advance between hypermedia clients and hypermedia servers operating as a properly functioning hypermedia system [1]. Without this agreement, the uniform interface constraint of REST [21] cannot be satisfied. In particular, new and novel hypermedia controls presented by a hypermedia server cannot be effectively transformed into an interactive affordance by a hypermedia client.2

Extension mechanisms present within a hypermedia format and/or system do not remove the need for a shared understanding between clients and servers in that system, but they do allow for late binding of that understanding, as we will see later in the paper.

It is of note that, while this is the case for the client/server relationship, significant work has been done allowing the creation of user driven (or, to say, User Agent-enabled) hypermedia controls [49], retrofitting this functionality onto the WWW via the plugin/extension mechanisms available in many user agents [27].

Affordances [26] are context dependent elements found in an environment [15] that allow agents to "orient" themselves and take actions. Within the context of Hypermedia, affordances have come to mean aspects of the presentational layer (rendered or otherwise) of hypermedia clients (i.e. User Agents) that allow users to either perceive information (textual or otherwise) and potentially derive navigational and control actions within the hypermedia system [20]. An example of an affordance offered by the Chrome Web Browser is the transformation of the mouse pointer into a hand icon, when a user hovers over a hyperlink.

Transclusion [32, 34, 37, 38] is another fundamental concept in hypermedia systems. Nelson defines transclusion as "reuse with original context available, through embedded shared instancing" [43].

This original definition of the term has since been broadened [2] to encompass the general ability to include non-local content from disparate sources within a hypermedia document, with the concept of "original context" becoming less emphasized.

Nelson's definition of and thinking around transclusion often focuses on reuse and embedding of generalized content, along with the attendant copyright difficulties [30, 39, 40, 41, 42, 51].

While copyright was a major consideration early in the analysis of hypermedia systems and still remains an ongoing concern in practice, this paper will utilize the concept of transclusion in a manner that diminishes these concerns. In our analysis we will limit transclusion to a same-origin transclusion[8] of content.

Same-origin transclusional content is content that is retrieved from the same origin (as expressed by the host representation [55] of URLs, for example) as the trancluding content. By narrowing transclusion to this more limited sense, we partially avoid the broader copyright concerns Nelson often dealt with.3

We note that this more limited notion of transclusion in hypermedia is not novel: the use of so-called "relative" URLs is common practice in HTML authoring on the WWW, with image elements, for example. Even with this more constrained notion of the term, we will see that providing a generalized mechanism for transclusion significantly increases the expressiveness of hypermedia in a hypermedia system.

HTML, an extension of SGML, is the most widely deployed hypertext in the world. [17], by virtue of it being the core format of the WWW. As hypermedia, HTML offers authors numerous hypermedia controls. Examples are anchors (also referred to as links), forms, image elements and iframes. In HTML control information (e.g. forms) is admixed by authors directly within the presentation information at the source level, in the form of embedded markup.

Hypermedia controls form a fundamental part of the uniform interface constraint of the REST network architecture [21], serving as the primary mechanism by which the REST network architecture style decouples client and server from one another [1].

Anchor elements [36] in HTML implement the ur-hypermedia control, the "hyperlink", as described by Nelson [43], following Bush [14], and first implemented in a practical sense by Englebart's NLS system [19]. Anchor elements allow for hyperlinking between HTML documents. This is accomplished via the href (hypertext reference [10]) attribute, which can provide a Universal Resource Locator (URL) reference, absolute or relative, to another resource found elsewhere on the network.

Following Amundsen's Hypermedia Factors (H-Factors) analysis [2], anchor elements satisfy the Outbound Link (LO) factor for HTML, a fundamental factor of distributed hypermedia systems.

Consider a simple anchor element defined in HTML:

[mathematical notation rendered in Formal Notation below]

A complete characterization of this anchor as interpreted and rendered by a WWW User Agent requires that we describe both the appearance, behaviors and affordances of this anchor. A typical User Agent would present such an anchor tag with the following behaviors and characteristics:

The text "An Example Website" will be rendered to the user of the user agent with some affordance (e.g. underlining and highlighting the text) indicating that the text is clickable

When a user clicks on the text:

The user agent will issue a HyperText Transfer Protocol (HTTP) GET request

The request will be issued to the URL specified in the href attribute

The HTML in the body of the HTTP response will then be placed in the user agents viewport, replacing the current document

Our functional description of hypermedia controls will use the last four characteristics in this list, as they present the fundamental primitives from which we can successfully build a general definition.

These four primitives can be classified as:

event trigger

request issuance

resource location

response placement

We define these four primitives, joined together, as the hypermedia control mechanic: the core functional primitives found in hypermedia controls that tie the class of hypermedia control elements together. 4

Note that we omit the first attribute of the list, the visual affordance of the link, from our list of primitives. Excluding this attribute may seem surprising given that the clickable hyperlink is perhaps the most iconic aspect of the WWW. However, we note that this "clickable" affordance is a contingent rather than an essential attribute of anchor tags. The visual affordance of the link is determined contextually: a screen-reader User Agent, for example, may present a significantly different affordance for a different user. Further, HTML allows authors to style links in other ways via Cascading Style Sheets (CSS) [33]. This mutability is in contrast with the hypermedia control mechanic we have outlined, which remains consistent regardless of the appearance of they hyperlink.

This is not to say that the affordances, visual and otherwise, are an unimportant aspect of hypermedia controls: they are crucial in presenting actions to users to select. It is rather to say that, as mutable and context-sensitive component of hypermedia controls, they form a divergent and broad class of phenomena that do not fit cleanly into the functional definition of hypermedia controls we are developing.

Form elements, introduced in HTML2 [9], are significantly more complex hypermedia controls than anchor elements. In contrast to anchors, form elements allow other elements defined within them (i.e. input elements) to modify the information transmitted by a network request that they issue. Form tags give HTML authors control to define not only the URL but also the HTTP action to use for a request, using the action and method attributes.

Form elements provide the following H-Factors within HTML: Templated Links (via the inclusion of input values when combined with a GET request), Non-Idempotent Links (via use of a POST method), Update Controls (via the use of the enctype attribute) and Method Controls (via the method attribute). They are the primary mechanism by which the WWW was transformed from a read-only hypermedia system into a read/write hypermedia system. Thus they are the key element in transforming the WWW into a hypermedia system with which distributed applications could be built.

Let's consider how a form element in HTML will be interpreted and presented to a user by a typical User Agent. What follows is a simple HTML form, consisting of a single text input element with an attendant label and a submit input:

[mathematical notation rendered in Formal Notation below]

Here we see the admixture of control and presentation logic described by Fielding [21] in sharp relief. A typical User Agent would present this form tag to an end user in the following way:

The text "Email:" would be presented with an email input next to it. A button-like element with the text "Submit" in it would be presented next to it. (A visual affordance.)

When a user clicks on the ’Submit’ button or hits enter while in the email input

The user agent will issue an HTTP POST, as specified by the method attribute

The request will be issued to the URL specified by the action attribute

The HTML in the body of the HTTP response will then be placed in the user agents viewport, replacing the current document5

Note that in our description we have left aside details regarding the inclusion of input values in the generated HTTP request. This simplifies our comparison of the form element with other hypermedia elements that do not have as complex a relationship with other elements in an HTML document.

Here again we see the primitives of the hypermedia control mechanic in the last four elements of our description: event trigger, request issuance, resource location and response placement. In the case of form elements, the event is form submission (i.e. submit) rather than a click. Form elements, in contrast with anchor elements, also provide a mechanism for choosing a particular HTTP method, in this case POST. With respect to the handling of response content, as in the case of the anchor tag, the response HTML document replaces the entire viewport.

Image elements allow HTML authors to embed media images inline within an HTML document, via a src attribute that specifies the URL of image content. It may seem strange to refer to image elements in the same breath as anchor and form elements, because they are not, on their own, interactive elements in HTML in the manner described by Fielding [20]: users do not select options by manipulating them directly.6 However, upon analysis, you will see that they do fit well within the conceptual model that we are developing.

In H-Factor terms, image elements provide an "Embedded Links" Factor in HTML, offering a transclusional affordance [2]: they include remote image content inline and transclusionally, within an existing HTML document. Note that in providing the ability to embed non-textual images within an textual HTML document, images transform the WWW from a hypertext system into a more general hypermedia system.

To see how image elements fit within the hypermedia mechanic consider a simple image tag in HTML that uses a relative URL:

[mathematical notation rendered in Formal Notation below]

This image element would be presented by a standard User Agent in the following manner:

No initial affordance will be made for the image content

When the image element loads

The user agent will issue an HTTP GET request

The request will be issued to the URL specified in the src attribute

The image content of HTTP response will then be transcluded (i.e. inserted) into the documents rendered state at the point that the image tag is defined

Here again we see that, despite at first appearing to be categorically different than anchor and form elements, image elements fit cleanly within our hypermedia control mechanic. The event, in this case, is not triggered by user selection of an action but rather is an event that occurs implicitly during the loading of a web page.

It is important to note that, when we say that the "load" event causes the HTTP request above, we are not referring to either the load or DOMContentLoaded JavaScript events. We are, rather, referring to the broader handling of parsing of HTML and the implied resource loading done by web browsers. Thus, a "load" event here is used in the broad sense.

Another important aspect of this example is that we see the first example of a hypermedia control performing transclusion: rather than replacing the entire viewport of the user agent, as is the case with anchor and form elements, the image control includes additional hypermedia content within the current document. Note that, while the image tag updates the render state of the hypermedia document, it does not cause a structural change to the document itself: no new elements are added to the documents internal structure.

The final hypermedia control we will examine is the iframe element. iframe elements allow the embedding of separate HTML documents within an existing HTML document and, thus, are examples of a transclusional hypermedia control, akin to images.

Like image elements, iframes refer to the content to be transcluded into the existing document via a src attribute. However, they differ from image elements in that they include additional hypermedia content within themselves, rather than non-hypermedia content. Despite being an attractive implementation of transclusion in HTML, iframes have fallen into relative disuse among modern web authors [48].

Iframe elements blend various behaviors of the three preceding hypermedia controls in an interesting and suggestive way. Consider the following iframe:

[mathematical notation rendered in Formal Notation below]

A typical User Agent would present this iframe in the following way:

An initial box of the given dimensions (300 by 200 pixels) would be rendered to the screen

When the iframe loads

The user agent will issue an HTTP GET request

The request will be issued to the URL specified in the src attribute

The HTML of HTTP response will then be transcluded (i.e. inserted) into the iframe element as a new sub-document within the iframe element and then rendered

We can see that the iframe element mixes elements of anchor tags and forms (the insertion of new HTML content) with the behavior of images (transclusion within an existing document.) The transclusion here is in a different form than what we saw with image elements: new hypermedia content has been added to the existing document. This mechanism is much closer to the notion of transclusion Nelson described and is significantly more general that the image element in that iframes provide all the expressive power attendant in the underlying hypermedia.

Once again we can see that the last four elements in this description of iframes fit well within the hypermedia mechanic concept that we established earlier.

With this definition of hypermedia controls established, we can now formalize this definition of hypermedia controls in a distributed hypermedia system.

Table 1: Definition of notation.

Our initial definition for a distributed hypermedia system $S = (mathcal {F}, P, C)$ where: $mathcal {F}$ is a set of data formats supported by the system; P is a network protocol for the system; C is a hypermedia client for the system; and SER is a hypermedia server for the system.

Here, network exchanges occur between C and SER via a network protocol P which encodes responses from SER to C in some format $F in mathcal {F}$.

With this definition of a hypermedia system established, lets consider the rendered state of a client C, called UX. Let $mathcal {H} subseteq mathcal {F}$ be the hypermedia formats supported by S. Let $H in mathcal {H}$ be an individual hypermedia format supported by S; Let DH be a hypermedia document conforming to H; Let $mathsf {R}(cdot) : D_{F} rightarrow mathit {UI}$ be a render function implemented by C presenting the content of some data in format F as the user perceived interface UI.

Let UX = (DH, R(DH)) be a composite of both a hypermedia document DH and its rendered state R(DH). Define $mathsf {HE}(cdot): (mathit {C}, P, mathit {SER}) rightarrow M_F$, as network hypermedia exchange between client C in S and server SER in S via P, the network protocol in S. Let MF be some media conforming format $F in mathcal {F}$ returned by SER to C. Let $mathsf {UP}(cdot) : (mathit {UX}, M, mathit {DI}) rightarrow mathit {UX}^{prime }$ be an update function implemented by C. Finally, let DI be a disposition specifying how the client should update the current UX with a response in the format of M.

Note particularly the inclusion of the element UX in the above definition, as a composite of both a hypermedia document DH and the rendered output of [mathematical notation rendered in Formal Notation below] . This is a necessary component of our general definition due to the nature of hypermedia controls such as image tags, which issue requests to SER from C but do not update DH in any structural manner, rather they include non-hypermedia content transclusionally in the rendered state of the document. Hence DH remains unaltered whereas R(DH) → R(DH)′, giving UX′. Iframe elements, in contrast, update DH to D′H and thus also the rendered state, which becomes R(D′H). Further, anchor and form elements that do not target an iframe or new viewport have a replacement disposition that replaces the current hypermedia document DH entirely with a new document of format $F in mathcal {F}$, DF.

The update function $mathsf {UP}(cdot)$ provides the mapping from the original UX state of client C to a new state, UX′ (which may involve a UI′, D′H or DF). The dispositional argument here captures the fact noted above that this update may be transclusional, transclusional with structural updates, replacement, or some other form (e.g. "download"). The dispositional options are derived from affordances found in H, functionality found in C, meta-data found in P, etc. As such update disposition is a separate concern from the render function R, which is solely responsible for rendering a hypermedia documents state once some sort of update has occurred.

Note also that $mathsf {HE}(cdot)$, hypermedia exchange, here should not be limited to response formats that are themselves hypermedia; they may be any $mathit {F in mathcal {F}}$. Image elements, for example, trigger requests whose responses consist of some image format that itself may not be a hypermedia. What is necessary for a given network request to be a hypermedia exchange is that it satisfies the uniform interface, as defined by Fielding [21]. In particular, within the uniform interface constraint the request must use hypermedia as the engine of application state and be "self-describing" (in terms of network relations). Non-hypermedia response formats satisfy this constraint so long as they do not carry along information that must be transformed into network relations via out-of-band information.

With these definitions established and clarified, we are in a position to give a formal definition of the term "hypermedia control":

Let $mathcal {ELT}_H$ be the set of all elements defined by $H in mathcal {H}$ and let $mathcal {EVT}_{C}$ be the set of events afforded by C. A hypermedia control is defined as an element $mathit {ELT} in mathcal {ELT}_H$ where there exists some event $mathit {EVT} in mathcal {EVT}_C$ such that an instance of EVT triggered on an instance of ELT ∈ DH, then C updates UX by way of $mathsf {UP}(mathit {UX}, mathsf {HE}(C, P, mathit {SER}), mathit {DI})$.

So a hypermedia control (again, from a functional standpoint) is an element found in a hypermedia document that initiates a hypermedia exchange by a hypermedia client in response to some event, thereby updating the client state UX in some manner (i.e. with some disposition).

With this formal definition of hypermedia controls we are now in a position to generalize the concept. In order to make things clear we will discuss this generalization in the context of HTML and the WWW, but we will see that it can be applied in other hypermedia systems as well. Referring to our formal definition we have S as the WWW, and P as HTTP, H as HTML, with C being a conforming web browser.

4.2.1 Event Trigger. For each of the hypermedia controls we looked at, the first element of the hypermedia control mechanic involved a type of event triggering a network request. In the case of anchor elements, this is the click event. In the case of form elements, it is the submit event7 and in the case of image and iframe elements it is the load event.

As hypermedia clients, web browsers trigger a significant number of events [35] beyond these. keyup and mousemove are two events that are triggered by user actions, for example, that are often used by HTML authors to produce more interactive web pages, typically by resorting to scripting of some sort.

The first step, therefore, in generalizing the hypermedia control mechanic would be to allow any of these events to trigger a hypermedia exchange. That is, expand the set of events that can trigger the hypermedia mechanic to be all of EVTC.

Unfortunately, none of the HTML elements that we looked at have attributes that hint at an implementation for this generalization: in the case of all four of the elements the events driving network requests are implicitly specified by the element type itself.

4.2.2 Request Issuance. The next step in generalizing the hypermedia control mechanic is to consider the form of the $mathsf {HE}(cdot)$ (hypermedia exchange) conforming to P, that is, the form of HTTP request being issued (the form of the response is dictated by P and the remote server.) Note that in the case of anchor and image tags HTML authors have no control over the form of HTTP request: the request will always be a GET. In the case of forms, however, HTML authors can use the method attribute to select either a GET or POST, satisfying the Method Controls factor.

It is worth noting that other methods are available in the HTTP protocol : PUT, PATCH and DELETE for example. Amundsen notes in his analysis of HTML that it is missing the "Idempotent Writes" H-factor by omitting support for PUT requests from its set of hypermedia controls. It is somewhat surprising that this functionality has never been added to HTML.

For this primitive of the hypermedia control mechanic, the form tag's method attribute shows us a mechanism for generalization: we can allow hypermedia controls to specify which HTTP method to use via an attribute. We can, further, extend beyond what the form element's method attribute offers and allow the specification of any valid HTTP method, including PUT, PATCH and DELETE requests, by HTML authors.

4.2.3 Resource Location. Anchor, form, image and iframe elements all allow user agent events to issue HTTP requests to a particular URL. This is done via a varying set of attributes: the anchor element uses the href attribute [10], the form element uses the action attribute, while the image and iframe elements use the src attribute.

It is by these various attributes that these particular elements of HTML become hypermedia controls at the most primitive level. Without the ability to specify a remote resource to interact with the concept of hypermedia controls in HTML becomes unintelligible.

In order to generalize this aspect of hypermedia controls, we can expand the set of all elements in ELTH, by extending this ability to specify a remote resource to interact with via URL to any element in HTML (again, as our H).

4.2.4 Response Placement. The final step in generalizing the hypermedia mechanic is making the disposition DI of the update caused by $mathsf {HE}(cdot)$ generally configurable by HTML authors. A solution to this is suggested by the image and iframe tag and hinges on the idea of transclusion: the possibility of not replacing the entire viewport of a user agent with a new hypermedia document (or non-hypermedia content) but rather to offer transclusive update possibilities.

The iframe element, in particular, hints at how to generalize this primitive: iframes can be the target of anchor and form elements. This is accomplished by using the name attribute on an iframe element to give the frame a unique identifier and then using the target attribute on the anchor or form elements to target a particular iframe. In this configuration, an anchor or form element will not replace the entire viewport with the response document, but rather insert it into the targeted iframe

Here is an example of an iframe that is targeted by an anchor tag:

[mathematical notation rendered in Formal Notation below]

When this anchor element is clicked, an HTTP GET request will be issued to the URL specified in the href attribute of the anchor and the response content will be loaded into the iframe element, rather than into the viewport of the user agent.

This is an extremely suggestive feature of HTML, allowing authors some control over the dispositional nature of the update that occurs, but it is also structurally limited: the target must be a fixed area and the content returned from the target URL must be a complete HTML document. Further, the content within the iframe element is sand-boxed from the enclosing content, making integration via standard mechanisms such as event propagation and form participation difficult or impossible. Due to these limitations HTML authors have not embraced these features widely and, today, they are considered antiquated by many developers [48].

Attempts have been made to introduce a more general notion of transclusion in HTML. Pam [45] suggested using the idea of character ranges for the transclusion of textual data within an existing document, following the src attribute of image and embed tags, coupled with an optional range specification. This proposal has not been adopted into HTML as of this writing. Kolbitsch and Maurer created tag-based mechanism for textual transclusion within HTML [34].

As an alternative to these ideas and implementations, we propose the concept of partially structured hypermedia transclusion. Rather than transferring entire HTML documents, ranges of characters, complete image files, etc. partially structured hypermedia is made up of fragments of media that, by themselves, may not form complete or legal documents.

Partial structures within the context of HTML have been explored [31, 50], but in extractive terms rather than as a potential format for hypermedia exchanges.

Complementing this idea of partially structured hypermedia in HTML we also propose allowing fine-grained control over the transclusion of response content within the current document. This mechanism should be more flexible than the current inline img mechanism and the static-area iframe mechanisms for transclusion. To maximum the flexibility of transclusion within HTML we need to allow hypermedia controls to specify two distinct aspects of the placement of new content: where to place content within the document and how to place the content relative to that location.

For the first aspect of general transclusion, we can build on suggestive functionality already found in anchor and form elements, where the target attribute allows an anchor to target an iframe element. Generalizing this feature would involve allowing hypermedia controls to target any element in a document, rather than only named iframe and frame elements.

To overcome the inflexibility of the name attribute based targeting found in these elements, we suggest using a more general selection mechanism already found in HTML via CSS: CSS selectors.

CSS Selectors are a generalized query language available in modern browsers that can be used to apply styles to elements in a declarative manner. By adopting CSS Selectors for specifying targets, we adopt an existing standard familiar to HTML authors that is expressive enough to target nearly [24] any element within a document.

For the second aspect of general transclusion, we propose allowing hypermedia controls specify exactly the how to swap the hypermedia content relative to the target element. Placement options such as inserting the content within the element (as in the case of iframe elements) should be possible, as well as more exotic options such as appending the content to the children of the target element, or even replacing the target element entirely.

These two concepts, giving hypermedia controls the ability to specify where and how transcluded content is integrated into an existing document, complete our generalization of the functional hypermedia definition provided in Section 4.

By increasing the expressiveness of HTML qua hypermedia, generalized hypermedia controls allow HTML authors to access a much richer set of interactive experiences than has been traditionally available to them directly in HTML.

In this section we will examine two of these patterns, along with their implementation using htmx:

Infinite Scroll

Active Search

Infinite scroll is a popular UI pattern in which a list of items loads more content as the user reaches the bottom of the current list of elements. This list can be a list of search results, a list of social media posts, and so forth.

Implementing this pattern as a hypermedia control requires the following behavior:

When the final element (the control) in this list becomes visible (the event) on the screen, issue a GET (the method) request to retrieve the content for the next set of elements and append (the disposition of the transclusion) it to the list (the target of the transclusion).

This pattern can be implemented in htmx in the following manner:

[mathematical notation rendered in Formal Notation below]

Here we use the revealed event to trigger a request. When this element, located at the end of the list, is revealed in the viewport, an HTTP GET request will be issued.

The hx-get attribute in this case instructs htmx to issue a GET HTTP request to the relative URL /page/2, to produce the second "page" or collection of elements to be added to the parent list. Note that, by virtue of using a relative URL, this is a same-origin request. Here an HTML author is using transclusion not for its referential features but rather for it's functional abilities.

The hx-target in this case specifies the CSS selector #list, which references the element with the id list. This is the parent ul tag of the list.

While hx-target specifies where to include the new content, the hx-swap attribute controls the disposition of the transclusion, that is, how the retrieved hypermedia content will be included in the document. In this case, the attributes specifies that the content should be swapped at the end of the target, but within it (rather than after it) via the beforeend value.

An important aspect of this pattern is that the response HTML will not be a complete HTML document. Rather it will be a partially structured HTML response, containing only the HTML content necessary to display the next set of elements in the list. In this case, given that the parent element is an unordered list (ul) element, we would expect the response content to contain a list of list item (li) elements:

[mathematical notation rendered in Formal Notation below]

Note that, in the new partially structured response, another li is included that acts as a hypermedia control and that it is configured such that, when that new, final element is revealed, yet another HTTP request will be issued, retrieving the next set of elements to the list. It is this pattern of successively triggered hypermedia controls that allows the scroll to become "infinite".

The pattern can be repeated until a final set of elements (if such a set exists) is reached, at which point this hypermedia control will be omitted from the response content, thereby ending the retrieval of new content.

Here we see that via four attributes we can implement the infinite scroll pattern using htmx, demonstrating the expressive power of the generalization it provides.

Figure 1: Infinite Scroll

The second UI pattern we can implement using htmx is "Active Search". Active Search is a UI pattern where, as a user types into a search box, the results of their search are shown in near real time in some other area on the page.

This pattern was made famous by Google, who adopted it for their web search UI in 2010 under the name "Instant Search" [28], introducing this sort of user experience to the broader internet.

Implementing the Active Search pattern as a hypermedia control requires adding the following functionality to an input element that is capable of accepting text via keyboard entry:

When a keyup (the event) occurs in the element (the control), issue a GET (the method) request to retrieve the relevant search result content and insert it into the search results section (the target) of the document.

This is a much more sophisticated hypermedia control that we saw in the infinite scroll example. However, implementing exactly such a hypermedia control via htmx requires only three attributes, hx-get, hx-trigger and hx-target, placed on a standard input element of type search:

[mathematical notation rendered in Formal Notation below]

The hx-trigger attribute is set to the keyup event. The trigger specification contains a trigger modifier for this event: delay:500ms. This modifier tells htmx to delay the request and only issue it if no other keyup occurs within 500 milliseconds. This debounces [23] the requests made by this hypermedia control, so that the server is not swamped with search requests as the user types.

The hx-get attribute instructs htmx to issue a GET request to the relative URL /search. Again, we have a same-site request that is being issued. The value of the input will be included in the GET request as a request parameter (this is an example of the "Templated Link" H-Factor) allowing the server side implementation to return search results matching the current value of the input element.

Finally, the hx-target attribute tells htmx to place any search results found in the element with the id search-results, which is a div located just below the input.

With these attributes in place, as a user types into this search input and pauses, a search request will be issued to the /search URL and the results of the search, in hypermedia form, will be placed in the div below the input. If the user continues typing after results have been retrieved, the results will again be updated.

The implementation of this UI pattern using three attributes, each readily understandable by HTML authors, again demonstrates the expressive power of the generalization htmx provides.

Figure 2: Active Search

As Hyperview is a new hypermedia system for mobile, all interactive patterns in it are, in some sense, novel. Hyperview equivalents of the UI patterns we demonstrated in htmx above all exist and look, to a first order of approximation, similar to the htmx implementations.

However, in order to showcase the mobile-specific nature of Hypreview, let's look at how to add a common mobile feature, the "pull-to-refresh" action, to the list of items we presented above.

[mathematical notation rendered in Formal Notation below]

Here we have added three attributes to the list element:

trigger - set to the event refresh, triggered by the Hypreview client when a pull-to-refresh action occurs

href - set to the URL of the remote resource to interact with

action - set to replace, so the response content will replace the existing element

Note that since no target is specified the list element itself will be the target of the interaction. Note also that, in the absence of a verb attribute, the HTTP request will be a GET.

With these three declarative attributes an HXML author can add the common pull-to-refresh user experience to an HXML-based mobile application, allowing the user to pull the list down and retrieve new elements added to the list on the server. This is done entirely in terms of generalized hypermedia controls we described earlier, as a derivation from our definition of hypemedia controls.

This example demonstrates that the generalization we presented in Section 4.2 has wider application beyond the context of the WWW and suggests that if it is adopted by other hypermedia systems it could provide increased creative possibilities for hypermedia authors within those systems.