💾 Archived View for rawtext.club › ~sloum › geminilist › 007103.gmi captured on 2023-09-08 at 16:43:19. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

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

<-- back to the mailing list

[tech] trailing '?' for input (was: entry field in gemtext)

Michael Lazar lazar.michael22 at gmail.com

Sun Sep 12 17:20:54 BST 2021

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

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 edittextbox with the existing query string as the pre-filled or suggestedvalue. The user can then edit the text, or submit it as-is (thelatter 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 anblank 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 suggestedtext to an empty string "".

I don't like this part as much though, so maybe just keep the firstpart.

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 thiswon't be so bad. Based on the original email it sounds like someclients are already doing this anyway.

- Michael