💾 Archived View for rawtext.club › ~sloum › geminilist › 004935.gmi captured on 2023-12-28 at 16:39:20. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Russtopia rmagee at gmail.com
Wed Jan 27 03:55:41 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Tue, 26 Jan 2021 at 15:16, easrng <easrng at gmail.com> wrote:
I agree that Gemini should have forms, but that format doesn't look
great to me.
Sure, I'm not attached too much to my syntax, it was a hack-ish one I'dcome up with for another project of mine.
What if forms were implemented as their own pages, not a
new link line type? I'm thinking something like this:
# Gemini Form Proposal
## Basic Format
Form fields are on their own line. Any line starting with `[in` is
considered a form element. This allows clients to continue to
determine line types by the first 3 characters. After the `[in`, a
dash is required.
After the dash, the input type is listed. If a client cannot handle an
input type, it SHOULD fall back to text. The rest of the line, up to
the first ] is used as options for the input. Next, there is a ]
character, then an optional text label.
## Escape sequences
In order to allow for ] characters, newlines, and literal backslashes
in input options, preface them with a backslash.
## Input types
Other types could be added, like number, email, phone, color, or even
file, but I feel this is an acceptable minimum set of types.
I do feel like there should be some explicit allowance for one-oftypes and boolean types, to give a client app hints as to what 'widgets'to best use to present the valid values to the user (eg., drop-downs orchoose a-b-c-d for a text-based client, and checkboxes). IMHO.
### text
A text input is a single line text input. Its format is as follows.
(Things in parentheses are optional)
```
[in-text <name>( <initial value>)]
```
For example,
```
[in-text userFullName Alex Fierro] What is your name?
```
### password
A password input is a single line text input that MUST hide the value
typed into it. For security reasons, there is now way to prefill a
password input. Its format is as follows.
```
[in-password <name>]
```
For example,
```
[in-password newPassword] What is your name?
```
### multiline
A multiline input is a text input that accepts any number of lines.
Its format is as follows. (Things in parentheses are optional)
```
[in-multiline <name> ( <initial value>)]
```
For example,
```
[in-multiline bio I am a demigod who enjoys art and the colors pink
and green.\nI usually use she/her pronouns, but sometimes I use
he/him.] Tell me about yourself
```
### submit
A submit input is a button that submits a form to a URL. It's label
SHOULD be used as the text on the button. Its format is as follows.
```
[in-submit /url/to/submit/to]
```
For example,
```
[in-submit /cgi-bin/profile.py] Update Profile
```
## Submitting
When an `[in-submit]` is (clicked|tapped|activated with the
keyboard|etc) all named inputs on the page (submit buttons are not
named) will be added to the URL of the submit button as query
parameters, and the resulting URL will be loaded.
- easrng
-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210126/2d272f1c/attachment-0001.htm>