Pages on the WWW are created via the HyperText Markup Language (HTML), a hypertext derived from Standard Generalized Markup Language (SGML) 7. The two most significant hypermedia controls in HTML are anchor tags, which implement the defining hyperlink mechanic 32 of the WWW, and forms, which transformed the WWW from a read-only hypermedia system into a read/write medium in which what today are called web applications can be built.

These two hypermedia controls are also the only significant user-interactive hypermedia controls available in HTML. Hyperlink anchors have been part of HTML since its inception, and the form element was added to the HTML 2.0 specification, which was published in 1995 28. Since then, no additional elements have been added to HTML that allow WWW users to obtain choices and select actions in terms of hypermedia interactions. Anchor and form elements comprised the core implementation of the uniform interface constraint outlined by Fielding in 2000, and they still do so today 9.

The core network protocol of the WWW is the HyperText Transfer Protocol (HTTP), a stateless, application-level, text-based protocol for transferring HTML documents and other content [12, 17, 23]. HTTP requests can be driven by user selections of actions, via hypermedia controls, or by non-interactive hypermedia controls such as image elements.

The primary semantics of an HTTP request are its target and method 11. Each request targets a resource on a server, identified by a Uniform Resource Locator (URL), and includes a method that describes the request’s intent with respect to that resource. For instance, a GET-method request simply asks the server to provide the client with the resource that can be found at that URL.

HTTP requests also provide a simple text-based name-value pair mechanism for transmitting metadata about an HTTP request. These are called headers, and they are included after the start-line of the request.

Listing 1 shows an HTTP request that would be issued to retrieve the index.html document from the server www.example.com.

In addition to GET, the HTTP 1.1 specification defines a number of other methods. Of those methods, GET, POST, PUT, and DELETE are frequently used by developers in web applications 2. The PATCH method, added later via an extension proposal 8, is also sometimes used. In broad terms, GET is used for information retrieval, and POST, PUT, PATCH and DELETE are used for updating resources.[Note ^2^]

In order to describe how the resource is to be modified, POST, PUT, and PATCH requests typically contain a request body. These bodies contain arbitrary data that the client provides along with the request. Although GET and DELETE are also capable of sending content in the request body, those semantics are left deliberately undefined, and doing so is generally discouraged. Instead, GET requests typically encode user-generated content as URL query parameters.

Listing 2 shows a basic POST request to the /signup relative URL. Note that the request includes form data—the user’s email—which is required to fulfill its purpose—signing that email for up for the service.

HTTP methods can additionally be classified by two primary characteristics: whether or not the method is safe, and whether or not it is idempotent.

Methods that are safe should not produce any side-effects on the server. By denoting methods this way, server authors indicate that this resource may be fetched relatively freely—whether by user action, browser optimization, or automated web crawler. While servers may generate side-effects based on safe requests, clients that send safe requests are not to be held responsible for those side effects. The GET and HEAD methods are safe.

Methods are considered idempotent if the effect of N > 0 requests to a given URL has the same effect as a single request to that URL. PUT, which replaces the resource at the URL with the contents of the request body, is idempotent, because multiple PUT requests would just keep replacing the resource with an identical one; POST, which can be used to create a new resource, is not idempotent, because multiple POST requests might create multiple resources.

Table 1. HTTP methods and their properties.

A surprising limitation of HTML is that, without additional enhancement via scripting, it is not possible to issue PUT, PATCH or DELETE requests. This is demonstrated in Table 1, which denotes the properties of a couple HTTP methods which are relevant to this paper. Note that in addition to the semantic limitations of the HTML-available HTTP methods—a POST describes a very different resource mutation than a DELETE—there are technical limitations as well: it is currently impossible for HTML authors to describe an unsafe, idempotent operation in hypermedia-based web applications.

In order to participate in the WWW, a server must implement the HTTP protocol, accepting HTTP requests and responding with HTTP responses. Hypermedia servers for the WWW are numerous [10, 20, 21, 34]; many programming languages have web server functionality directly integrated into the core library [14, 15, 27]. The large number of such servers indicates relative simplicity of such software, likely an important contributing factor to the growth of the WWW as a hypermedia system.

