Hypermedia Controls: Feral to Formal (PDF: ACM HT'24)(dl.acm.org)
dl.acm.org
Hypermedia Controls: Feral to Formal (PDF: ACM HT'24)
https://dl.acm.org/doi/pdf/10.1145/3648188.3675127
10 comments
The URL to Fielding's "REST APIs must be hypertext-driven" blog post (ref #20) is messed up. The actual URL is <https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...>, but it links instead (for the second time) to <https://www.w3.org/2011/10/integration-workshop/p/hypermedia...> (which is ref #1, Mike Amundsen's "Hypermedia-Oriented Design" document).
Also, where's the source repo (for the paper)?
Also, where's the source repo (for the paper)?
Interesting write up. It frames htmx as a much more principled system. But it feels like such a dry version of control, something that conceetely links back to ideas of hypermedia, but I'm not sure that it helps the user or enhances the web much. Formalism still has its place, but I was hoping for something that more sheds lights on the medium.
Two things come to my mind as better exhibiting the control offered within the page:
1. Schema.org Actions/EntryPoints, which can markup the things users can do on a page with additional details & info, formalizing what buttons might offer. This is used by Gmail to let HTML emails include quick actions.
> Today, we are excited to start the next chapter of schema.org and structured data on the Web by introducing vocabulary that enables websites to describe the actions they enable and how these actions can be invoked.
http://blog.schema.org/2014/04/announcing-schemaorg-actions.... https://schema.org/Action
Unfortunately the docs only show the json-ld markup! Which is really a data island, off the hypertext! How horrible, just so trashy it's done like this! Ideally microdata (or rdfa) would be used, to enrich the page as it already is. You have to tab to it, but available on the Gmail docs: https://developers.google.com/gmail/markup/actions/declaring...
2. Invoker actions (renamed Commands) are starting to be implemented in browsers, which allows components to wire themselves to each other, without js. Buttons triggering modals, tooltips wiring to elements... This stuff has always been un-hypertext, has been developers writing their own js to wire the page up. But now the page itself can express control & wirings.
And with custom events and custom actions, it's possible to imagine a vast expansion of hypermedia control, of making visible the machinery & linkage of hypertext.
https://open-ui.org/components/invokers.explainer/
Two things come to my mind as better exhibiting the control offered within the page:
1. Schema.org Actions/EntryPoints, which can markup the things users can do on a page with additional details & info, formalizing what buttons might offer. This is used by Gmail to let HTML emails include quick actions.
> Today, we are excited to start the next chapter of schema.org and structured data on the Web by introducing vocabulary that enables websites to describe the actions they enable and how these actions can be invoked.
http://blog.schema.org/2014/04/announcing-schemaorg-actions.... https://schema.org/Action
Unfortunately the docs only show the json-ld markup! Which is really a data island, off the hypertext! How horrible, just so trashy it's done like this! Ideally microdata (or rdfa) would be used, to enrich the page as it already is. You have to tab to it, but available on the Gmail docs: https://developers.google.com/gmail/markup/actions/declaring...
2. Invoker actions (renamed Commands) are starting to be implemented in browsers, which allows components to wire themselves to each other, without js. Buttons triggering modals, tooltips wiring to elements... This stuff has always been un-hypertext, has been developers writing their own js to wire the page up. But now the page itself can express control & wirings.
And with custom events and custom actions, it's possible to imagine a vast expansion of hypermedia control, of making visible the machinery & linkage of hypertext.
https://open-ui.org/components/invokers.explainer/
Maybe I'm mistaken and this isn't part of hypermedia controls, but collecting and marshalling user input into the resultant request seems to be missing completely.
It seems to me that part of a hypermedia control includes what kinds of inputs are accepted and how they are included into a resultant request. Whether this is an HTML form with input type attributes or Swagger/OpenAPI definitions, there's a generic definition of request marshalling needed I believe.
It seems to me that part of a hypermedia control includes what kinds of inputs are accepted and how they are included into a resultant request. Whether this is an HTML form with input type attributes or Swagger/OpenAPI definitions, there's a generic definition of request marshalling needed I believe.
Some of them don't do this though, which suggests it isn't a defining feature. The only "user input" in many cases is a click, which doesn't need to be collected and marshalled. The definition also includes "controls" no user input at all, such as when "onload" is the trigger, which I guess might be controversial, but the onclick controls are definitely controls and sometimes the click is the only input.
I think in the context of hypermedia there's a difference between the interface of the User Agent and affordances in the media. The "hyper" part of hypermedia refers to how resources are linked to and can influence each other. A resource can be linked to the resource that is responsible for creating it as in a Comment resource linking to a Reply resource. That reply resource needs a way to marshall whatever the elements of a Reply are (text, author, images, etc) into a new Comment Resource. That's missing.
Clicks on a page (and even the actual of typing or selecting an image) are part of the User Agent's interface: how the User Agent would interpret those hypermedia controls exposed by the Reply Reosurce into things the user can do. But the user Agent itself then needs to Marshall the result of user input into some kind of request. In HTTP this is a form and resulting POST request in urlencoded or multipart format.
A generic definition of this whole concept is needed.
Clicks on a page (and even the actual of typing or selecting an image) are part of the User Agent's interface: how the User Agent would interpret those hypermedia controls exposed by the Reply Reosurce into things the user can do. But the user Agent itself then needs to Marshall the result of user input into some kind of request. In HTTP this is a form and resulting POST request in urlencoded or multipart format.
A generic definition of this whole concept is needed.
[deleted]
What does one do with a formalized definition of hyper media controls
Basically 'naming things'. It makes it possible to address and distinguish strategies in writing and conversation.
H-Factors ( http://amundsen.com/hypermedia/hfactor/ ) have also been useful to me in the past for the same reasons.
H-Factors ( http://amundsen.com/hypermedia/hfactor/ ) have also been useful to me in the past for the same reasons.
One generalizes, then one implements
Heh, if you had included "by studying htmx" in the post title it'd be #5 on the front page in no time
> It is still possible for what Nelson refers to as "transcopyright" issues to occur on
same origin transclusions, when multiple authors reuse the same origin for hosting
copyrighted content, but this is not the common case, at least in the case of the WWW.
I would argue that this overwhelmingly is the common case—viz:
- twitter.com
- youtube.com
- facebook.com
- reddit.com
... etc. It is only through artificially restricting your focus outside the way that the Web is used in practice—and optionally also being so blinded by one's milieu (that of professional programmers who unlike the average person might spend between, say, 25–50% of their waking hours on a typical day at least partially focused on publishing to the origin associated with whatever they're getting paid for at the moment, but nonetheless live the rest of their lives like everyone else publishing to and consuming from the major platforms)—that you can claim something like the above.
I would argue that this overwhelmingly is the common case—viz:
- twitter.com
- youtube.com
- facebook.com
- reddit.com
... etc. It is only through artificially restricting your focus outside the way that the Web is used in practice—and optionally also being so blinded by one's milieu (that of professional programmers who unlike the average person might spend between, say, 25–50% of their waking hours on a typical day at least partially focused on publishing to the origin associated with whatever they're getting paid for at the moment, but nonetheless live the rest of their lives like everyone else publishing to and consuming from the major platforms)—that you can claim something like the above.
So I've read the title and the abstract, and I still have no idea what a "hypermedia control" is.
Academic papers are generally written to be read by peers in the field. If you're not a researcher in the hypermedia field, you shouldn't expect to immediately understand a paper without doing some work. The abstract is a paper distilled to its essence, and is not the place to expect to learn the necessary background.
In this case, the abstract says: "This functional mechanic is used to create first an informal and then formal definition of the term "hypermedia control". Using this formal definition we then derive a generalization of the concept, referring contextually to the World Wide Web." Therefore, we should expect to look in the paper for the definition.
We find the "functional definition" at Definition 4.1: "A hypermedia control is an element that responds to an event trigger by issuing a type of request to a URL and placing the response at some position within the user agents viewport." The "formal defintion" then follows immediately after, but can't be quoted here because it requires LaTeX notation and a full page of text.
As a possible non-academic summary is that a hypermedia control can be defined as:
An interactive element within a hypermedia system (like a web page) that allows users to trigger actions, typically resulting in new content being loaded or displayed. Common examples include: links (clicking loads a new page); buttons (clicking triggers an action like submitting a form); form inputs (entering data and submitting retrieves results); images with embedded links (clicking loads new content).
The key aspects of a hypermedia control are that it responds to a user action (click, submit, etc.); it causes some kind of network request (usually to fetch new content); it specifies where that new content should go (replace the whole page, update a specific area, etc.)
In this case, the abstract says: "This functional mechanic is used to create first an informal and then formal definition of the term "hypermedia control". Using this formal definition we then derive a generalization of the concept, referring contextually to the World Wide Web." Therefore, we should expect to look in the paper for the definition.
We find the "functional definition" at Definition 4.1: "A hypermedia control is an element that responds to an event trigger by issuing a type of request to a URL and placing the response at some position within the user agents viewport." The "formal defintion" then follows immediately after, but can't be quoted here because it requires LaTeX notation and a full page of text.
As a possible non-academic summary is that a hypermedia control can be defined as:
An interactive element within a hypermedia system (like a web page) that allows users to trigger actions, typically resulting in new content being loaded or displayed. Common examples include: links (clicking loads a new page); buttons (clicking triggers an action like submitting a form); form inputs (entering data and submitting retrieves results); images with embedded links (clicking loads new content).
The key aspects of a hypermedia control are that it responds to a user action (click, submit, etc.); it causes some kind of network request (usually to fetch new content); it specifies where that new content should go (replace the whole page, update a specific area, etc.)
One important clarification I should have mentioned: buttons and form inputs only meet the definition of hypermedia controls when HTMX or something similar is used. Under normal HTML only links, images, complete forms, and iframes qualify, since (for instance) form inputs and buttons can't on their own make a request or specify where new content would go.
You can put the actual definition on page 4, or you can make it easy for the reader and just say "hypermedia controls (like links and buttons)" the first time you mention the term in the abstract.
Strictly speaking, buttons aren't typically hypermedia controls. Haven't read the paper yet but the only controls in HTML are links and forms. Buttons can be nested inside those as actuators but aren't controls unto themselves since they don't meet that functional requirement of sending a request to a URL and inserting response content into the viewport.
EDIT: It seems the authors also consider images and iframes to be controls since they also make requests and add content to the viewport.
EDIT: It seems the authors also consider images and iframes to be controls since they also make requests and add content to the viewport.
"four types of hypermedia controls found in HTML: links (anchors), forms, image tags and iframes"
"Examining the hypermedia control mechanic of links, forms, image tags and iframes in HTML, we see the following common functional pattern emerge: For each of these controls: (1) An event trigger (click, submit or load) (2) Causes a particular type of HTTP request issuance (3) That request is made to a resource location specified by a URL (4) The content of the HTTP response is then placed in the user agent viewport Within the context of HTML, this gives us the following functional definition of hypermedia controls as an element that incorporates this hypermedia control mechanic: Definition 4.1 (Hypermedia Control). A hypermedia control is an element that responds to an event trigger by issuing a type of request to a URL and placing the response at some position within the user agents viewport."
They mention the limitations of these existing hypermedia controls within HTML. In general, existing HTML controls don't allow the developer to choose any type of HTTP request to be sent from any type of HTML element and target any part of the page.
"in the absence of an extension mechanism hypermedia clients and servers must agree in advance on the types of hypermedia controls they will support. HTML includes a very powerful extension mechanism: JavaScript [47 ]. By taking advantage of this extension mechanism we are able to extend HTML and provide the generalized hypermedia controls outlined above to HTML authors."
"CONCLUSION In this paper we proposed an informal and then definition of the term "hypermedia control", derived from the implementations of four common such controls found in HTML: anchors, forms, im- ages and iframes. From this formal definition we then derived a generalization of the concept of hypermedia controls within the context of HTML. We then introduced htmx, a JavaScript library that implements these generalizations for HTML authors. We demonstrated two interactive patterns that can be implemented by HTML authors using generalized hypermedia controls. Finally, we introduced Hyperview, a mobile hypermedia that also implements the generalization we proposed. We demonstrated an interactive pattern achievable in Hyperview using this generalization, thus demonstrating that this generalization applies to hypermedia systems beyond HTML and the WWW."
"Examining the hypermedia control mechanic of links, forms, image tags and iframes in HTML, we see the following common functional pattern emerge: For each of these controls: (1) An event trigger (click, submit or load) (2) Causes a particular type of HTTP request issuance (3) That request is made to a resource location specified by a URL (4) The content of the HTTP response is then placed in the user agent viewport Within the context of HTML, this gives us the following functional definition of hypermedia controls as an element that incorporates this hypermedia control mechanic: Definition 4.1 (Hypermedia Control). A hypermedia control is an element that responds to an event trigger by issuing a type of request to a URL and placing the response at some position within the user agents viewport."
They mention the limitations of these existing hypermedia controls within HTML. In general, existing HTML controls don't allow the developer to choose any type of HTTP request to be sent from any type of HTML element and target any part of the page.
"in the absence of an extension mechanism hypermedia clients and servers must agree in advance on the types of hypermedia controls they will support. HTML includes a very powerful extension mechanism: JavaScript [47 ]. By taking advantage of this extension mechanism we are able to extend HTML and provide the generalized hypermedia controls outlined above to HTML authors."
"CONCLUSION In this paper we proposed an informal and then definition of the term "hypermedia control", derived from the implementations of four common such controls found in HTML: anchors, forms, im- ages and iframes. From this formal definition we then derived a generalization of the concept of hypermedia controls within the context of HTML. We then introduced htmx, a JavaScript library that implements these generalizations for HTML authors. We demonstrated two interactive patterns that can be implemented by HTML authors using generalized hypermedia controls. Finally, we introduced Hyperview, a mobile hypermedia that also implements the generalization we proposed. We demonstrated an interactive pattern achievable in Hyperview using this generalization, thus demonstrating that this generalization applies to hypermedia systems beyond HTML and the WWW."
The paper is structured in the following manner:
- background
- examination of existing hypermedia controls in HTML
- formalization & definition
- generalization
- application (htmx & hyperview)
The TLDR is:
> 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 in some manner (i.e. with some disposition)
- background
- examination of existing hypermedia controls in HTML
- formalization & definition
- generalization
- application (htmx & hyperview)
The TLDR is:
> 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 in some manner (i.e. with some disposition)
Sorry for being so direct, but I don’t really understand why papers of such low quality are produced. Is this some school research? There’s so much water and zero interesting stuff. Hypermedia is an old idea and there’s so much more to it than just HTML elements with interaction outcomes defined by server. Hypermedia APIs, RMM, access control etc etc.
In researching for my own PhD I was surprised to find that there was no focused academic treatment of hypermedia controls. For example, Fielding mentions them only in passing in the introduction of his thesis. As this concept was a key motivating idea, leading both intercoolerjs/htmx and hyperview I felt a formal definition that went beyond the web was a useful contribution, and peers in the hypermedia community agreed. I hope that this definition and generalization leads to further advancement in hypermedia systems such as the web.
I don’t think this is useful. It actually seems to be wrong.
Hypermedia is the way to organize content for consumption in non-linear way. Hypermedia systems are broader concept than client-server (single document or program can be a hypermedia system).
Formal definition can look like this: given a set of multimedia elements (text, audio, video, etc) and possible transitions between them, this set can be defined as hypermedia if there exist elements which can be reached from some entry element via multiple different transition paths.
A hypermedia system then is such system that allows users to consume hypermedia content by presenting multimedia elements and enabling users to transition between them.
Note that this definition doesn’t mention networks or protocols: collection of HTML pages, images, videos etc on local hard drive is still a hypermedia system despite that no network is involved.
Compared to a book or ordinary text document the core and the most important property of such system is that possible transitions are predetermined: designer of the system defines the possible ways to consume the content, while the book reader is free to start reading at any page. Networks, protocols, HTML, UI are less interesting implementation features at this stage. This definition opens many interesting opportunities to talk about before you go into technical details.
This is what I would expect from such paper, not school-level talks about links and buttons.
Hypermedia is the way to organize content for consumption in non-linear way. Hypermedia systems are broader concept than client-server (single document or program can be a hypermedia system).
Formal definition can look like this: given a set of multimedia elements (text, audio, video, etc) and possible transitions between them, this set can be defined as hypermedia if there exist elements which can be reached from some entry element via multiple different transition paths.
A hypermedia system then is such system that allows users to consume hypermedia content by presenting multimedia elements and enabling users to transition between them.
Note that this definition doesn’t mention networks or protocols: collection of HTML pages, images, videos etc on local hard drive is still a hypermedia system despite that no network is involved.
Compared to a book or ordinary text document the core and the most important property of such system is that possible transitions are predetermined: designer of the system defines the possible ways to consume the content, while the book reader is free to start reading at any page. Networks, protocols, HTML, UI are less interesting implementation features at this stage. This definition opens many interesting opportunities to talk about before you go into technical details.
This is what I would expect from such paper, not school-level talks about links and buttons.
I encourage you to submit a paper for next year’s ACM hypertext conference presenting your ideas.
jph00 helpfully quoted the paper's definition of hypermedia for us: https://news.ycombinator.com/item?id=41538587
> We find the "functional definition" at Definition 4.1: "A hypermedia control is an element that responds to an event trigger by issuing a type of request to a URL and placing the response at some position within the user agents viewport."
You said:
> Note that this definition doesn’t mention networks or protocols
Neither does the given definition of hypermedia controls in the paper. So it seems that your respective definitions are perfectly compatible.
> We find the "functional definition" at Definition 4.1: "A hypermedia control is an element that responds to an event trigger by issuing a type of request to a URL and placing the response at some position within the user agents viewport."
You said:
> Note that this definition doesn’t mention networks or protocols
Neither does the given definition of hypermedia controls in the paper. So it seems that your respective definitions are perfectly compatible.
Since your attempt at improving the definition of hypermedia controls fails to actually mention hypermedia controls at all, I’m going to suggest that it is not in fact an improved definition.
You seem to have missed the point of the paper, since your comment here is presenting a definition of hypermedia as an alternative to the given definition of hypermedia controls. Defining hypermedia in general and discussing other aspects of it is not relevant to the scope of the paper. It honestly doesn't make any sense to complain that an academic paper specifically on hypermedia controls doesn't define and comprehensively discuss hypermedia as a whole, unless you have mistaken the purpose of the paper as being to define hypermedia as a whole. Your criticism of the definition of hypermedia and hypermedia systems might make more sense if it were directed at Carson Gross' book, Hypermedia Systems. Have you read it?
excited about it because i believe it is the first academic paper to focus on and provide a formal definition for hypermedia controls in particular, rather than treating them as part of a larger system