Webforms

Webforms are an invaluable means of communicating to a website and possibly it’s audience. So today I want to describe how WebKit implements them, though I’ll leave text editting to another day.

I also use this on some of Odysseus’s internal pages in order to implement search or to allow updating the local SQLite database (the latter of which involves intercepting the form submission) elsewhere.

The <form> element itself mostly serves to track all the comprising form inputs (they (un)register themselves), and tells all of them to validate, reset, or load themselves into a FormSubmission’s possibly platform-specific FormData which the form will then hand to the page loading subsystem I described previously (https://adrian.geek.nz/webkit_docs/loading.html ).

The form inputs tell the <form> when to submit, reset, or validate. And validation may be part of submission.

The problem with the <input> element is that it acts and behaves very differently depending on it’s type, but it must be exposed to JavaScript as a single class. So it mostly dispatches to it’s inner InputType, which are looked up in a hashmap.

These InputTypes implement the event handler as you would expect, reusing code through a decent class hierarchy. The render tree will later call the platform-specific widget rendering code if the inputs aren’t too styled, which they typically are now.

Some input types like <form type="file"> will show system dialogs when clicked. This is accomplished by having it ask the “chrome” (outside the sandbox) to open that dialog window for it and notify it of the results.

Also in order to display their value, most form inputs use a concept called “shadow DOMs”. These are subtrees which are translated over into the render tree instead of the actual children visible to JavaScript.

WebKit will also use it’s “shadow DOM” to render validation messages after the form controls have validated themselves. As will text-based inputs in order to offer autocompletions from it’s associated <datalist>.

And the <select> element is a little bit more complex because it’ll create custom nodes in the render tree choosen based on whether the “multiple” attribute is present, and if it’s absent that render node will tell the chrome to show it’s popup menus.

Opinion time

I don’t like forms in mainstream web design, I wish everyone didn’t start styling their form controls to have the same “flat” look. I’m familiar with the default look from other apps, and I like it!

It’s also dissappointing that webdevs don’t seem to know just how powerful form controls are these days. In WebKit at least you have builtin and extensible autocompletion and validation UIs! There’s code specifically for submitting to mailto: URIs!

Do other browsers not have this?