💾 Archived View for soviet.circumlunar.space › oak › mailinglist › 7.gmi captured on 2023-01-29 at 03:12:46. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
Date: Mon, 25 Jan 2021 23:17:29 -0800
Hi all,
I have just started to get into Gemini, now running a simple server locally
with the Kristal client to test things out.
Reading the draft spec, I see there are only two ways to obtain input from
the
user -- via responses 10 and 11 (INPUT and SENSITIVE INPUT).
While this allows simple single-field entry of values to the server, there
appears to be no facility to allow users to enter multi-field, structured
data in a single operation -- that is, simple forms.
If it does not violate the fundamental tenets of the Gemini project, I
humbly
suggest an extension to the syntax of gemtext in the following manner to
enable structured multi-field forms. The logic and work here would be ~90%
on
the client side, as it is mostly a convention for encoding structured forms
within .gmi documents, parsed and acted on by the client. Form submission
would require no additional core server-side logic; interpretation of
submitted form values would follow the standard patterns of request handling
with URL query parameters.
No client or server state would be introduced.
I have used an encoding similar to what follows successfully in a past
'minimal HTML' project, to generate simple forms dynamically (but on the
server-side). I hope it might serve well to allow Gemini users a more
convenient way to interface with back-end programs, whilst preserving the
overall ethos of minimalism and privacy.
If the idea of adding a new link type to the gemtext specification is
anathema,
please consider the proposal as a purely client-side convention,
displayed but otherwise ignored by existing clients as part of the
<USER-FRIENDLY LINK NAME> portion of the existing '=>' syntax instead.
--
PROPOSAL
5.5.4 Link line form encoding
Lines beginning with the two characters "?>" are form-link lines, which
follow
the same rules as standard Link lines [5.4.2], plus a <FORM-SPEC> section
preceding the <USER-FRIENDLY LINK NAME>:
?>[<whitespace>]<URL>[<whitespace>]<FORM-SPECS><whitespace>[<USER-FRIENDLY
LINK NAME>]
where:
<whitespace> is any non-zero number of consecutive spaces or tabs
Square brackets indicate that the enclosed content is optional.
<URL> is a URL, which may be absolute or relative.
<FORM-SPEC> is a list of one or more <form-field-specifier> items, separated
by the Unicode/ASCII forward-slash '/'. The client uses <FORM-SPEC> to
build
a form entry popup, dialog, or series of input prompts to gather structured
user input.
Each <form-field-specifier> follows the form
T#VAR#DEFVALUE#LABEL
where T ? [ s | c | b ]
's' denotes a string (freeform data) field;
'x' denotes a string/number SENSITIVE field, which the client MUST shroud as
password-type data;
'c' denotes a choice (dropdown/one-of) field;
'b' denotes a boolean ( checkbox, yes/no ) field
's' fields are freeform text, and may be used for numbers, text, or freeform
data. It is the server's responsibility to validate submitted data.
For 'c' fields, the first choice is the default, all following choices being
delimited from it and each other by the pipe '|' character.
For 'b' fields, allowable DEFVALUEs are [0 | 1], [yes | no], or [on | off].
The
client is responsible for detecting these and returning sensible
counterparts to the DEFVALUE if the user chooses their opposites.
VAR denotes the name of the form variable when submitting back to the server
upon submission.
DEFVALUE denotes the default value to be displayed in the form. For choice
type fields, the first item in the choice list is the default.
LABEL is text to be displayed by the client explaining the form field.
Clients
MUST use the VAR field as a default LABEL if the .gmi link omits one.
A valid <FORM-SPEC> field is of the form
<form-field-specifier>{/<form-field-specifier>/...}
Example - three field form requesting a string, a choice, and a boolean
s#DELAY#5#Delay in seconds/c#SIZE#small|big|huge#Size of
something:b#DEBUG#1#
Note the above example has no LABEL for the final form field, so the client
should render a default label using the form variable's name, 'DEBUG'.
This would instruct the client to display a form, popup or series of prompts
(in the case of a text-based client) to enter three items.
The choice field would default to 'small', the first item in its set.
The client would return a URI upon submission with the query parameters
?DELAY=5&SIZE=small&DEBUG=1
if the user submitted with default values.
A fully-realized example of this proposed syntax would thus be
?> gemini://example.org/formSubmit s#DELAY#5#Delay in
seconds:c#SIZE#small|big|huge#Size of something:b#DEBUG#1# Please fill out
this handy form
Suggested limits on form structure and data
Max <form-field-specifiers>: 8
Max <form-field-specifier> sub-field lengths
(VAR, DEFVALUE, LABEL): 255 Unicode characters
Max 'c' type choice length per item: 64 Unicode characters
Max 'c' type choices: 64
Max 's' value: enforced by server-side endpoint handler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210125/f3a3aeec/attachment.htm>
--------
Date: Tue, 26 Jan 2021 13:43:10 +0100
Russtopia <rmagee at gmail.com> wrote:
Hi all,
Hi!
[... form proposal ... ]
The issue is that Gemini (and gemtext) is too close to being frozen
forever. And most Gemini content out there doesn't need to use forms.
I have an alternative proposal: make the form on a new page, and use
something other than gemtext for it (and possibly something other than
Gemini the protocol). I suggest instead making a gemtext-derived format
that is specially suited to forms, which has special line types and
stuff as necessary (in fact, I suggest adding a similar line type to the
one you gave in your proposal). You could probably borrow from a lot of
the gemtext spec directly. It would be best to use one of the
Gemini-analogue protocols which allow uploading (I know of Dioscuri,
Titan, and Inimeg) so that users could submit the form by performing an
upload process to the same URL. Using a different protocol would be
best as then there are no upload limitations; with Gemini, the URL given
by the client has to be less than ~1024 bytes, which is not suited to
all forms.
~aravk | ~nothien
--------
Date: Tue, 26 Jan 2021 08:43:44 -0500
nothien at uber.space writes:
Russtopia <rmagee at gmail.com> wrote:
> [... form proposal ... ]
The issue is that Gemini (and gemtext) is too close to being frozen
forever. And most Gemini content out there doesn't need to use forms.
This is my personal opinion, but I would go further and say that Gemini
doesn't need forms. If you have fully featured forms, you can implement
largely any kind of application (excluding very interactive ones), and
in the history of the web, this lead to re-implementing the whole
internet over port 80. I don't think Gemini needs to do that. The one
input lets you select different dynamic versions of a page, like for
different locales, or search results, or similar.
Having more complex forms is a temptation to implement applications on
Gemini, rather than using pairings of protocol+client that are more
appropriate (e.g. using NNTP for a message board).
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
--------
Date: Tue, 26 Jan 2021 11:25:32 -0800
On Tue, 26 Jan 2021 at 05:43, Jason McBrayer <jmcbray at carcosa.net> wrote:
nothien at uber.space writes:
> Russtopia <rmagee at gmail.com> wrote:
>> [... form proposal ... ]
> The issue is that Gemini (and gemtext) is too close to being frozen
> forever. And most Gemini content out there doesn't need to use forms.
This is my personal opinion, but I would go further and say that Gemini
doesn't need forms. If you have fully featured forms, you can implement
largely any kind of application (excluding very interactive ones), and
in the history of the web, this lead to re-implementing the whole
internet over port 80. I don't think Gemini needs to do that. The one
input lets you select different dynamic versions of a page, like for
different locales, or search results, or similar.
Having more complex forms is a temptation to implement applications on
Gemini, rather than using pairings of protocol+client that are more
appropriate (e.g. using NNTP for a message board).
Point well taken -- I know it is a slippery slope, but I still think forms
could be
supported in a manner which keeps complexity down.
This form-builder idea could be implemented with no protocol changes,
100% client-side, within the existing => link syntax. To be user-friendly,
it would
require some sort of agreement by clients on the FORM-SPEC syntax.
Consider if clients agreed to act on documents ending in .gmif
('gemini-form'):
This is a form link, click to fill out
.. clients could, by convention, parse such .gmiform files containing the
FORM-SPEC
using it to build a dynamic entry form. After form entry, the client would
encode it and send back
to the same endpoint (here, form.gmif) so the server could act on the
values.
For clients that did not choose to implement forms, they would by default
simply display .gmif
documents as any other plaintext resource.
The .gmif document holding the <FORM-SPEC> could even have comments with
instructions
on how to manually create a query to the endpoint, for users of older
clients eg:
[form.gmif]
s#DELAY#5#Delay in seconds
c#SIZE#small|big|huge#Size of something
b#DEBUG#1#
// If you are seeing this page, your gemini client does not support
automatic dynamic forms.
// You can still use this service by building a FORM-SPEC matching the
above syntax and
// pasting it to this page's URI, eg:
// gemini://example.site/form.gmif?DELAY=5&SIZE=small&DEBUG=1
As ~nothien points out, there's a limit of ~1024 bytes on URLs which I
think is a good thing;
working within the protocol as-is will naturally force relatively small,
simple forms.
So I guess I'm now proposing an optional client-side '.gmif' form standard
:)
-Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210126/f34c1343/attachment.htm>
--------
Date: Tue, 26 Jan 2021 18:16:30 -0500
I agree that Gemini should have forms, but that format doesn't look
great to me. What if forms were implemented as their own pages, not a
new link line type? I'm thinking something like this:
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.
In order to allow for ] characters, newlines, and literal backslashes
in input options, preface them with a backslash.
Other types could be added, like number, email, phone, color, or even
file, but I feel this is an acceptable minimum set of types.
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?
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?
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
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
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
--------
Date: Tue, 26 Jan 2021 19:55:41 -0800
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'd
come 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-of
types 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 or
choose 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>
--------
Date: Wed, 27 Jan 2021 10:27:06 +0000
On Tue Jan 26, 2021 at 1:43 PM GMT, Jason McBrayer wrote:
Having more complex forms is a temptation to implement applications on
Gemini, rather than using pairings of protocol+client that are more
appropriate (e.g. using NNTP for a message board).
I agree with this completely. I think Gemini should be a protocol for viewing
content only. I missed all the discussion around inimeg, titan etc. at the time
but I feel similarly about those.
I think a different protocol for filling out forms makes a lot more sense, and
we can work on having gemini clients and form clients play nicely together so
the user experience doesn't suffer from using a different program to fill out a
form.
Adding forms would take us wayyyyy too close to the web in my opinion.
Charlie (shtanton)
--------
Date: Wed, 27 Jan 2021 18:37:56 +0100 (CET)
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.
To 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.
Binary 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.
The 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.
Choice 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.
Finally, 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.
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 :)
--------
Date: Wed, 27 Jan 2021 13:13:22 -0500
On January 27, 2021 3:55:41 AM UTC, Russtopia <rmagee at gmail.com> wrote:
I do feel like there should be some explicit allowance for one-of
types 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 or
choose a-b-c-d for a text-based client, and checkboxes). IMHO.
I agree that there should me checkboxes, but I think radio buttons are more
in the spirit of Gemini than menus.
RE: Keeping Gemini simple, what if forms were a separate MIME type like
text/form+gemini? I think forms are important to have because unlike ex.
file uploads I don't know if there is another lightweight solution. The
only options I can think of for form filling and submission are PDF forms,
but those are only really usable in Acrobat and HTML forms, which I suppose
we could serve over Gemini but often require JavaScript to function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210127/5cb5f193/attachment.htm>
--------
Date: Wed, 27 Jan 2021 19:52:38 +0100
I think this should have a [TECH] tag? [1]
I am quite firmly on the "Gemini does not need forms" side. At least as far as implementing additional syntax in clients. For some clients it might be a big leap to have to implement this, especially considering you can already build forms in Gemini, you just have to get a bit creative and it does not require any new syntax or behaviour on the client side. And thus no additional specification. But again: One should think twice if this really has to be implemented using Gemini and not another, more suited protocol.
The basic idea is the following: Each form field is presented on a separate "page" and the server keeps track of where the client is in the form. Ideally the URL (URI/IRI?) contains all the data necessary, thus "saving" the data on the client so it might be continued at a later date. If the amount of data expected is larger than would fit in the URL, server side state with client certificates would be an alternative.
Now to the different types of input fields. I assume the form's base is gemini://example.com/form/ which might display some information about the form and the first input field.
On 27.01.2021 18:37, me at edaha.org wrote among?other?things:
> # binary
> Binary options are best known as checkboxes on the web. They're simple on/off toggles. How they are displayed is up to the client
A check box can be simply implemented with two links for yes and no like this for example:
Does Gemini need forms? => 0/ No, it does not. => 1/ Yes, it does.
These two links would then direct the client to either <gemini://example.com/form/0/> or <gemini://example.com/form/1/> respectively. Now the server would have to understand that this still belongs to the form and it should serve the next input field page. In this example I just put each input in a path segment as that is the first thing I came up with. You could of course put this in the query, separate it with spaces, commas semicolons or something completely different.
A nice side effect of doing it this way is that you could in theory build this from a static site server by creating respectively named directories and index.gmi files (or whatever your server happens to use).
> # text
> The bulk of data that we could ever ask for is just 'text'.
We already have this (and passwords too!) with status codes 10 and 11. So when you go to either of the URLs in the example above, the server will have to respond with that status code. Upon receiving the data it might redirect the client so that the URL holds some representation of the data, say for example to <gemini://example.com/0/42/>.
> Differentiating between "tel" "num" and "text" should be done server-side, as these are all still just text fields.
I completely agree.
> "password" is deliberately not supported -- this is why gemini has client certs.
Odd choice considering Gemini already has support for this.
> If an input should be multi-line, then the following could be used: [...]
That is not something that could be implemented by using Gemini this way [2], but if you want to write big amounts of text, you should really use something else, e.g. file upload (ftp) or maybe email, irc, xmpp, nntp, etc.
> # choice
> Choice 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
This could be implemented just like a checkbox, just with more options. Coincidentally the syntax is very similar to the one proposed.
Which of these protocols are we using? => gemini/ gemini => gopher/ gopher => http/ HTTP
> # submit
> Finally, submit. This one's easy:
... because it is not necessary. The server will just show you the result or take the respective action after the last form field is filled. Maybe a final checkbox of "Are you sure" would be nice to let the user know that this will result in some action.
> # 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.
And as I said above, you can pass these however you like, although I would guess using the path segment approach would be the easiest and best supported. If I recall correctly there were different opinions voiced about carrying on a query in a redirect. So who knows what some clients might do if the data is all stored in the query and a user decides to go to the next form field.
> and that's it!
... we do not need an additional specification for this. If you insist on implementing forms in Gemini, you already can - it just requires you to think a bit, and the solution might addmittedly be a bit clunky. But that's because Gemini is not meant for doing forms!
I hope this was not too bad of a rant but actually helpful.
Johann
[1] https://lists.orbitalfox.eu/archives/gemini/2020/004142.html
[2] Maybe you could have the users type in some escaped line feeds, but the specification says: "The requested resource accepts *a line* of textual user input." (? 3.2.1, emphasis mine)
---
You can verify the digital signature on this email with the public key available through web key discovery. Try e.g. `gpg --locate-keys`...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210127/570d7ce5/attachment-0001.sig>
--------
Date: Thu, 28 Jan 2021 18:00:25 +0100
When this topic have come up in the past, we have concluded that Gemini can
support forms with serial input fields, as opposed to the parallel input
fields people are used to from web forms.
One way to do this is to send status 10 until all the fields are satisfied,
like a CLI. Another way is to have a page with links pointing to one field
at a time.
Johann Galle <johann at qwertqwefsday.eu> wrote:
The basic idea is the following: Each form field is presented on a
separate "page" and the server keeps track of where the client is in the
form. Ideally the URL (URI/IRI?) contains all the data necessary, thus
"saving" the data on the client so it might be continued at a later date.
If the amount of data expected is larger than would fit in the URL, server
side state with client certificates would be an alternative.
I haven't seen this approach yet, seems just as valid as the other ones.
Now to the different types of input fields. I assume the form's base is
gemini://example.com/form/ which might display some information about the
form and the first input field.
On 27.01.2021 18:37, me at edaha.org wrote among other things:
> # binary
> Binary options are best known as checkboxes on the web. They're simple
on/off toggles. How they are displayed is up to the client
A check box can be simply implemented with two links for yes and no like
this for example:
```
Does Gemini need forms?
=> 0/ No, it does not.
=> 1/ Yes, it does.
```
Asking a question like this is not a good example for showing off
checkboxes but another way is to send this:
10 Does Gemini need forms? [yes/no]
...and repeat until the user supply a valid answer.
Multiple choice checkboxes can be combined into one input:
10 My server supports: [c: CGI, v: virtual host, s: sessions]
...and the user can answer "sv" or "cs" or "v" or whatever other valid
combination.
[...]
> # choice
[...]
This refers to a single choice among a list of things.
> <= choice Which of these protocols are we using?
> <= choice gemini
> <= choice gopher
> <= choice HTTP
This could be implemented just like a checkbox, just with more options.
Coincidentally the syntax is very similar to the one proposed.
```
Which of these protocols are we using?
=> gemini/ gemini
=> gopher/ gopher
=> http/ HTTP
```
This would be:
10 Which of these protocols are we using? [gemini/gopher/http]
...in that same example. Though, I do like the links better.
> # submit
> Finally, submit. This one's easy:
... because it is not necessary. The server will just show you the result
or take the respective action after the last form field is filled. Maybe a
final checkbox of "Are you sure" would be nice to let the user know that
this will result in some action.
Or just "Confirm sending this information"
--
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210128/272c292c/attachment.htm>
--------