💾 Archived View for rawtext.club › ~sloum › geminilist › 004944.gmi captured on 2024-03-21 at 16:46:54. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Proposal: Simple structured form specification

me at edaha.org me at edaha.org

Wed Jan 27 17:37:56 GMT 2021

- - - - - - - - - - - - - - - - - - -

I've been following this discussion and while I'm on the side of "gemini doesn't need forms", I thought it would be fun to see how far we could simplify the concept of a form :) I don't have any direct responses to anything said thus far, but my ideas below have been inspired by the back and forth.

Ultimately, there are only a few data types that are truly needed for any form: binaries, choices, and text. This helps limit the scope of what would need to be implemented and what people would need to learn to be able to use forms. Keep it simple, smarty!

With gemini's limitation on URLs, and the fact that data can only be passed via the URL, we have to keep in mind that we'd want to limit the amount of information needed to be passed. Thus, I'd say that, were forms to be implemented, they must pass arguments positionally instead of as named parameters.

SyntaxTo keep it simple (and have fun), I think an input's identifier can simply be the reverse of the link identifier: <=

Much like how => signifies "going somewhere else", <= signifies "sending information here".

<= lines take two parameters: type and label. Again, very similar to links :)

<= type label

As mentioned, there are really only three types of data that are meaningful and distinct. The valid options for "type" would only be "binary" "text" and "choice". "submit" is also a type that is needed as it's an action.

binaryBinary options are best known as checkboxes on the web. They're simple on/off toggles. How they are displayed is up to the client

<= binary I have read this email and understand the binary option type

When submitted, this would be a simple 0/1 value in the url.

textThe bulk of data that we could ever ask for is just 'text'. Differentiating between "tel" "num" and "text" should be done server-side, as these are all still just text fields. "password" is deliberately not supported -- this is why gemini has client certs.

<= text What's your website?

If an input should be multi-line, then the following could be used:

<= text Tell me what you like about gemini in a paragraph.<= text

A single `<= text label` input can be followed by exactly one more `<= text` line to signify that it should be multi-line input. It is up to the client to decide how many lines to display. If a third `<= text` line were added, it would be interpreted as a new text input.

choiceChoice is ultimately optional, IMO. This provides closed-ended responses for a user. Again, the idea of "radio" vs. "dropdown" vs. anything else does not matter, as those are entirely client-side decisions. What's important is that the user is only able to select one response.

<= choice Which of these protocols are we using?<= choice gemini<= choice gopher<= choice HTTP

After an initial `<= choice` toggle, immediately adjacent ones are interpreted as options for a single input. The above could be displayed as a dropdown, or radio boxes, or anything the client decides.

submitFinally, submit. This one's easy:

<= submit /path/to/interpreter

Note that there's no support for a custom label for the button -- again, by design :) We don't need them.

Putting it all together

The last part is how it's passed. As mentioned at the beginning, I think (were gemini to support this, which I don't think it should) that form inputs are sent /positional/, not named. This is a requirement to reduce the chance of hitting the url limit.

Using the above inputs as an example, upon clicking the submit button, the url would look like this (for my own sanity I'm not doing proper url encoding -- i leave that as an exercise to the reader):

/path/to/interpreter?1&edaha.org&I like how simple and easy it is to use\nit's a lot of fun!&gemini

and that's it! I've got to get back to work now, but this was a fun thought experiment :)