Web browsers are the hypermedia clients for the WWW. As a hypermedia client, they implement the crucial functionality of interpreting and displaying hypermedia content for a user with a rich visual user experience, such as displaying clickable links, submit-able forms, etc.

With the deprecation and retirement of Internet Explorer, there are now three major browser engines: WebKit (Safari), Gecko (Firefox), and Chromium (Chrome) [4, 24].

The simplest, and most important, of the Triptych proposals is the addition of PUT, PATCH, and DELETE support to the HTML form element. Triptych’s approach is to extend the existing method attribute, which currently only supports GET and POST, with three new possible values: PUT, PATCH, and DELETE.

Listing 3 shows a simple sign-up form, which uses the PUT method.

Variations on this feature have been proposed many times [3, 19, 25]. Triptych’s proposal is mostly similar, but strictly limited in scope to just these three methods; this simplifies adoption of the change for browser vendors and increases the likelihood of the proposal being accepted.

Adding additional methods to HTTP forms is hampered by an unfortunate aspect of the HTML spec: if a browser does not recognize the value of the method attribute, it will default to a GET method. As discussed in Section 2.2, GET-method requests typically encode user-generated content as URL query parameters, while POST-method forms add them to the request body. HTML forms follow this pattern, so a form that makes an unintentional GET request exposes its contents to the URL, potentially leaking sensitive data.[Note ^4^]

Even if support for additional HTTP methods were to be immediately available in browsers, this security concern would inhibit its adoption on the WWW. Web servers would need to ensure a web browser supports this HTML feature before utilizing it, otherwise the unrecognized method would result in GET requests being sent for PUT-method forms, possibly leaking sensitive data to the URL.

To resolve this, Triptych includes a fallback mechanism. An additional attribute, custommethod, can be specified to override the value of the method attribute, as seen in Listing 4.

This pattern introduces a novel form of progressive enhancement to HTML. Progressive enhancement typically refers to additional, non-essential functionality that is layered on top of the hypermedia with scripting; the website still functions properly without scripting, but the additional functionality enhances the experience when available. In this case, however, progressive enhancement occurs based on whether the hypermedia itself recognizes certain novel features.

Using the custommethod attribute, web applications can immediately start taking advantage of the idempotency semantics of PUT where available, but fall back to POST on clients where the custommethod attribute is not recognized. The server supports this by simply handling the /signup URL identically for both PUT and POST methods.

In this manner, Triptych is able to enhance HTML semantics while remaining infinitely backwards-compatible with old clients, fulfilling the mandate to “degrade gracefully” 29. Once an application developer determines that PUT-method support is sufficiently widespread for their use-case, they can dispense with custommethod altogether.

The custommethod attribute is also forwards-compatible with full support for custom HTTP methods. The HTTP specification permits servers to define and use their own non-standard methods—functionality that has previously been proposed for HTML 19. In order to limit scope, Triptych itself does not propose the ability to use non-standard HTTP methods in the form, but it is designed to make that feature easier to add in the future.

The second Triptych proposal expands the functionality of HTML buttons, enabling them to make network calls independent of a form element or script execution. It simply adds the action and method attributes from the form element to the button element.

To illustrate the value of this feature, consider the hypermedia controls involved in basic web authentication, one of the most common patterns in web applications. Listing 5 shows how one might implement a traditional authentication form, with an email and password.

Note the HTTP semantics described by the form’s attributes: the user “logs in” to the website by creating (method="POST") a session resource (action="/session"). As shown in Listing 6, with Triptych, HTML is able to simply and concisely model “logging out” as well.

Unlike logging in, which relies on form data to verify the user’s identity, logging out can be described entirely using HTTP semantics: delete this session. No form body is necessary. By adding additional HTTP methods and making them available to the button directly, Triptych makes it possible to specify that interaction declaratively.

Although this pattern is ubiquitous on the WWW, it cannot be accomplished with existing HTML controls. The closest analogue, shown in Listing 7, requires the author to wrap the button in a superfluous form and issue a POST request to a related resource.

This pattern does work, but it obscures the intended hypermedia semantics in two important ways.

