On some pages I see an entry field similar to an html form. I did not see any documentation explaining how to create and process an entry field. Can someone point me in the right direction? Thanks --
Can you give us an example? Devin Prater r.d.t.prater at gmail.com gemini://tilde.pink/~devinprater/ On Wed, Sep 8, 2021 at 1:54 PM Vlad Markov <dvoich at aim.com> wrote: > > On some pages I see an entry field similar to an html form. I did not see > any documentation explaining how to create and process an entry field. Can > someone point me in the right direction? > > Thanks > -- > >
gemini://geminispace.info/ Selecting the "Search" link brings up a field in which I can enter a search term. On Wed, 8 Sep 2021 13:58:15 -0500 Devin Prater <r.d.t.prater at gmail.com> wrote: > Can you give us an example? > Devin Prater > r.d.t.prater at gmail.com > gemini://tilde.pink/~devinprater/ > > > > On Wed, Sep 8, 2021 at 1:54 PM Vlad Markov <dvoich at aim.com> wrote: > > > > > On some pages I see an entry field similar to an html form. I did not see > > any documentation explaining how to create and process an entry field. Can > > someone point me in the right direction? > > > > Thanks > > -- > > > > --
On Wed, Sep 08, 2021 at 03:09:46PM -0400, Vlad Markov wrote: > Selecting the "Search" link brings up a field in which I can enter a > search term. That's actually just a link; when you go to that link, the server returns an "input requested" response. Your Gemini client handles this by displaying an input field. The details are in the protocol specification, specifically the bit about 1x response codes. -- pjvm
On Wed, Sep 08, 2021 at 03:09:46PM -0400, Vlad Markov <dvoich at aim.com> wrote a message of 29 lines which said: > gemini://geminispace.info/ > > Selecting the "Search" link brings up a field in which I can enter a search term. % agunua -d gemini://geminispace.info/search ... Header line: "10 Search query" Status code 10 means "INPUT" <https://gemini.circumlunar.space/docs/specification.gmi> The client tries again with the same URL and a query at the end. % agunua -d gemini://geminispace.info/search\?foobar ... "foobar" => gemini://gemlog.blue/users/foobar/1612432042.gmi gemlog.blue/users/foobar/1612432042.gmi (text/gemini, 44B) => gemini://gopher.zcrayfish.soy/I/users/zachary/foobar.jpeg gopher.zcrayfish.soy/i/users/zachary/foobar.jpeg (image/jpeg, 2K)
On Wed, Sep 8, 2021 at 2:54 PM Vlad Markov <dvoich at aim.com> wrote:
>
> On some pages I see an entry field similar to an html form. I did not
see any documentation explaining how to create and process an entry field.
Can someone point me in the right direction?
>
> Thanks
Greetings! This does not answer your question but it's tangentially
related and some might find it interesting.
A while ago I designed a protocol that's similar to gemini called
"spartan". It borrows the gemtext document format and adds one
"unofficial" line type for prompting input [0]. It looks like this
=: /link Enter your input
I honestly think this is a flat-out improvement over gemini's "10
INPUT" status (and I rarely say that). It avoids an extra round trip,
allows for better client UX, and is probably more intuitive. It's also
easy to replicate the gemini INPUT response behavior. For example,
10 Enter your input
would become
20 text/gemini
=: . Enter your input
Best,
Michael
[0] https://portal.mozz.us/spartan/spartan.mozz.us/specification.gmi#4-document-format
On Fri, 2021-09-10, mbays wrote:
>=> /link? Enter your input
I kind of like it, but I don't think adopting such a convention is worth
the trouble. It has strange edge cases and it can be confusing.
Ideally this would be a client-only signal, which can be achieved with
an empty fragment identifier:
=> /link# Enter your input
But that just doesn't look right. :)
>* Clients could render such links differently, e.g. with an inline text
>box.
Multiple text boxes might give the false impression of a form.
>every CGI implementation I've seen won't differentiate between "/link"
>and "/link?".
The problem is in the CGI spec:
https://datatracker.ietf.org/doc/html/rfc3875#section-4.1.7
The server MUST set this variable; if the Script-URI does not include
a query component, the QUERY_STRING MUST be defined as an empty
string ("").
So in order for a CGI script to do what you suggest:
>* Doesn't break clients who ignore the convention, as long as the server
>returns 10 to a request with empty query.
it would have to return 10 in response to both "/link" and "/link?",
which is not something we can expect everyone to do. For instance, I
have a script which requests input only on "/link?input", and returns
an intro page when the query is empty.
On Sun, Sep 12, 2021 at 11:33 AM mbays <mbays at sdf.org> wrote:
>
> * Sunday, 2021-09-12 at 14:53 +0000 - nervuri <nervuri at disroot.org>:
>
> >On Fri, 2021-09-10, mbays wrote:
> >>=> /link? Enter your input
> >
> >So in order for a CGI script to do what you suggest:
> >
> >>* Doesn't break clients who ignore the convention, as long as the
> >>server returns 10 to a request with empty query.
> >
> >it would have to return 10 in response to both "/link" and "/link?",
> >which is not something we can expect everyone to do.
>
> Yes. So the problem is that people might create links using this
> convention without first checking that the target does return 10 on
> empty query, breaking compatibility with clients not following the
> convention.
>
> I think I agree that this is enough of a problem to make the convention
> a Bad Idea. Shame!
>
> It could still make sense as part of the gemini spec itself, but I'm not
> going to suggest that.
Let's generalize this a bit more:
If a gemini URL contains a query string, the client can show an edit
textbox with the existing query string as the pre-filled or suggested
value. The user can then edit the text, or submit it as-is (the
latter would preserve the existing behavior).
For example:
gemini://example.com/input?default%20text
The client would show an input textbox prefilled with "default text".
Of course, this still doesn't solve the case where you want to show an
blank textbox to the user, but you could add a special case like:
If the query string contains a single question mark,
e.g. "gemini://example.com/input??", the client can set the suggested
text to an empty string "".
I don't like this part as much though, so maybe just keep the first
part.
Pros:
- Doesn't abuse URL semantics.
- Fully backwards compatible.
- More secure, as the user will see the query string before they
click on it (prevents malicious URLs). Clients could even take
this a step further and outline the textbox in yellow or red if
the URL is for a cross-domain.
> Multiple text boxes might give the false impression of a form.
I think as long as each textbox has a dedicated "submit" button this
won't be so bad. Based on the original email it sounds like some
clients are already doing this anyway.
- Michael
> But that leaves the question of how the user is meant to know whether they're intended to edit the text or leave it as is. There's plenty of current usage with links with non-empty query component which are meant to be kept. Maybe this is the main problem of the web => non conscient GET request :-)
---