The way I’ve chosen to approach webforms is quite peculiar! I believe in the value of letting readers communicating back to a website & its audience, but rendering these controls inline incurs significant complexity which actively gets in the way of exploring the broader possibilities of browser-design. In exploring how readers can best communicate back via speech or a TV remote I decided to separate webforms out into their own webpage(s) to be handled by a dedicated codepath. I may still render (fully-stylable) form controls inline using the same logic as any other element, but once they’re clicked (like a link) I switch to the separate mode.
This approach has several advantages. It minimizes the number of events normal HTML rendering needs to handle, whilst avoiding the need to embed “native” UI widgets. Or at least widgets which look native to whichever platform the browser is running on. It gives me the design flexibility to present the best interface for your device or operating system, without clashing with the webdesigners’ designs. Taking full advantage of the effort the platform has put into accessibility.
The drawback is that webdesigners who haven’t followed accessibility best practices will find that important context for their form controls may be missing in Haphaestus & other Argonaut Suite browsers.
For TV remote input I chose to create a sidebar listing all the forms’ inputs alongside a menu of possible values for the selected control, which I have now implemented (as “Bureaucromancy in an even more peculiar way! In Haphaestus forms are rendered (by what amounts to a server-side webapp) to webpages full of hyperlinks. The form state is stored in the query string, whilst which submenu is displayed is specified by the URI’s path, where the tab-history becomes naturally becomes an undo/redo stack! These hyperlinks typically tell the backend to set a specified query parameter to a specified value, upon which we can build select-boxes & autocompletion lists!
This allows me to prototype in existing browsers with confidence that I can integrate into Haphaestus (in-process) as soon as I’ve implemented links! It’d take a little more than a shallow wrapper around HURL! And with a templating language similar to Jinja/Django/Liquid/etc this should help more webdevs be comfortable contributing. Usually when writing Haskell code I’d prefer Blaze, but that might scare such contributors away.
The design of these menus are heavily centered upon squares to minimize the number of button processes needed to get to your desired option.
Some of the most complex input types to implement were the ones related to text entry, especially if we want to “internationalize” in preparation for others to contribute the onscreen keyboard appropriate for their locale.
I implemented this by having backend support for appending & deleting text, I have not yet implemented support for moving the text cursor away from the end of the string. We’ll see if that’s a desired feature. A configfile, or the query string, specifies which template to render, which in turn renders the appropriate onscreen keyboard. Which may be refined for the particular input type which is actually being displayed.
There is lots of exploration that can be done regarding the design of these keyboards, but currently I have a tabbar navigating between 5 squares covering the Latin1 characterset.
For dates I pulled in the HourGlass & TZ hackages to help me split the data into its individual components, though I also wrote some of my own code to take this further. Each of those individual components (Your, Month, Day, Hour, AM/PM, Minute, & Timezone) can be incremented or decremented (or toggled, in case of AM/PM) whilst most of them display grids of possible values for readers to pick between. In the case of years (a numpad) & timezones these are separated out into separate pages. Which of these subcomponents are displayed depends on the input’s type.
Another link allows setting the input to the current time.
A fair amount of backend code shuttles the data between HourGlass & the templates, whilst CSS3 Grid made it trivial to render calendars! Unfortunately however HourGlass does not support dates BCE, feel free to contribute fixes upstream!
I would be interested in discussing the needs for implementing non-Gregorian calendars.
Bureaucromancy (this form engine I’m describing) also includes code to transfer data between querystrings & the form inputs it has parsed from HTML, normalize the values entered into a form input, & ensure it meets constraints specified by the website. If those constraints include regular expressions, I use the regex-tdfa hackage to evaluate them.
Whilst I have caught up to the current (sorry) state of the dominant browser engines regarding webforms, there’s some controls I consider vital lacking from the specs which I wish to explore! Like passkeys or spam-protection via proof-of-work! Also I’ve so far neglected to internationalize what little UI text Beurocromancy has, that should be trivial (use JSON?). It’d be good to explore adding alternative text & date entries better suited to different locales. Bureaucromancy is at a great place, but there’s lots more that can be done!
But what excites the most is to implement more form engines for different devices & operating systems! To explore the design space opened up by moving this feature out from hypertext documents!
For my verbal browser “Rhapsode” I’d give forms a conversational UX! For the desktop I’d overlay a page-modal dialog full of native widgets, benefitting from the readers’ familiarity with them & all the effort put into making them accessible. Webdesigners seem to want that modal-UX, though frequently build it into their pages! 8pen provided an interesting concept for joystick/touch-based text entry. It’d probably make Bureaucromancy more useful to other devs to expose a commandline interface! Who knows what else?
I may even design a new webform markup language which better suits my implementation needs!
Note: Most other browser engines (including all the dominant ones) reimplement form controls themselves, they don't reuse the OS's native UI library. Accessibility can suffer due to this.