First, because the only unsafe method available to HTML is POST, the session must be deleted by referencing a different URL than the one used to create it. This eliminates the concept of a single resource from the URL entirely, which can have negative downstream effects on the application’s coherence. For instance, many server frameworks support file-based routing, in which the function that handles a particular URL route can be found at a corresponding file path in the server code. When sessions can be managed at the same URL, the authentication code can be co-located within the same file, making it easier to find, modify, and encapsulate that functionality.

Second, the parent form serves no purpose other than to allow its child button to make an HTTP request; the logout button straightforwardly does not have any form data. The unnecessarily verbose interface likely leads many developers to conclude that HTML is simply insufficient to describe even the most common interactive application functionality, and they often opt for scripted alternatives which do not introduce unnecessary semantic overhead.

Button actions also enable richer form controls. Consider a basic job application form as depicted in Listing 8. In this example, submitting the form with the unadorned “Submit” button will issue a POST request to the /apply route. Clicking the “Cancel” button, however, will ignore the parent form’s attributes and inputs; instead, it will make use of the button’s own attributes, which specify both a different URL and HTTP method. Unlike the logout flow, which can reasonably be achieved using a form wrapper, this pattern is extremely difficult to accomplish with standard HTML, because forms cannot contain other forms.

Once again, Triptych engages with the existing HTML terminology to make its new features as intuitive and unobtrusive as possible. It re-uses the action and method attributes from the form element, to preserve existing semantics. Servers can also progressively enhance their buttons by wrapping them in a form; clients that support the feature will see that the button has an action and ignore the parent form.

The final Triptych proposal dramatically expands the possibilities of what HTML can accomplish with the hypermedia response, by providing the ability to specify page replacement targets without performing full page navigations [6, 22].

Page navigation is an essential paradigm on the WWW, but it carries a lot of conceptual baggage. Almost every network request that can be specified by HTML results in a page navigation—both links and forms perform one by default. Page navigation creates a browser history entry, impacts back button behavior, and, semantically, asks the user to understand the new page as a new location.

Although navigation is the correct way to model the basic structure of a website, there are many hypermedia interactions that require network requests but should not alter the current resource location. While such interactions are already possible through scripting, Triptych makes it possible to model them declaratively. This is done by extending the target attribute of links and forms to accept arbitrary CSS selectors, along with a handful of additional keywords.

Listing 9 shows a button that might be available in an online chatroom. This button locks Room #123, the room currently being viewed by the user, so that no newcomers are able to join. This action is modeled in HTTP as a PUT request to the /rooms/123/lock endpoint, and the button indicates that the contents of the HTTP response should replace it on the page, using the _this keyword as a parameter for target. This mirrors the style of existing target values, like _blank and _parent 33.

When the user clicks the “Lock”, the server responds with the “Lock” button’s inverse: an “Unlock” button for that same room. As shown in Listing 10, this is represented in HTTP as a DELETE request on the current lock.

Note that neither of these actions navigate the user to a new room. They both take place within the confines of the page /rooms/123, and consequently do not create new entries in the browser history. This is appropriate when the actions do not change which resource is being viewed, but instead modify the existing resource.

By returning an “Unlock” button, the server is applying Hypertext as the Engine of Application State (HATEOAS). The presence of the “Unlock” button confirms that, having completed the request to lock Room #123, the current state of that room resource is “Locked”, and that one of the actions the user can take to modify that resource is to “Unlock” it. A navigation to that page, later or by a different user, would simply include the button that corresponds to whichever action the user is allowed to take, given the room’s state at the time of page load. We can say that the addition of response placement allows for subnavigational HATEOAS: instead of driving state updates with page navigation, subnavigational updates alter the current page to reflect the new state of the current resource.

It is very important that the server be aware of whether or not the request came from a client that is capable of placing responses. If the server only returns a small part of the page to a client that did not understand—and therefore ignored—the target attribute, the user might be navigated to an incomplete view. This can be resolved with a header that indicates the response’s target, and, in the absence of such a header, the server can safely assume that it is a full-page navigation. Once again, like with the custommethod attribute, Triptych provides the ability for the server to participate in backwards compatibility. The server can alter its response based on the client capabilities that the header—or lack thereof—implies, providing a smooth upgrade path via progressive enhancement.

