Hello all Just recently joined your email list after lurking for a while (via HN). I like the look of gemini, hopefully it can hit a sweet spot of simple hypertext without the baggage of the full web infrastructure. I think gemini is interesting. And I particularly have enjoyed reading the discussion about text formatting and bullets... no, seriously. I'm interested in user interfaces and cognitive aspects of hypertext among other things. My question is really about how we can support cognitive aspects of user navigation through gemini-space. I understand and largely endorse the reasons for the simple text based protocol and format. However at the moment, browsing gemini-space is a very homogenous experience (each page looks the same as others). So it is not so clear to the user whose page you are on. On the wider web, there is a stronger notion of place, which has become very brand heavy and each website is a graphic masterpiece in its own right. There is a "cost" to that clearly. Is there a simple and gemini-friendly way for us to (optionally!) convey this sense of place. For example, to set a simple global favicon or background colour for pages on a certain site. It could help with user's task of navigation and understanding exactly where they are. I know there are lots of CLI junkies around here, so maybe this hasn't been a priority so far. I'm not proposing anything heavy or like the www, but I feel there could be some simple sweet spot here to be investigated. Best wishes - Luke
> Just recently joined your email list after lurking for a while
Welcome! Glad to have you here (keep that in mind as I disagree with you below).
> Is there a simple and gemini-friendly way for us to (optionally!) convey
> this sense of place.
At present I think Konpeito Media (gemini://konpeito.media) is a great
example of providing what you are talking about.
They offer color, as well as a non-color mode. Many gemini capsules also
use figlet fonts or other forms of ascii and unicode
art.
My feeling is that gemini inherits more from gopher than from the web.
Including a lot of the culture that has surrounded it in its early days.
That doesnt mean that things need to stay that way, though I admit my
preference is to avoid styling almost entirely. Styling, to me, misses the
point: that the content is the important thing.
> browsing gemini-space is a very homogenous experience
I think I disagree with this. I think coming from the web, yes that may be
true. But users that have been using gopher have had the
mental shift to interacting with this sort of content for quite some time
and the subtle differences in how text is arranged can have
a big impact and really create a style and flavor for each capsule. It
just takes a little distance from the maximalism that is the web.
People that drink a 2-litre of cola each day are used to sweet and think
that a sparkling water with a bit of lime has no flavor. But if
you stop drinking soda for awhile your taste starts to return to a more
normal realm. I think this is true of gemini and gopher as well
when contrasted with the web.
As you likely read in the discussions surrounding bullets, there is
definitely nothing stopping servers and clients from serving up and
rendering html or markdown and having the styling that comes with those. I
cannot speak for everyone, but my feeling is that the
text/gemini format is intended to be very simple and to allow consistent
display across devices (many of which do not support color
or font size changes).
I would definitely be interested to see if we can find some ways of
achieving what you are talking about by creating a culture and
community that finds creative ways to use text to really give gemini a
feel of its own. While I cited Konpeito above, I know that
the escape sequence thing is a fun hack, but that graphical clients will have trouble.
I do think we should be providing alt text to ascii art blocks, maybe like so:
```smiley face
o o
.
\___/
```
Anyway, sorry for the opinionated ramble. Really: truly glad to have your
voice in the discussion (as well as all of the other recent
new folks to this mailing list and to gemini in general).
--?
Sent with https://mailfence.com
Secure and private email
On Thu, May 14, 2020 at 11:56 AM Luke Emmet <luke.emmet at gmail.com> wrote: > Is there a simple and gemini-friendly way for us to (optionally!) convey > this sense of place. For example, to set a simple global favicon or > background colour for pages on a certain site. It could help with user's > task of navigation and understanding exactly where they are. I know > there are lots of CLI junkies around here, so maybe this hasn't been a > priority so far. > > I'm not proposing anything heavy or like the www, but I feel there could > be some simple sweet spot here to be investigated. Hi! I really appreciate that you brought up favicons. I've also been thinking about how they might be a fun and useful way to give a bit of "personality" to sites as they appear in bookmark lists, etc. The original implementation of favicons on the web was so simple and nice. Just plop a favicon.ico file in your root of your directory and you're done! Now on the modern web, it's gotten complicated with every browser having their own conventions on what the optimized size/format should be. So you end up needing to use a tool to generate 8 different file formats and link to them to using various <meta> tags in the page header. I think utilizing unicode characters, specifically emojis, might be an elegant solution to this problem. They're scalable to any resolution and standard enough to provide a uniform experience across sites. A content author wouldn't need to worry about their image being transparent or looking like crap on higher resolutions, for example. And of course, they would work on terminal clients too! My proposed convention would be something like this gemini://my-site.com/favicon.txt This resource should be optional. If it exists, it should contain a single unicode character (the exact semantics of what a "character" is would need to be ironed out). Clients may chose to display this character alongside links or in the page title bar. Regards, Michael
Howdy, On Thu, May 14, 2020 at 04:55:56PM +0100, Luke Emmet wrote: > And I particularly have enjoyed reading the discussion about > text formatting and bullets... no, seriously. Seek help! :p Just kidding, welcome to Gemini! > My question is really about how we can support cognitive aspects of user > navigation through gemini-space. I understand and largely endorse the > reasons for the simple text based protocol and format. However at the > moment, browsing gemini-space is a very homogenous experience (each page > looks the same as others). So it is not so clear to the user whose page you > are on. I understand entirely where you are coming from. An idea I've had for a while now (I don't remember if I've mentioned it here before) is that it would be nice if a graphical Gemini browser used a different foreground and background colour (and perhaps even a different font?) for different domains (subdomains)? This would be something the client would do itself, with no possibility of control or influence from the server - it would just use the domain as the seed to a PRNG which chose a new scheme. This would then give different sites their own subtly distinct look and feel, which a user could learn to recognise in time. I have no idea how feasible this is: programmatically generating genuinely pleasant colour schemes is certainly not straightforward. > Is there a simple and gemini-friendly way for us to (optionally!) convey > this sense of place. For example, to set a simple global favicon or > background colour for pages on a certain site. It could help with user's > task of navigation and understanding exactly where they are. I know there > are lots of CLI junkies around here, so maybe this hasn't been a priority so > far. The idea of favicons has been mentioned before in a gemlog post: gemini://mozz.us/journal/2020-04-17.gmi I have a couple of big concerns here: One is that right now Gemini is strictly one-request-per-resource and a lot of people, myself included, consider that a really desirable property. Anything like favicons or CSS would remove that property, no matter how light weight they were. It's true that at least the second request would go to the same server as the first so this doesn't actually destroy predictability or control of which servers your client connects to, which is one of the arguments in favour of the one request thing. Another is that, philosophically, I kind of feel like styling *should* be under the control of the client and not the server. Some people have strong preferences for light text on dark backgrounds, for example, because they have problems with eye strain the other way around. Right now on the web this is really only possible if the author deigns to provide the option (as Stack Overflow recently did, to much fanfare). I think that's totally backwards. Give the power over styling to the people who actually have to read the content, let them read your stuff in the way that works best for their eyesight and that *they* find aesthetically pleasing. I realise this reduces some of the scope for self-expression on the part of Gemini content authors, but there's more than enough scope for that in the actual *content* they produce (if not, there are bigger problems...). (of course, this is kind of a weak argument against CSS-light in Gemini, because actually honouring the settings would be optional and clients could ignore them and use the user's preferences instead) The biggest concern is (no surprises to regular readers here!) is that it's really hard to do this in a way that's not extensible. With the best of intentions we'll specify a strictly optional CSS-ultralight thing which can only choose background and foreground colours from a small fixed pallette...and then some client will implement one extra optional feature, and it'll be popular, so then other clients will copy it, and the whole thing snowballs until people start to think of these unofficial extensions as a real part of Gemini, and strictly spec-adherent clients which don't support them as "broken". This exact story happened many times over with the web and I'm terrified of the same things happening to Gemini. It's why I've tried at every turn in this project to avoid adding in anything that feels like it will be really easy to extend in new directions. I'm not opposed to hearing ideas, but I have a hard time imagining much can be done in the way of ultralight optional styling which doesn't violate the non-extensibility principle. I'd be much more interested in us exploring innovative possibilities which are strictly under the control of the client, like keying the styling to the domain as I mentioned earlier. I'm not saying that exact approach necessarily is the best way to do it, or even a good way. But it's *a* way to do it which doesn't run afoul of any of the issues above and that kind of out-of-the-box thinking is a good direction to take, IMHO. Hope you're not too disappointed by this response, feel free to (politely, constuctively!) argue back against any of this. Thanks for your interest and welcome to Gemini! Cheers, Solderpunk
On Thu, May 14, 2020 at 07:06:19PM +0200, Brian Evans wrote: > I do think we should be providing alt text to ascii art blocks, maybe like so: I've kind of wondered about this too. Specifically, I started wondering about this after the recent styling changes at typed-hole.org (sorry to pick on you, Julien!). The new figlet-generated (I assume?) section headers look really great, but they're not great for accessibility (a screen reader won't know how to read them) and they're not great for searchability (a GUS search for words used in one of them won't turn up results). I'm kind of torn here. A lot of folks are doing very cool things with ASCII/ANSI art and colour escape codes in Geminispace. I love the way it looks, and coming from the Gopher culture myself I totally understand and appreciate this urge. I really don't want to publically condemn these practices and seem like a creativity-destroying jerk who wants Geminispace to be bland and depersonalised and black and white. But there *are* a lot of non-trivial problems with this stuff: on top of accessibility and searchability, Sean has mentioned potential security problems with handling ANSI escape codes from untrusted sources... Cheers, Solderpunk
On 5/14/20 6:21 PM, solderpunk wrote: > it would be nice if a graphical Gemini browser used a different > foreground and background colour (and perhaps even a different font?) > for different domains (subdomains)? That sounds like a really nice feature that some people would value in a client that offered it. If, while browsing gemini, I could quickly set the colors or styling on a domain level it could be neat to visually separate places I go routinely. Some users might value that feature enough to choose a client that offers it. Others wouldn't care. Another option on the client level would be to hash the domain into a color code of some sort, dynamically creating variation in the backgrounds to a reasonable degree (shades of grey? below a certain lumen?). That would give the user an obvious indication if a link followed changed domains. Again, it might be of value to somebody and others won't care. We're getting a plethora of clients popping up. Maybe some of these new ones want a way to differentiate themselves. I'd suggest that putting any and all of these levels of control into the client's hands would be great for gemini long term. The problems come when we want to solve these things server-side.
On 5/14/20 6:33 PM, solderpunk wrote: > he new figlet-generated (I assume?) section > headers look really great, but they're not great for accessibility (a > screen reader won't know how to read them) and they're not great for > searchability (a GUS search for words used in one of them won't turn up > results). It's a really tough situation and you nailed it on the head. Code fencing can be used for creative art or for literally preserving whitespace on indexable content. It would be nice to indicate to both screen readers and search engines which is which. I hesitate to even offer a solution because it gets too close to our heated code fencing & list markup discussion, but... As code fences currently begin with ``` and end with ``` We could use the starting code fence to indicate whether the content is art or not, or parseable as text or not. ```text ```art or some ARIA-esque token. I was originally thinking that the text following ``` could be a literal alt text. I dunno. Just throwing out ideas. solderpunk, please don't shoot me.
On Thu, May 14, 2020 at 01:50:11PM -0400, Michael Lazar wrote: > This resource should be optional. If it exists, it should contain a single > unicode character (the exact semantics of what a "character" is would need > to be ironed out). Clients may chose to display this character alongside > links or in the page title bar. Huh! That is pretty non-extensible! Compared to something like a file full of key=value pairs for CSS-like properties, I mean. Cheers, Solderpunk
Tomasino writes: > We could use the starting code fence to indicate whether the content is > art or not, or parseable as text or not. I actually really like this idea. I previously had thought a literal alt text there as well. But differentiating crawlable content seems useful. It could also tell screen readers whether or not to attempt to read the content or not. I propose, also very hesitantly, that the following be optional elements to code fences: - The opening fence can be followed by a flag value of text or art (or some other words that get decided upon, maybe even a or t) - The closing fence can be followed by alt text ```art 8-) ``` Googly eyed smiley face ```text I am a short thing with literal spacing ``` Alt text may or may not be needed for a text style fence but an art one almost certainly could benefit from it. A system like this would give clients and users the ability to communicate things based on user preference (ie. a screen reader user only wanting alt text for art with no attempt to read the actual content in the fence, or a different user only wanting the content but not the alt). Anyway, interesting ideas. --? Sent with https://mailfence.com Secure and private email
Hello
> I understand entirely where you are coming from. An idea I've had for
> a while now (I don't remember if I've mentioned it here before) is that
> it would be nice if a graphical Gemini browser used a different
> foreground and background colour (and perhaps even a different font?)
> for different domains (subdomains)? This would be something the client
> would do itself, with no possibility of control or influence from the
> server - it would just use the domain as the seed to a PRNG which chose
> a new scheme. This would then give different sites their own subtly
> distinct look and feel, which a user could learn to recognise in time.
> I have no idea how feasible this is: programmatically generating
> genuinely pleasant colour schemes is certainly not straightforward.
This is interesting, something like the sigils in Urbit, or Gravitar
that are automatically generated from
some identifier?
https://urbit.org/blog/creating-sigils/
https://en.gravatar.com/site/implement/
And so when you were on a "site" the content would be labelled/decorated
in a simple yet consistent way
I think that could work.
If it is for the client to decide, how do we determine the "scope" of a
site:
1. If it is one per domain then that works, but I suppose that is not a
universal
assumption a client can make as many gemini spaces might be hosted
on the same domain.
2. Full path - is very specific, but it would mean the placemarker would
change with every request.
3. The author indicates it somehow
4. ?
It would be good perhaps if the author could optionally provide a seed
site id as part of the content.
e.g. "site-name: Mysite" or other such pre-defined, not extensible
syntax (we have headings, bullets, links...). Maybe the @symbol is
awaiting such a role
"@ MySite"
This can be ignored by any disinterested client and is just text in the
document that CLI readers can read without polluting the content with
metadata.
> The idea of favicons has been mentioned before in a gemlog post:
>
> gemini://mozz.us/journal/2020-04-17.gmi
>
> I have a couple of big concerns here:
>
> One is that right now Gemini is strictly one-request-per-resource and a
> lot of people, myself included, consider that a really desirable
> property. Anything like favicons or CSS would remove that property, no
> matter how light weight they were. It's true that at least the second
> request would go to the same server as the first so this doesn't
> actually destroy predictability or control of which servers your client
> connects to, which is one of the arguments in favour of the one request
> thing.
I don't see the single request per resource is really violated here,
since it is optional and not required to understand the content. But if
that is really a worry
the client side option might work.
Maybe the favicon thing is just a convention that authors could include
or not. The client could search up the url path and show the first one
it finds, or none
> Another is that, philosophically, I kind of feel like styling *should*
> be under the control of the client and not the server.
That is OK, but maybe the server can hint.
> Some people have
> strong preferences for light text on dark backgrounds, for example,
> because they have problems with eye strain the other way around.
Agree
> Right
> now on the web this is really only possible if the author deigns to
> provide the option (as Stack Overflow recently did, to much fanfare). I
> think that's totally backwards. Give the power over styling to the
> people who actually have to read the content, let them read your stuff
> in the way that works best for their eyesight and that *they* find
> aesthetically pleasing. I realise this reduces some of the scope for
> self-expression on the part of Gemini content authors, but there's more
> than enough scope for that in the actual *content* they produce (if not,
> there are bigger problems...).
>
> <snip>
> I'd be much more interested in us exploring innovative possibilities
> which are strictly under the control of the client, like keying the
> styling to the domain as I mentioned earlier. I'm not saying that exact
> approach necessarily is the best way to do it, or even a good way. But
> it's *a* way to do it which doesn't run afoul of any of the issues above
> and that kind of out-of-the-box thinking is a good direction to take,
> IMHO.
--
______________________________________
Orlando Lutes
http://www.orlando-lutes.com
Hello
> I understand entirely where you are coming from. An idea I've had for
> a while now (I don't remember if I've mentioned it here before) is that
> it would be nice if a graphical Gemini browser used a different
> foreground and background colour (and perhaps even a different font?)
> for different domains (subdomains)? This would be something the client
> would do itself, with no possibility of control or influence from the
> server - it would just use the domain as the seed to a PRNG which chose
> a new scheme. This would then give different sites their own subtly
> distinct look and feel, which a user could learn to recognise in time.
> I have no idea how feasible this is: programmatically generating
> genuinely pleasant colour schemes is certainly not straightforward.
This is interesting, something like the sigils in Urbit, or Gravitar
that are automatically generated from
some identifier?
https://urbit.org/blog/creating-sigils/
https://en.gravatar.com/site/implement/
And so when you were on a "site" the content would be labelled/decorated
in a simple yet consistent way
I think that could work.
If it is for the client to decide, how do we determine the "scope" of a
site:
1. If it is one per domain then that works, but I suppose that is not a
universal
assumption a client can make as many gemini spaces might be hosted
on the same domain.
2. Full path - is very specific, but it would mean the placemarker would
change with every request.
3. The author indicates it somehow
4. ?
It would be good perhaps if the author could optionally provide a seed
site id as part of the content.
e.g. "site-name: Mysite" or other such pre-defined, not extensible
syntax (we have headings, bullets, links...). Maybe the @symbol is
awaiting such a role
"@ MySite"
This can be ignored by any disinterested client and is just text in the
document that CLI readers can read without polluting the content with
metadata.
> The idea of favicons has been mentioned before in a gemlog post:
>
> gemini://mozz.us/journal/2020-04-17.gmi
>
> I have a couple of big concerns here:
>
> One is that right now Gemini is strictly one-request-per-resource and a
> lot of people, myself included, consider that a really desirable
> property. Anything like favicons or CSS would remove that property, no
> matter how light weight they were. It's true that at least the second
> request would go to the same server as the first so this doesn't
> actually destroy predictability or control of which servers your client
> connects to, which is one of the arguments in favour of the one request
> thing.
I don't see the single request per resource is really violated here,
since it is optional and not required to understand the content. But if
that is really a worry
the client side option might work.
Maybe the favicon thing is just a convention that authors could include
or not. The client could search up the url path and show the first one
it finds, or none
> Another is that, philosophically, I kind of feel like styling *should*
> be under the control of the client and not the server.
That is OK, but maybe the server can hint.
> Some people have
> strong preferences for light text on dark backgrounds, for example,
> because they have problems with eye strain the other way around.
Agree
> Right
> now on the web this is really only possible if the author deigns to
> provide the option (as Stack Overflow recently did, to much fanfare). I
> think that's totally backwards. Give the power over styling to the
> people who actually have to read the content, let them read your stuff
> in the way that works best for their eyesight and that *they* find
> aesthetically pleasing. I realise this reduces some of the scope for
> self-expression on the part of Gemini content authors, but there's more
> than enough scope for that in the actual *content* they produce (if not,
> there are bigger problems...).
>
> <snip>
> I'd be much more interested in us exploring innovative possibilities
> which are strictly under the control of the client, like keying the
> styling to the domain as I mentioned earlier. I'm not saying that exact
> approach necessarily is the best way to do it, or even a good way. But
> it's *a* way to do it which doesn't run afoul of any of the issues above
> and that kind of out-of-the-box thinking is a good direction to take,
> IMHO.
--
______________________________________
Orlando Lutes
http://www.orlando-lutes.com
Hi Michael On 14-May-2020 18:50, Michael Lazar wrote: > I really appreciate that you brought up favicons. I've also been thinking > about how they might be a fun and useful way to give a bit of "personality" > to sites as they appear in bookmark lists, etc. > > The original implementation of favicons on the web was so simple and nice. > Just plop a favicon.ico file in your root of your directory and you're > done! Now on the modern web, it's gotten complicated with every browser > having their own conventions on what the optimized size/format should be. > So you end up needing to use a tool to generate 8 different file formats > and link to them to using various<meta> tags in the page header. > > I think utilizing unicode characters, specifically emojis, might be an > elegant solution to this problem. They're scalable to any resolution and > standard enough to provide a uniform experience across sites. A content > author wouldn't need to worry about their image being transparent or > looking like crap on higher resolutions, for example. And of course, they > would work on terminal clients too! > > My proposed convention would be something like this > > gemini://my-site.com/favicon.txt > > This resource should be optional. If it exists, it should contain a single > unicode character (the exact semantics of what a "character" is would need > to be ironed out). Clients may chose to display this character alongside > links or in the page title bar. I think that would be a nice start, perhaps with a colour hint to be considered by the client, but of course not everyone can map their identity onto a single unicode code point! I really like the Haiku small vector graphic format. It is a bazillion times simpler than SVG and makes for crisp icons and different resolutions https://www.haiku-os.org/docs/userguide/en/applications/icon-o-matic.html Regards - Luke
>> I do think we should be providing alt text to ascii art blocks, maybe like so: > I've kind of wondered about this too. Specifically, I started wondering > about this after the recent styling changes at typed-hole.org (sorry to > pick on you, Julien!). The new figlet-generated (I assume?) section > headers look really great, but they're not great for accessibility (a > screen reader won't know how to read them) and they're not great for > searchability (a GUS search for words used in one of them won't turn up Personally I find Ascii art or Figlet type fonts unattractive, but each to their own. Some clients for Gemini will be using non-fixed-width rendering fonts. But I suppose it they are wrapped in preformat blocks it is OK. > I'm kind of torn here. A lot of folks are doing very cool things with > ASCII/ANSI art and colour escape codes in Geminispace. I love the way > it looks, and coming from the Gopher culture myself I totally understand > and appreciate this urge. I really don't want to publically condemn > these practices and seem like a creativity-destroying jerk who wants > Geminispace to be bland and depersonalised and black and white > > <snip> > But there *are* a lot of non-trivial problems with this stuff: on top of > accessibility and searchability, Sean has mentioned potential security > problems with handling ANSI escape codes from untrusted sources... Colour escape codes seem like a Unix/terminal hack to me, they would look strange in a non CLI? They aren't very accessible (e.g. screen readers for the blind) and if there are security issues I think that has to be a serious consideration Best wishes - Luke
Hi Michael, Michael Lazar writes: > gemini://my-site.com/favicon.txt > > This resource should be optional. If it exists, it should contain a single > unicode character (the exact semantics of what a "character" is would need > to be ironed out). Clients may chose to display this character alongside > links or in the page title bar. Interesting - it sounds like this is a kind of client/publisher agreement that sidesteps the server entirely. Almost a super-protocol. In the sense that you, as publisher, are free to make whatever files you want available while I, as the client, am free to display your files in whatever way I like. (Think about how awkward it would be to _exclude_ this behaviour in the spec!) Tim
Hi James On 14-May-2020 19:42, James Tomasino wrote: > On 5/14/20 6:21 PM, solderpunk wrote: >> it would be nice if a graphical Gemini browser used a different >> foreground and background colour (and perhaps even a different font?) >> for different domains (subdomains)? > That sounds like a really nice feature that some people would value in a > client that offered it. If, while browsing gemini, I could quickly set > the colors or styling on a domain level it could be neat to visually > separate places I go routinely. Some users might value that feature > enough to choose a client that offers it. Others wouldn't care. > > Another option on the client level would be to hash the domain into a > color code of some sort, dynamically creating variation in the > backgrounds to a reasonable degree (shades of grey? below a certain > lumen?). That would give the user an obvious indication if a link > followed changed domains. Again, it might be of value to somebody and > others won't care. > I think this is worth exploring if it can be done. But I can't yet see how a client can determine when it is a cross-site link (or for client side styling a site). Since there may be multiple users on the same site. So the author has to indicate it in a consistent (i.e. standardised) way. But I like this line of discussion. - Luke
Brian Evans <b__m__e at mailfence.com> wrote: > I propose, also very hesitantly, that the following be optional elements > to code fences: > - The opening fence can be followed by a flag value of text or art (or > some other words that get decided upon, maybe even a or t) > - The closing fence can be followed by alt text I was planning to suggest this when the spec freeze ends in a few weeks. Not sure if it's a good idea to put it in the spec or as a recommended convention. -- Katarina >
On Thu, May 14, 2020 at 09:40:49PM +0200, Katarina Eriksson wrote: > Brian Evans <b__m__e at mailfence.com> wrote: > > > I propose, also very hesitantly, that the following be optional elements > > to code fences: > > - The opening fence can be followed by a flag value of text or art (or > > some other words that get decided upon, maybe even a or t) > > - The closing fence can be followed by alt text > > I was planning to suggest this when the spec freeze ends in a few weeks. > Not sure if it's a good idea to put it in the spec or as a recommended > convention. There's an existing convention in Markdown, if I'm not mistaken, of mentioning a programming language's name in curly brackets after an opening code fence, which is used as a hint for syntax highlighting. I'm not clear on the details, entirely, but people have mentioned it before. It might be smart to adopt/extend that syntax? For now I am leaning toward "recommended convention"... Cheers, Solderpunk
Hey, > There's an existing convention in Markdown, if I'm not mistaken, of > mentioning a programming language's name in curly brackets after an > opening code fence, which is used as a hint for syntax highlighting. > I'm not clear on the details, entirely, but people have mentioned it > before. Yeah, there kinda is [0]. It's called the "info string" and has (by spec) no defined meaning, it's usually used to hint the syntax highlighter on the correct programming language. > It might be smart to adopt/extend that syntax? I think that would be a good thing. I enjoyed some of the ASCII art you an find in gemini space and it would be nice to recognize these in a search engine and filter these out. It could also allow to search for certain programming languages (considering ascii art a PL) > For now I am leaning toward "recommended convention"... Yeah, sounds reasonable. Having the info string in the spec is a good idea though, but make it's content not fixed Regards xq [0] https://spec.commonmark.org/0.29/#fenced-code-blocks
On 5/14/20 8:47 PM, James Tomasino wrote: > I hesitate to even offer a solution because it gets too close to our > heated code fencing & list markup discussion, but... As code fences > currently begin with ``` > and end with > ``` > > We could use the starting code fence to indicate whether the content is > art or not, or parseable as text or not. > > ```text > > ```art > > or some ARIA-esque token. > > I was originally thinking that the text following ``` could be a literal > alt text. I dunno. Just throwing out ideas. I like this proposal, I played with this idea on gemini://typed-hole.org front-page. I was a quick change on my clients code so that could work. I tried having the first opening fence with some kind of type (art in this case) and the closing one with some alt-text.
> On 5/14/20 8:47 PM, James Tomasino wrote:
>
> We could use the starting code fence to indicate whether the content is
> art or not, or parseable as text or not.
>
> ```text
>
> ```art
I'm not a fan of the ending part having text too,
slightly harder parser, and noticeably harder to read for humans,
especially if there are several blocks back-to-back
other than that, not too bad idea, I suppose
of course, ``` might not be the best characters, but it'd work
(` is accessable on US keyboard, but often a combining character or behind
some key-chord on other layouts)
maybe...something like this?
``` whitespace [optional alt text describing contents]
monospace art or code block
```
where you could do stuff like
``` hello_world.py
print("hello world")
```
and
``` a cheering stick-man
\o/
|
/ \
```
or simply
```
can re-use as block quote as well
because why not?
~jan6, 2020
```
would probably be good to have different start and end tags to make it simple to parse
otherwise you'd need to count if current ``` line is odd or even numbered
(did it just start, or did it finish?), or such extra checks
that's why it could be good to require at least one whitespace after
starting ``` and none after closing one,
alt text optional, but descriptive if used (you could have a convention of
having art captions start with "art, depicting" or such, but not one word
"art, figure it out yourself")
but hey, these are just my initial thoughts, feedback?
On 5/17/20 11:42 AM, jan6 at tilde.ninja wrote: > I'm not a fan of the ending part having text too, > slightly harder parser, and noticeably harder to read for humans, > especially if there are several blocks back-to-back > other than that, not too bad idea, I suppose TLDR; ``` this is alt text / syntax descriptor this should not be search by engines or read by screen readers by default ``` ``` this has no alt text and should be searched by engines and read by screen readers ``` --- The long version --- I've been thinking of ways to keep it extremely simple. If the goals are: - provide alt text for a block that may not be easily parsed by bots & screen readers - indicate which blocks should and should not be parsed Then I think we can accomplish the goal with a single code fence suffix that is either blank, indicating that the content CAN be parsed, or has text, indicating that IS the alt text. ``` anything here is alt text moo moo moo moo moo ``` ``` This will be parsed because there's no fence suffix at the start. ``` That would be incredibly easy to parse and require zero effort from clients that already exist since they can continue to just look at the first three characters and ignore the rest. Search engines can read the alt/descriptor and skip the rest of the block if it exits, or read the contents if its blank. Easy all around. The complication would come if you want that space to have another purpose, such as defining the language for syntax highlighting on a code block like we see in markdown. ```bash #!/usr/bin/env bash printf "moo moo moo moo moo\\n" ``` This would be interpreted for alt-text purposes as just "bash". First of all, it would mean that search engines wouldn't parse code blocks which may or may not be a bad thing. It may actually work out great for accessible clients though. I don't know of anyone making an accessible client YET, but if it were structured this way the block, when hit, could indicate verbally that a preformatted block had been reached and the alt/descriptor could be read. A good accessible client might even inform the user how many lines the block contains and offer some way to "page" through it bit by bit. This sort of behavior would be nice to talk through with anyone working on such a client, but beyond giving it some initial consideration I don't see it as belonging in the gemini spec itself.
On Sun, May 17, 2020 at 01:16:05PM +0000, James Tomasino wrote: > > It may actually work out great for accessible clients though. I don't > know of anyone making an accessible client YET Rhapsode is an "auditory web browser" that recently added Gemini support: http://rhapsode.adrian.geek.nz/ So, they do exist. I hope it is only the first of more to come. This is an area where we can very easily beat the pants off most of the web. Cheers, Solderpunk
> would probably be good to have different start and end tags to make it simple to parse otherwise you'd need to count if current ``` line is odd or even numbered (did it just start, or did it finish?), or such extra checks Guys... I don't want to be mean, but parsing is not that hard, lol. <cr><lf> is not hard to parse either. For ```, all you need is a boolean (or even just a context enum) that's set to its opposite value everytime you see ``` at the start of a line. If the value was set to true, then you're now in a block and everything after ``` will be the alt text. Christian Seibold Sent with ProtonMail Secure Email. ??????? Original Message ??????? On Sunday, May 17, 2020 8:30 AM, solderpunk <solderpunk at SDF.ORG> wrote: > On Sun, May 17, 2020 at 01:16:05PM +0000, James Tomasino wrote: > > > It may actually work out great for accessible clients though. I don't > > know of anyone making an accessible client YET > > Rhapsode is an "auditory web browser" that recently added Gemini > support: > > http://rhapsode.adrian.geek.nz/ > > So, they do exist. I hope it is only the first of more to come. This > is an area where we can very easily beat the pants off most of the web. > > Cheers, > Solderpunk
_jan6 writes:_ > I'm not a fan of the ending part having text too, > slightly harder parser, and noticeably harder to read for humans, > especially if there are several blocks back-to-back I'm not sure about this. It seems to me that someone parsing by line can just set a flag for `in_pre_block`. When they get to a line beginning with ``` they know the pre block has ended. Sounds dead simple to me. As to harder for humans, the whole point is to make it easier for humans. The ``` and text should not appear to most users. It is not for them, it is for the client. Having the opening ``` with a type of some form allows a client to offer options such as "show ascii art" and "show pre text" as boolean options. If someone chose to set "show ascii art" to to false for the below: ``` art :-) ``` A simple smiley The client could display: [art: A simple smiley] To that user instead of the full block. I think there is real value and utility in that. Not only that but it adds to the ability of any future screen reader implementations to be able to parse the document in a way that will make sense to the user using the screen reader. I would go so far as to recommend this be a requirement for preformatted blocks in accessibility merits alone. I think there should be three types: Art, Text, Code and that descriptions on the end blocks should be compulsory. That said, I'm definitely not wanting to bikeshed this thing and we have already had a lot of text/gemini discussions in the past. --? Sent with https://mailfence.com Secure and private email
May 17, 2020 6:19 PM, "Brian Evans" <b__m__e at mailfence.com> wrote: > As to harder for humans, the whole point is to make it easier for humans. The ``` and text should > not appear > to most users. It is not for them, it is for the client. no... point of gemini is to have a format so simple you don't *need* specialized clients, that you can view it with basically TLS-enabled netcat equivalent... a super-simple client... for example, => lines are quite readable, you can easily see where they go and what they're named with your eyes, without *needing* to do fancy "hide url, only show human-readable part", which is just a nicety fancy clients CAN do... "oh the client will take care of it" is a bad way of thinking at that rate you'll end up with something like html, "hey, the user doesn't need to see the source! let's make it all fancy!", because y'know, html is readable... and sure, you could keep a boolean or such for that, but why not make it easier? it doesn't matter too much parsing-side, I suppose, sure...
On 17 May 2020, at 5:19 pm +0200, Brian Evans wrote: > _jan6 writes:_ > > I'm not a fan of the ending part having text too, slightly harder > > parser, and noticeably harder to read for humans, especially if > > there are several blocks back-to-back > I'm not sure about this. It seems to me that someone parsing by line can > just set a flag for `in_pre_block`. When they get to a line beginning > with ``` they know the pre block has ended. Sounds dead simple to me. > As to harder for humans, the whole point is to make it easier for > humans. The ``` and text should not appear to most users. It is not > for them, it is for the client. Having the opening ``` with a type of > some form allows a client to offer options such as "show ascii art" > and "show pre text" as boolean options. If someone chose to set "show > ascii art" to to false for the below: > ``` art > :-) > ``` A simple smiley > The client could display: > [art: A simple smiley] > I would go so far as to recommend this be a requirement for preformatted > blocks in accessibility merits alone. I think there should be three > types: Art, Text, Code and that descriptions on the end blocks should > be compulsory. I like the idea of severely limiting the available block-type options. How about this for block syntax, with the understanding that the alt text is highly recommended for accessibility. Specifying the block type and the programming language or written language (as appropriate) would be strictly optional: those that wanted to make use of them could, those who did not want to make use of them would not have to. For the purposes of this proposal, there would be *no space* between the backticks and the optional content-type field, which field may not contain spaces. There must be at least one space on the line before the (recommended) alt text. That way, the client doesn't need to try and figure out where one ends and one begins: the instant the client sees a space, we're into alt-text territory for the rest of the line. ```[art | code[:programming language] | text[:written language]] [alt text] ... ``` So, e.g., ```code:c The Laziest Hello World #include "real_hello_world.h" ``` ```text:fr_FR Antoine de Saint-Exup?ry on perfection Il semble que la perfection soit atteinte non quand il n'y a plus rien ? ajouter, mais quand il n'y a plus rien ? retrancher. -- Terre des Hommes, 1939 ``` ``` This is a block with just alt text. You know, I think the alt text is better than the content this time. ``` What the client does with the alt text and the block type, if anything, is up to the author. I think this way, it would be both nicely readable to a human reading the source text/gemini, without sacrificing ease of parsing. Just throwing an idea at the wall to see whether it sticks. Cheers, Ivy Foster
jan6 writes: > [...] point of gemini is to have a format so simple you don't *need* specialized clients Funny, I never saw that written anywhere. Simple: yes. Designed specifically to be run without a client that does nothing more that cat the raw format: nope. While that is certainly a valid use case I definitely balk at the idea that that should be a primary target. > "hey, the user doesn't need to see the source! let's make it all fancy!" I cannot speak for any other clients, but with mine you can always just download the file as raw source if you want the source. The fact is that there will be variance in use case and client approaches. The use case you mention is perfectly valid, as are programs (I hesitate to call them clients if all they do is make a request and print the response as raw text) that do what you described. I hardly think providing an alt string/type string to what could be a big blob of non-sense characters to a non-sighted person should be considered too complicated. Nor do I think it is hard to visually grep the following: ``` ascii art of a dog Seems unambiguous to me. > [...] without *needing* to do fancy "hide url, only show human-readable part", which is just a nicety fancy clients CAN do... The spec actually _requires_ that the ``` line itself not be shown to users, thus making a netcat like response not in line with what the spec would consider a client. Taken from the spec: "Any line whose first three characters are "```" (i.e. three consecutive back ticks with no leading whitespace) are preformatted toggle lines. These lines should NOT be included in the rendered output shown to the user." I think the alt text feature would be a very useful tool in making gemini more accessible than gopher. The web is an accessibility nightmare and some simple planning and very low overhead features can be implemented here in gemini to make it more approachable to all users, but especially those that use various assistive technologies. Again, this is a very bikeshed oriented topic and I am not wanting to start a new rabbit hole on this. Solderpunk, if you are reading this, I too remember the formatting conversations and do not relish a deep dive back in. So feel free to chime in and pump the breaks on this convo if you think that is the right approach.
Ivy writes: > I like the idea of severely limiting the available block-type options. > > How about this for block syntax, with the understanding that the alt > text is highly recommended for accessibility. Specifying the block > type and the programming language or written language (as appropriate) > would be strictly optional: those that wanted to make use of them > could, those who did not want to make use of them would not have to. > > For the purposes of this proposal, there would be *no space* between > the backticks and the optional content-type field, which field may not > contain spaces. There must be at least one space on the line before > the (recommended) alt text. That way, the client doesn't need to try > and figure out where one ends and one begins: the instant the client > sees a space, we're into alt-text territory for the rest of the line. > > ```[art | code[:programming language] | text[:written language]] [alt text] > ... > ``` I think you hit on it perfectly Ivy. I love this proposal and it definitely has my full support. It communicates a lot of information in a small space and is still very parsable. Given the specs mandate of the ``` not being shown directly tot he user it should not clutter up the document for those viewing it under most circumstances. It is also easy to write for those developing content. I like that both parts are optional, but available, and a lot can be communicated with them. Well done. --? Sent with https://mailfence.com Secure and private email
On 5/17/20 5:42 PM, Brian Evans wrote: > ```[art | code[:programming language] | text[:written language]] [alt text] > ... > ``` I'm getting lost in the brackets a bit. If I want to include alt text, must i have art, code, or text as the first word, or no? ```art superman logo vs ``` superman logo
James Tomasino <tomasino at lavabit.com> wrote: > > ```[art | code[:programming language] | text[:written language]] [alt > text] > > ... > > ``` > > I'm getting lost in the brackets a bit. If I want to include alt text, > must i have art, code, or text as the first word, or no? > > ```art superman logo > > vs > > ``` superman logo > Both are OK according to the proposal above, there is no "must" as everything is optional -- Katarina >
I think it makes a lot more sense to have a specific alt text marker; something like
```art | alt text here
```
or for example:
```code:cpp | Fibonacci implementation
int fib(int n) {
if (n < 2) {
return n;
}
return fib(n - 1) + fib(n - 2);
}
```
With this, one could tell what's alt text and what is the "kind" very easily.
- Nicole Mazzuca
P.S. Sorry for the HTML if this sends HTML, I'm using a mobile client and
it is unclear how to do plain text.
-------- Original Message --------
On May 17, 2020, 11:15, Katarina Eriksson wrote:
> James Tomasino <tomasino at lavabit.com> wrote:
>
>>> ```[art | code[:programming language] | text[:written language]] [alt text]
>>> ...
>>> ```
>>
>> I'm getting lost in the brackets a bit. If I want to include alt text,
>> must i have art, code, or text as the first word, or no?
>>
>> ```art superman logo
>>
>> vs
>>
>> ``` superman logo
>
> Both are OK according to the proposal above, there is no "must" as
everything is optional
>
> --
> Katarina
>
>>
May 17, 2020 9:15 PM, "Katarina Eriksson" <gmym at coopdot.com> wrote: > > Both are OK according to the proposal above, there is no "must" as everything is optional > everything except the space, is ;P in order for the space to be optional it'd need to be [art|blabla][ alt] instead of [art|blabla] [alt], as latter makes it mandatory to have a space there no matter what (and a single space at that, not allowing tabs or multiple spaces) I'm not sure having types which are optional, is too good of an idea, but otherwise it's nice... what if I happen to have an alt text like "code red" on some art piece? accessible clients would read nonsense... also don't really see the point/reasoning of the "text" type there, if it's not code nor art, what is it? monospace text for no reason? maybe just "misc" category then? accessibility-wise you can just avoid art, so that doesn't seem to be much reason for a text type... also maybe allow one-letter shorthand types? kinda like [a[rt]|c[ode]|t[ext]], use either "c hello.lua" or "code hello.lua" not much practical value, but it allows one to only check the first character and skip to alt-text, if wanted (or ignore anything other than first 4 characters on that line)
Katarina Eriksson writes: > James Tomasino <tomasino at lavabit.com> wrote: >> ```art superman logo >> >> vs >> >> ``` superman logo >> > > Both are OK according to the proposal above, there is no "must" as > everything is optional What if the alt text is "art superman logo"?
May 17, 2020 9:36 PM, "Nicole Mazzuca" <nicole at strega-nil.co> wrote: > I think it makes a lot more sense to have a specific alt text marker; something like > > ```art | alt text here > ``` > > With this, one could tell what's alt text and what is the "kind" very easily. current proposal would mean you just treat everything after space as alt-text the space is mandatory before alt-text in that proposal (probably should be "nonzero amount of <whitespace>") nothing is preventing me from making an alt-text saying something like "this | that - a poem", so it wouldn't exactly solve anything, other than making it slightly easier to parse (separating only on first space shouldn't be hard at all anyway)
On 5/17/20 6:43 PM, jan6 at tilde.ninja wrote: > nothing is preventing me from making an alt-text saying something like "this | that - a poem", so it wouldn't exactly solve anything, other than making it slightly easier to parse (separating only on first space shouldn't be hard at all anyway) I'm really leaning toward the simplest of all things, which is no special "type" at all. Just ```[optional whitespace][optional alt text] The art type is meaningless once we have an alt, so that's easy to dismiss. The text type doesn't help tell me if the content should be spidered or read aloud. Including a language property seems nice, but we don't have a lang property on the whole document, so it's overkill in this context. Really the only thing we're doing is codifying a bunch of extra rules and enumeration so that we can specify code syntax languages. That leads to clients being able to mark things up, which is fine and all, but seems far less important than the plain accessibily goal. If this becomes cumbersome or fragile (space vs no space breaking things) then people won't use it. I suggest the simpler approach here will be better for gemini. If people want to use the alt text area to indicate code & language, then that's a pattern we can toss into the best practices doc. If it gets put into practice, clients can check for it if it matters to them.
That seems like a mistake. Code highlighting is _really_ important for code gemlogs, imo. Nicole Sent from ProtonMail mobile -------- Original Message -------- On May 17, 2020, 12:28, James Tomasino wrote: > On 5/17/20 6:43 PM, jan6 at tilde.ninja wrote: >> nothing is preventing me from making an alt-text saying something like "this | that - a poem", so it wouldn't exactly solve anything, other than making it slightly easier to parse (separating only on first space shouldn't be hard at all anyway) > > I'm really leaning toward the simplest of all things, which is no > special "type" at all. Just > > ```[optional whitespace][optional alt text] > > The art type is meaningless once we have an alt, so that's easy to > dismiss. The text type doesn't help tell me if the content should be > spidered or read aloud. Including a language property seems nice, but we > don't have a lang property on the whole document, so it's overkill in > this context. > > Really the only thing we're doing is codifying a bunch of extra rules > and enumeration so that we can specify code syntax languages. That leads > to clients being able to mark things up, which is fine and all, but > seems far less important than the plain accessibily goal. > > If this becomes cumbersome or fragile (space vs no space breaking > things) then people won't use it. I suggest the simpler approach here > will be better for gemini. > > If people want to use the alt text area to indicate code & language, > then that's a pattern we can toss into the best practices doc. If it > gets put into practice, clients can check for it if it matters to them.
On Sun, May 17, 2020, at 12:36, Nicole Mazzuca wrote: > That seems like a mistake. Code highlighting is _really_ important for > code gemlogs, imo. Because there's already a large, potential base of content that would be ported to hosting on gemini, I'm worried that over-specifying the "alt-text" would create an extra set of steps for content creators. Perhaps the client can be opinionated, or ask the user what they want to do with a text block. "This text block has no hints, should I just render it as monospaced text?" "This text block has the hint text 'art' should I render it as ascii art?" "If I run across text blocks with alt text like javascript, fortran, ruby, css... should I apply code formatting" But the baseline for the client would be to say "it's a text block, I'm rendering it as monospace". -- Emma
On 5/17/20 7:45 PM, Emma Humphries wrote: > "This text block has no hints, should I just render it as monospaced text?" ``` with nothing after it, this would be the default. It can apply monospaced text, but won't stop screen readers from parsing it or search engines from spidering it. > "This text block has the hint text 'art' should I render it as ascii art?" ``` some sort of alt text handles art, weird formatted text that can't parse, figlet, etc. Accessible! > "If I run across text blocks with alt text like javascript, fortran, ruby, css... should I apply code formatting" ``` !code pascal Give it some special token to indicate to clients that care that it can be handled in a special way. Don't know what the token should be. Could be a hash-bang! :) Nicole says code highlighting is important. Granted there's a lot of that type of content coming. I still don't think we need to overcomplicate this thing.
May 17, 2020 10:36 PM, "Nicole Mazzuca" <nicole at strega-nil.co> wrote:
> That seems like a mistake. Code highlighting is _really_ important for
code gemlogs, imo.
can't you just get that out of the filename?
just have a convention that the alt text starts with the filename of the
code, if applicable?
and I'm not aware of anything with syntax to highlight that DOESN'T have a
filename extension like .js or .py or .yaml or whatnot...
``` code.py
print("hello")
```
``` code2.sh prints "world"
echo "world"
```
```example.json about how to do nothing
{"abc":123}
```
and whatnot, stuff like that?
> also don't really see the point/reasoning of the "text" type there, if it's not code nor art, what is it? monospace text for no reason? maybe just "misc" category then? accessibility-wise you can just avoid art, so that doesn't seem to be much reason for a text type... Don't forget about Poetry! :) Christian Seibold Sent with ProtonMail Secure Email. ??????? Original Message ??????? On Sunday, May 17, 2020 1:36 PM, <jan6 at tilde.ninja> wrote: > May 17, 2020 9:15 PM, "Katarina Eriksson" gmym at coopdot.com wrote: > > > Both are OK according to the proposal above, there is no "must" as everything is optional > > everything except the space, is ;P > in order for the space to be optional it'd need to be [art|blabla][ alt] instead of [art|blabla] [alt], as latter makes it mandatory to have a space there no matter what (and a single space at that, not allowing tabs or multiple spaces) > > I'm not sure having types which are optional, is too good of an idea, but otherwise it's nice... > what if I happen to have an alt text like "code red" on some art piece? accessible clients would read nonsense... > > also don't really see the point/reasoning of the "text" type there, if it's not code nor art, what is it? > monospace text for no reason? maybe just "misc" category then? accessibility-wise you can just avoid art, so that doesn't seem to be much reason for a text type... > > also maybe allow one-letter shorthand types? kinda like [a[rt]|c[ode]|t[ext]], use either "c hello.lua" or "code hello.lua" > not much practical value, but it allows one to only check the first character and skip to alt-text, if wanted (or ignore anything other than first 4 characters on that line)
It was thus said that the Great James Tomasino once stated: > Including a language property seems nice, but we > don't have a lang property on the whole document, so it's overkill in > this context. It could be included with the MIME type as: text/gemini; lang=en_US or maybe as: text/gemini; language=se_NO -spc (There is a way ... )
On 5/18/20 1:02 AM, Sean Conner wrote: > It could be included with the MIME type as: > > text/gemini; lang=en_US As language directives would help with client-side translation options and aid global access to content I am a fan! However, I don't see a way of accomplishing this purely on the server level without a blanket decision that all your content is going to be in one language. If we allow it to be set at the document level then we're starting to add document header. It would be neat if there's a way. Anyone else see a good option that doesn't introduce extensibility or complexity?
Hi James, James Tomasino writes: > On 5/18/20 1:02 AM, Sean Conner wrote: > decision that all your content is going to be in one language. If we > allow it to be set at the document level then we're starting to add > document header. Maybe in the source files held on the server, but this could also be specified on a per-directory or even per-user basis. But this is just server implementation detail, isn't it? The text/gemini response that's actually served doesn't accrue a header. A gopher analogy: none of the "gopher maps" served up for my gopherhole look anything like the source files from which they're generated. But that has nothing to do with RFC-1436. > It would be neat if there's a way. Anyone else see a good option that > doesn't introduce extensibility or complexity? It's just a parameter in the content type string, is it really introducing extensibility when servers are already free to add as many of these as they like (up to the character limit), and clients are free to ignore them? Tim
On Monday 18 May 2020 13:25, James Tomasino <tomasino at lavabit.com> wrote: > It would be neat if there's a way. Anyone else see a good option that > doesn't introduce extensibility or complexity? Sometime, things must be strict and old files must be remaster :-) UTF-8 as mandatory character set for gemini page with .gmi extension! All other text encoding should be consider as external content and manage by external software. Regards, K.I.S.S and Less is more :-) freD.
Ivy Foster <escondida at iff.ink> writes: > How about this for block syntax, with the understanding that the alt > text is highly recommended for accessibility.[...] I quite like the content of this proposal. It reminds me of org-mode source blocks. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada |
May 18, 2020 2:25 PM, "James Tomasino" <tomasino at lavabit.com> wrote: > However, I don't see a way of accomplishing this purely on the server level without a blanket decision that all your content is going to be in one language. why not? there can be many approaches... you can have metadata file, that has a list, like hello-en.gmi en-US hello-et.gmi et-EE you could separate directories by language, and have the server serve them as if they were in the same dir en-US/hello.gmi ? hello.gmi sv_SE/hi.gmi ? hi.gmi with some duplicate checking probably you could have a little header in your source files, just the first line, and have server ignore the first line (it could be just language, or the entire mimetype, maybe) etc etc, there are so many approaches to this ;P
On 5/18/20 1:10 PM, jan6 at tilde.ninja wrote: > you could have a little header in your source files, just the first line, and have server ignore the first line > (it could be just language, or the entire mimetype, maybe) > > etc etc, there are so many approaches to this ;P There's a few decent ideas floating around already, I'll admit. I hope one of them resonates with people. I'm wary of ones that involve adding things to a gemini file, though, especially if they're not spec. If one server decides to implement a language header by adding content to the top of a .gmi, then moving content to another server type has burden added. Little things like that add up and you end up with the different "flavors" like markdown. This is doubly true for what plugd was saying about gopher maps not looking like the files that they are authored in for many gopher servers. I would hope we can avoid this problem from the start. The .gmi spec is simple and flexible. I'd hate to see us get into a situation where we are creating new languages to generate it for transport so early in the life of gemini. I like your idea of a metadata file. I doubly-like it because then it's an individual problem servers can handle on their own without us needing to address anything more in the specs.
On Sun, May 17, 2020 at 09:02:51PM -0400, Sean Conner wrote: > It could be included with the MIME type as: > > text/gemini; lang=en_US > > or maybe as: > > text/gemini; language=se_NO I have been meaning to propose exactly this. The FAQ says that the "first class" application of Gemini is human consumption of predominantly written material, and specifying a language is actually really important metadata for this application. Knowing the text encoding is not adequate: Screenreaders (like Rhapsode) need to know a language to be able to pronounce text vaguely correctly. Text in some languages should be rendered right to left and/or top to bottom. The same word can mean very different things in different languages and search engines should not return irrelevant results on this basis. Someone is bound to ask: "Oh, does this mean text/gemini; content-size=1234 is okay, too?". No! We are talking about MIME types here. This is *category* information. Details specific to one particular document are inappropriate. Cheers, Solderpunk
On Mon, May 18, 2020 at 11:25:04AM +0000, James Tomasino wrote: > However, I don't see a way > of accomplishing this purely on the server level without a blanket > decision that all your content is going to be in one language. Some equivalent of Apache's .htaccess files would allow users to specify languages for particular files/directories. One day, Molly Brown will recognise .molly files to allow things like this, along with specifying MIME types for unusual/unconventional file extensions, specifying client certificate fingerprints to restrict access to some content to certain clients only, etc., etc. I don't know that this approach is the best way to do it, it's just the one I'm familiar with. But, I mean, "Content-Language" is a HTTP response header - there *must* be plenty of ideas out there in web land that server authors could look to for ways to handle this. Cheers, Solderpunk
On Monday 18 May 2020 13:25, James Tomasino <tomasino at lavabit.com> wrote: > and aid global access to content I am a fan! However, I don't see a way > of accomplishing this purely on the server level without a blanket > decision that all your content is going to be in one language. No need to be in only one language, UTF-8 is able to do all language in in the same document! All new content is UTF-8 now, and older content can be easily converted. https://en.wikipedia.org/wiki/UTF-8#/media/File:Utf8webgrowth.svg Regards, freD.
May 18, 2020 5:36 PM, "defdefred" <defdefred at protonmail.com> wrote: > No need to be in only one language, UTF-8 is able to do all language in in the same document! no, that's not the point the point is, as stated before, allowing screen-readers and search engines to properly read the documents, and for allowing languages that render in a different direction to do so (like right-to left languages, or vertical writing), if you search "pain" you probably don't want to see a french page about making bread, if you read an icelandic page as english with TTS (such as those who're visually impaired might do), it will sound like absolute nonsense, etc... utf-8 takes care of glyphs, but several things require knowing the language to work. (while at it, a language code such as "zxx", the code for things known not to be in ANY language, should be supported, and used for things like ascii/unicode art)
> On May 14, 2020, at 21:00, Luke Emmet <luke.emmet at orlando-lutes.com> wrote: > > This is interesting, something like the sigils in Urbit, or Gravitar that are automatically generated from > some identifier? > > https://urbit.org/blog/creating-sigils/ > Had to give it a try ? E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ??
On 28-May-2020 23:29, Petite Abeille wrote: >> On May 14, 2020, at 21:00, Luke Emmet<luke.emmet at orlando-lutes.com> wrote: >> >> This is interesting, something like the sigils in Urbit, or Gravitar that are automatically generated from >> some identifier? >> >> https://urbit.org/blog/creating-sigils/ > Had to give it a try ? > > E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ?? Huh - that is cute. These Urbit avatars are quite attractive. I think they spent quite a bit of time on the graphic design of that engine. - Luke
> On May 29, 2020, at 01:29, Luke Emmet <luke.emmet at gmail.com> wrote: > >> E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ?? > Huh - that is cute. These Urbit avatars are quite attractive. I think they spent quite a bit of time on the graphic design of that engine. Yeah, pretty nifty actually. Like their 'phonemic naming system' as well (the 4028369029 to ~lapryt-fidse bit): https://urbit.org/understanding-urbit/urbit-id/ https://github.com/urbit/urbit-ob/blob/master/src/internal/co.js https://github.com/urbit/sigil-js It's a bit of a pain to run 'out-of-the-box' if you are not into node.js, but I'm confidant spc will get a sweet Lua implementation in no time :) -- PA
It was thus said that the Great Petite Abeille once stated: > > > > On May 29, 2020, at 01:29, Luke Emmet <luke.emmet at gmail.com> wrote: > > > >> E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ?? > > Huh - that is cute. These Urbit avatars are quite attractive. I think > > they spent quite a bit of time on the graphic design of that engine. > > Yeah, pretty nifty actually. > > Like their 'phonemic naming system' as well (the 4028369029 to ~lapryt-fidse bit): First off, it should be ~lapryt-fidseg. Secondly, how do you get ~4028369029 from gemini.circumlunar.space? I either get taplux~ligsef or ~~rocpel~ladtuc, depending on if I use bit-endian or little-endian on the IP address (as a 32-bit quantity). > https://urbit.org/understanding-urbit/urbit-id/ > https://github.com/urbit/urbit-ob/blob/master/src/internal/co.js > https://github.com/urbit/sigil-js > > It's a bit of a pain to run 'out-of-the-box' if you are not into node.js, > but I'm confidant spc will get a sweet Lua implementation in no time :) Heh. -spc (How hard could it be?)
> On May 29, 2020, at 02:55, Sean Conner <sean at conman.org> wrote: > > First off, it should be ~lapryt-fidseg. Secondly, how do you get > ~4028369029 from gemini.circumlunar.space? I either get taplux~ligsef or > ~~rocpel~ladtuc, depending on if I use bit-endian or > little-endian on the IP address (as a 32-bit quantity). Using the first few bytes of the sha3.sha256 of the domain. With the IP address: gemini.circumlunar.space ? 168.235.111.58 ? 2834001722 ? ~taplux-ligsef ? sigil
> On May 29, 2020, at 03:12, Petite Abeille <petite.abeille at gmail.com> wrote: > > Using the first few bytes of the sha3.sha256 of the domain. > Actually, the certificate serial number could be a seed as well, e.g.: tonumber( ( '03AFB22DF61DC72291F4B7C3745572BB7F4F' ):sub( 1, 8 ), 16 ) ? 61846061 ? ~wantun-linbyn? sigil
It was thus said that the Great Petite Abeille once stated: > > On May 29, 2020, at 01:29, Luke Emmet <luke.emmet at gmail.com> wrote: > > > >> E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ?? > > Huh - that is cute. These Urbit avatars are quite attractive. I think > > they spent quite a bit of time on the graphic design of that engine. > > Yeah, pretty nifty actually. > > Like their 'phonemic naming system' as well (the 4028369029 to ~lapryt-fidse bit): > > https://urbit.org/understanding-urbit/urbit-id/ > https://github.com/urbit/urbit-ob/blob/master/src/internal/co.js > https://github.com/urbit/sigil-js > > It's a bit of a pain to run 'out-of-the-box' if you are not into node.js, > but I'm confidant spc will get a sweet Lua implementation in no time :) I think you know me too well. Anyway, if anyone is interested in playing with this, I have a CGI script set up. A few sample links: gemini://gemini.conman.org/sigil?id=~lapryt~fidseg&fg=green&bg=white gemini://gemini.conman.org/sigil?id=F01C0885&fg=green&bg=white gemini://gemini.conman.org/sigil?id=~lapryt~fidseg gemini://gemini.conman.org/sigil?id=F01C0885 The source code to the CGI is also avaiable on the site---warning: it's
> On May 30, 2020, at 03:49, Sean Conner <sean at conman.org> wrote: > > I think you know me too well. Wow! Super fantastic. Was it fun to do? :) For the record: https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua Very, very nice :)
On Sat, May 30, 2020 at 11:17:05AM +0200, Petite Abeille wrote: > > > > On May 30, 2020, at 03:49, Sean Conner <sean at conman.org> wrote: > > > > I think you know me too well. > > Wow! Super fantastic. Was it fun to do? :) Indeed, these look really great. I like the idea of mapping identifiers (be they Urbit IDs or URLs) to visually appealing and distinct little graphical elements. I'm kind of wary of Gemini clients using Urbit IDs for this purpose, though. Totally aside from any kind of potential IP issue, it just seems a little rude when the Urbit folk obviously put an awful lot of time and energy into coming up with these sigils as part of their own project's visual identity. But adopting the general idea I'm totally enthusiastic about. Any graphic designers, or similarly inclined people, on the list? Cheers, Solderpunk
> On May 30, 2020, at 20:54, solderpunk <solderpunk at SDF.ORG> wrote: > > I'm kind of wary of Gemini clients using Urbit IDs for this purpose, though. MIT License https://github.com/urbit/sigil-js They put it out there to be actually used, by actual people.
On Sat, May 30, 2020 at 09:15:39PM +0200, Petite Abeille wrote: > MIT License > > https://github.com/urbit/sigil-js > > They put it out there to be actually used, by actual people. > Presumably for use in Urbit-related contexts, right? Okay, I realise that given the code is out there under an MIT license they can't stop people doing whatever they want with it. We're
> On May 30, 2020, at 21:21, solderpunk <solderpunk at SDF.ORG> wrote: > > Presumably for use in Urbit-related contexts, right? ?!? Urbit has those already...no point in releasing it back to themselves... > > Okay, I realise that given the code is out there under an MIT license > they can't stop people doing whatever they want with it. A MIT license is meant to *allow* people to do whatever the heck they want. > We're *allowed* to. It just feels rude, to me. ... > But I can't stop Gemini client authors doing it. This is a profound truth.
> On May 30, 2020, at 20:54, solderpunk <solderpunk at SDF.ORG> wrote: > > Any graphic designers, or similarly inclined people, on the list? Actually, if someone is up to it, their methodology for composing visually distinct images is very generic: https://urbit.org/blog/creating-sigils/ Looking at Sean's implementation, one could fiddle with the various SVG fragments, and achieve a distinctive visual identity, without having to change much of the mechanics themselves: https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua
> On May 30, 2020, at 21:21, solderpunk <solderpunk at SDF.ORG> wrote: > > It just feels rude, to me. "Urbit ID and the sigils are components of Urbit that are totally separate from the OS ? you can use them on their own and potentially even extend their functionality. We?re happy with what we?ve done with them so far, and hope that people will experiment with what?s possible with this naming and identity system." -- Gavin Atkinson, Creating Sigils, 202-02-04 https://urbit.org/blog/creating-sigils/ <https://urbit.org/blog/creating-sigils/> It would be rude not to :D
It was thus said that the Great Petite Abeille once stated: > > On May 30, 2020, at 03:49, Sean Conner <sean at conman.org> wrote: > > > > I think you know me too well. > > Wow! Super fantastic. Was it fun to do? :) Yes. I"ve never really looked at SVG before, and I had to pick up just enough to know how to construct the file. > For the record: > https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua > > Very, very nice :) Thanks. -spc
There was an offhand request for a converter from gophermap to the native text/gemini format in the IRC channel. I had an awk script written already to parse gophermaps, so I made some quick adjustments and can share the results here: https://github.com/jamestomasino/dotfiles-minimal/blob/master/bin/gophermap2gemini.awk Currently it detects html links, telnet links, and remaining linkable gopher types and formats those into the => link pattern. I am checking URLs for spaces and escaping those, since spaced URLs do actually work in gopher but won't in gemini due to link line parsing. I'm defaulting to code-fencing all type i lines in the file unless the lines match the formatting for a header (#, ##, ###, but not ####), or an unordered list. It's in GNU awk and untested on BSD. I'm guessing it'll explode there brilliantly. For those of you looking to batch-convert or cross-serve content, it may be useful. Hack it up and enjoy. PS: do we have a name for the text/gemini format itself? The spec-spec just refers to it by media type.
---