2 posts tagged with "html"

As web developers, we know that most of the create, read update, and delete (CRUD) actions we perform on the web are typically (hopefully?) done using an HTML form.

HTML Forms​

HTML Forms are cool because they have plenty of built-in features.

For example, they have native form validation and access to all the inputs in a form, and at some point, because you need to submit the form, there is a mechanism to do that as well. You can use a button, <button>submit</button> or an input of type submit, <input type="submit" />, although the latter isn't used as much these days in new sites, from what I've seen.

Here is a simple form to exhibit this.

If you fill out the form and click submit, the form will submit and add a paragraph with dark green text client-side that says, "Form submitted".

There are other things in the simple form, like form validation via the required attribute on inputs, but that's not what we're here to discuss.

What we want to touch on is that the form was able to handle the submit event because it had a submit button associated with it, which was defined in HTML within the form element.

Note: you can press enter in fields to submit a form, but again, not what we're here to discuss.

How I Broke My Form​

This brings us to a new feature that I was working on for OpenSauced for a few months, workspaces. I encourage you to create your own, but for now, let's get back to the business of forms.

Here's our beautiful workspaces settings page that I implemented.

Recently, there were styling changes, which is what you see above.

Everything looked great, and I had tested it.

Narrator: he thought he had tested it, and we shipped things to production.

Once things went live, I decided to do some smoke tests, which I usually do. I went over to the beautiful workspace settings I had worked on, made some changes in the settings, and then clicked Update Workspace button. Hmm, no toast message saying the settings were updated. I checked the browser dev tools to see if there were any JavaScript errors. Nothing related to the updates. And then it dawned on me. The submit button was outside the form, and I just broke some key functionality in the app.

Side note, but luckily thanks to Netlify's deployment rollback feature, I was able to revert to the previous production deployment within about a minute of the workspace settings page being broken 😅

How I Fixed My Form​

So how did I fix it? We needed this new styling to fix several other issues related to z-indexes and layout.

For some context, the OpenSauced application is a Next.js site, so React, but I decided to put on my old school HTML hat and remembered that form elements can be associated to a form via a form attribute. What you need to do is give the form an id attribute, and the form element that you want to associate the form to needs to have a form attribute whose value is the value of the id attribute for the form.

Here's another simple form demonstrating a simplified version of my fix.

I encourage you to remove the form attribute from the button in the above CodePen to see the issue I caused.

Here's the fix I rolled out to production.

Wrapping Up​

Learning a framework is great, and I'm a big proponent of just building something, but as you continue on in your career, it's great to start getting some fundamentals into the mix.

Also, this is a perfect example of why using semantic HTML is important! It definitely helped me get out of jam! 😅

Stay saucy peeps!

If you would like to know more about my work in open source, follow me on OpenSauced.

All the major browsers now support the <dialog%gt; element. Why add this HTML element? User land code, code that developers write to fill in gaps of the browser, was doing similar things repeatedly, especially around focus trapping, and browser engines responded by adding this functionality directly in the browser.

Focus Trapping​

What is focus trapping? It's a feature where you do not want focus outside a specific element, and that element typically contains focusable elements.

For example, a form in a modal to confirm an action: As a user uses the keyboard to navigate, they go to the next focusable element, e.g. a button.

If they reach the last focusable element in the modal, without focus trapping, the focus would go to the next focusable element in the document object model (DOM). With focus trapping, you go from the last focusable back to the first focusable element in the parent element.

In user land, popular packages like focus-trap have enabled developers to incorporate focus trapping.

<dialog> for Modal Dialogs​

With the dialog element, you get this for free, although there is a gotcha. If you add a dialog element to the page with the open attribute set, the dialog element will become visible on the page; however, focus trapping will not work as you'd expect in a modal.

From the API documentation:

Note: While you can toggle between the open and closed states of non-modal dialog boxes by toggling the presence of the open attribute, this approach is not recommended.

To get focus trapping working, the JavaScript API is required. You can display a modal on the screen by calling the HTMLDialogElement showModal method.

Note that you'll need to view this CodePen in full view because, for some reason, modal dialog focus trapping does not work in the CodePen editor view.

Not only do you get focus trapping, you also get modal close functionality that people have come to expect via the Escape key.

All of that is already amazing, but another common thing people were doing in user land was adding a background to block out users from interacting with the page. With the <dialog%gt; element, we can add a ::backdrop pseudo-element that does this for you. All you need to do is style it. In the CodePen above, uncomment out this code in the CSS panel to see this in action.

{% raw %}
dialog::backdrop {
  background-color: purple;
  opacity: 0.55;
  filter: blur(100px);
}
{% endraw %}

<dialog> for Non-Modal Dialogs​

The structure of a non-modal dialog element is the same as a modal dialog. The main difference is to show a non-modal dialog, you need to call the HTMLDialogElement show method.

With a non-modal dialog, the user is not blocked from navigating the rest of the page, i.e. no focus trapping, and the Escape key will not automatically close the dialog.

Closing a dialog​

To close a dialog or modal, we can use the HTMLDialogElement close method.

{% raw %}
const modal = document.querySelector("dialog");

// some button in the dialog that has a click event listener registered
modal.querySelector("button").addEventListener("click", () => {
  modal.close();
});
{% endraw %}

Wrapping up​

The web platform keeps getting better. It's great to see pain points in user land that had user solutions come natively to browser land.

References​

• Using JavaScript to trap focus in an element
• MDN - <dialog>: The Dialog element
• GitHub issue <dialog%gt; element should trap focus from the w3c/html repository.
• Dialog - web.dev

Stay saucy peeps!

If you would like to know more about my work in open source, follow me on OpenSauced.