The following UX patterns are a subset of common patterns not achievable in plain HTML. With the addition of Triptych, HTML is able to achieve some of them, meaningfully improving its expressive capabilities.

4.1.1 Click To Edit.

The click to edit pattern allows a user to click a button in order to trigger an editing view—usually to edit the resource at the current URL. In HTML, this can only be modeled as a page navigation, where viewing the data and editing the data take place on separate pages. Using partial page replacement, Triptych makes it possible to switch between these modes on the same page.

Listing 11: An editable form.

In Listing 11, a Triptych-enhanced button issues a request to the /edit relative URL and replaces the entire contents of the element with the ID target (i.e. the div enclosing the button.) A similar pattern for saving the form is enabled by Triptych.

4.1.2 Click To Load.

Websites often break up data into smaller segments, loading the first chunk quickly and then giving the user the opportunity to load more at a later time. Traditionally, a website might accomplish this by paginating, where each page provides another chunk of data. Modern applications, however, often append the new data to the existing page.

One way to add this pattern to a webpage is with a “Click to Load” button, which allows the user to load the additional elements on command. Listing 12 shows an HTML implementation of the pattern, taking advantage of Triptych’s response placement functionality.

Listing 12: A button that loads more resources.

In this case, the button targets the enclosing li, and will replace it with the next page of items, retrieved from the sever. The server response should also include the current 2N list item, to preserve its place in the overall list.

While Tryptich, in its current form, does extend the expressive power of HTML, there remain many UX patterns found in modern web applications that are not achievable.

4.2.1 Infinite Scroll.

Infinite scroll is a UX pattern in which, when a particular element in a series (e.g. a list) is scrolled into view, new elements are appended to the series. It is essentially an enhanced click-to-load, removing the requirement for explicit user action entirely. Listing 13 is an implementation of infinite scroll using htmx markup.

Listing 13: An htmx implementation of infinite scroll.

Achieving a similar UX pattern with a pure hypermedia implementation in Triptych is not possible. None of Triptych’s extensions add the ability for a hypermedia exchange to be triggered based on the user’s scroll position. By contrast, htmx is able to achieve this through the hx-trigger=revealed attribute, which changes the triggering event from a user click to a specific user scroll position,

4.2.2 Active Search.

Active search is a UX pattern where, as a user types into a text input, the search results are updated immediately. In htmx, this behavior can be achieved with hx-trigger, shown in Listing 14.

Listing 14: An htmx implementation of active search.

Once again, Triptych is not able to implement this pattern, since the triggering event is not a click, but the release of a keypress (i.e., keyup). Triptych’s partial DOM replacement does make it possible for the target of the search to be a partial page replacement—but triggering that search still requires a click.

Although the patterns presented in this section are only a small subset of the user experiences that can be achieved through generalized hypermedia controls, they highlight which of the control primitives HTML is currently best primed to support.

Triptych succeeds in bringing support for three of the four hypermedia control primitives to HTML. HTML currently has very limited support for customizing the request issuance and the response placement. However, Triptych is able to easily enhance those primitives, since HTML already contains semantic controls to customize them. Triptych simply makes those existing controls—the method and target attributes—more capable.

The remaining primitive demonstrates Triptych’s most glaring limitation. Generalized hypermedia libraries like htmx can initiate a hypermedia exchange from diverse triggers such as scroll position, element lifecycle, and timers. HTML, by contrast, is largely limited to user selections via clicks, which open links, or submissions of forms. Triptych does not attempt to generalize this primitive, because there are no readily available event trigger controls to extend in HTML.

We conclude that while Triptych represents a significant advancement in the expressiveness of HTML, it falls short of the expressive power of fully generalized hypermedia controls due to its inability to further customize the event triggers. This is a necessary limitation for Triptych, which adopts a strategy of minimal extensions to well-established HTML semantics. HTML itself has no established notion of modifying event triggers, and therefore nothing for Triptych to extend.

While HTML does not provide an explicit and general behavioral affordance mechanism to authors and users, there are specialized behavioral affordance mechanisms.

5.1.1 Lazy Loading.

5.1.2 Datalists.

