HTML Events and the Radio Input
Published: 2020-12-11 02:38:49

In HTML, a Freak in the Stylesheets — What on Earth is HTML pt III, I talked about how HTML doesn’t really do anything. Ben Romy explains this pretty succinctly, saying, “Programming languages have functional purposes. HTML, as a markup language doesn’t really “do” anything in the sense that a programming language does. HTML contains no programming logic. It doesn’t have common conditional statements such as If/Else. It can’t evaluate expressions or do any math. It doesn’t handle events or carry out tasks” ([Why HTML is Not a Programming Language](https://ischool.syr.edu/why-html-is-not-a-programming-language/#:~:text=HTML%2C%20as%20a%20markup%20language,statements%20such%20as%20If%2FElse.&text=This%20is%20because%20HTML%20is%20not%20a%20programming%20language.)). 

  

Something that still doesn’t quite sit right with me though is radio inputs. If HTML has no programming logic (including if/else logic) and is entirely structural, how can it be capable of handling something like a radio input without JS? A radio input to me seems like a perfect instance of if/else logic: if this input is selected, mark all others as deselected. 

  

This quibble also extends to really any kind of input. If HTML can’t handle events, how am I writing text into it? The first clarification I must make to myself is that HTML DOES have events. It just doesn’t HANDLE those events. So Ben Romy’s point stands.

  

The tl;dr answer here is I’m not sure, but I have two theories:

1) Less likely theory: my assumption that there is if/else logic built into a radio button is wrong, and HTML doesn’t actually have to do anything programmatically when a user clicks a new radio button and the previously selected one is emptied; maybe this behavior is just intrinsic, like this pseudocode: “when button is selected, wipe clean all others before marking the radio button as selected.” This seems like a nice “u dumb bro” retort to my nitpicking, but I don’t think it completely explains it.

  

2) More likely theory: the DOM and JS are involved here, and the radio button has some built-implicit event handlers+listeners here, which you don’t see when you write a radio button into your code, but is actually there any time the browser actually deals with displaying/”function-ing” your radio button. Or basically, browsers are f-ing complicated. This seems a better/more likely explanation since it would also cover how other input types work, i.e., they’re complicated interactions between HTML/CSS, JS, DOM, your browser, etc.

  

The rest of this is me reminding myself of basic language boundaries/definitions. Enjoy if you want a refresher:

  

I assume I am not alone in this confusion over basic HTML that I have, which probably relates to barely learning any vanilla HTML and jumping into JS and then React directly in a bootcamp learning setting. For the previously uninitiated, combining HTML and JS as JSX confuses the boundaries between what part of the code is HTML, and what part is JS, what part is structure, and what is functional/scripting logic. Beyond that, I have a feeling a lot of my confusion legitimately relates to how confusing and complex the browser and DOM are.

  

In React land, when I write &lt;button onClick={() =&gt; console.log(“Hello Dolores”) } >Say Hello&lt;/button&gt;, even though this is all technically JS/JSX, when that actually gets converted into HTML and JS, (I think) onClick becomes an HTML onclick event handler, while the anonymous function I’ve passed in is the event listener. The handler handles the firing of the callback, which itself “listens” and is called whenever the specified event is delivered to the target.

  

listener is the callback (value) (JS). The key letter for remembering this is “L:” Listener is a caLLback.

handler is the HTML event attribute (key)… This might be a stretch, but maybe the key letter for this could be “A,” since we can think about the hAndler as the Event API for interconnecting HTML, JS, and the DOM. 

  

Multiple ways to add event listeners:

Above, declarative React style of adding an event handler (camel-cased onClick, onHover, onChange handlers)

target.addEventListener(type, listener \[, options\]);

Declarative HTML style:

“Adding an HTML attribute named on&lt;eventtype&gt;:”

&lt;button onclick="handleClick()"&gt;,

Imperative JS style:

“Or by setting the corresponding property from JavaScript:”

document.querySelector("button").onclick = function(event) { … }.

from [MDN DOM onevent Handlers](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Event_handlers)

  
[MDN's Events and the DOM article](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Events) gives three types, so you can assume that some of the ones I’ve named above are redundant, e.g., the React version is syntactic sugar for the EventTarget.addEventListener() style.