Another specialized behavioral affordance can be in the HTML datalist element, which can be associated with an input element to provide autocomplete behavior. A simple usage of the datalist element, and its option element children, can be seen in Listing 15.

Listing 15: A simple usage of HTML datalists.

In this example, when a user begins typing a letter, an autocompletion affordance will appear offering completions that match what the user has typed. For example, if a user types the character ‘r’ into the input, the value “red” will appear in a suggestions popup, allowing the user to select the desired value.

The behavioral affordance here is tied to the input or keyup event—depending on implementation—and, once again, is very limited in what it provides to HTML authors. While the datalist is specified entirely in hypermedia (i.e. the values of the autocomplete affordance are determined entirely by information found in the hypermedia itself), it does not allow an HTML author to specify a hypermedia exchange to take place.

This limits the effectiveness of this affordance to situations when the domain of autocomplete values is relatively small and known at the time the HTML document is served.

5.1.3 Collapsible Details.

A final example of a limited behavioral affordance available in HTML is the details element. As with the datalist, this is not a hypermedia exchange active affordance, but it is a behavioral affordance. The detail element, when combined with a summary element, can be used to show only the summary of a section of text in an HTML document, and then reveal the additional content when the users clicks on the summary element.

This is typically rendered with a visual signifier such as a triangle indicating to users that the summary element is clickable.

Listing 16: A simple usage of HTML details.

Listing 16 will, when rendered in a web browser, show the text “Hypermedia” to the user, along with attendant visual affordance indicating that it is interactive. When a user clicks the text, the definition of hypermedia will be shown. As with the datalist attribute, no hypermedia exchange takes place in this case and the interaction is entirely local to the current HTML document.

A final important distinction between the various behavioral affordances we have discussed is between user-intentional affordances and author-intentional affordances.

A click event that triggers navigation occurs in response to active user input. The hypermedia-driven action therefore occurs in response to positive intentionality from the user.

The behavioral affordance offered by the lazy attribute, in contrast, is more nuanced. The triggering event occurs in response to user input scrolling the element into view—although this is a direct user action, a lower level of user intentionality involved. Indeed, the user may even be annoyed to see an image only begin to load once it is in the viewport. Here, the intentionality lies more in the HTML document author. They have chosen to use the lazy temporal modifier to save bandwidth, to make the initial page load faster for the user; the user did not take a conscious action with this result in mind.

It is important to note that the intentionality of the user and the HTML author do not always align. A mechanism for generalizing behavioral affordances in HTML may be abused by HTML authors to the detriment of web users.

In our analysis of Triptych we showed that the primary constraint on its ability to implement the patterns found in more general hypermedia control systems was the lack of a natural mechanism to express behavioral affordances in HTML. While HTML currently has some behavioral affordances, they are specified either implicitly, as in the case of anchor tags, or in an ad-hoc manner, as in the case of the lazy attribute. Surfacing behavioral affordances in a markup-friendly manner would enable HTML authors and users to enjoy a richer hypermedia environment on the Web.

In htmx, behavioral affordances are available via the hx-trigger attribute, which allows the author to specify events—and modifiers of those events—that trigger a hypermedia exchange. HTML could take this approach by adding a trigger attribute to request-capable elements. For many common cases, this approach is simple and flexible, but it also has limitations. The hx-trigger implementation has a relatively complex syntax for modifiers that does not align with the syntax found on existing HTML attributes.

Hyperview, a mobile hypermedia presented alongside htmx in 18, takes an element based approach, specifying behavioral affordances via a behavior element.

The button in Listing 17 will issue a request to /display after a normal-length button press to display the element. If the user long-presses the button, however, it issue a request to /edit and display an editing UI for that item.

The Hyperview approach uses the natural nesting of SGML-based markup language elements to express behaviors and it is a promising direction to explore for surfacing behavioral affordances in HTML. Multiple behavioral affordances can be naturally specified via multiple behavior elements, nested within a single parent. Modifiers to behaviors can be added via attributes in a manner that is easy for clients to parse and interpret,

This hypothetical behavior element could be composed with Triptych to implement patterns such as the infinite scroll, as seen in Listing 18. In doing so, it completes the generalization of HTML’s hypermedia controls that Triptych alone is incapable of.