💾 Archived View for gemi.dev › gemini-mailing-list › 000160.gmi captured on 2024-08-25 at 09:45:39. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
I had an idea for a new line type for the text/gemini document type.I'm not sure how attached I am to it, or how well it would be received,but I figure it would at least be worth mentioning here. "Frames" are a way to create collapsible "sections" of a Gemini document. In graphical browsers I imagine these would be arranged horizontally, but they would be perfectly readable vertically as well. Proposed syntax: ||| denotes the start or end of a frame |?? (or any non-'|' characters after the first '|') denotes a new frame section --- denotes a vertical/same section division in a frame section A very good example of this would be a navigation bar. For example, # Page Title ||||||||||||||||| => ../ Back => page1/ Page 1 => page2/ Page 2 => page3/ Page 3 | | | | | | | | | ## Article Title 2020-05-28 ----------------- Article contents ... ||||||||||||||||| Footer text This is perfectly readable on a dumb terminal display, but on a TUI/GUI browserit may look something like this: # Page Title ??? ----------------------------- ??? => Back?? | ## Article Title ??? => Page 1 | 2020-05-28 ??? => Page 2 |------------------ ??? => Page 3 | Article contents ? ?? ???????? | ... ??? ----------------------------- ??? Footer text With this example, it may be a better idea to place the links at the
An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/1cb2 abc5/attachment.htm>
Couldn't nice clients do this already, just using the heading and preformatted blocks? That keeps thing simple but still allow for this kind of functionality. I'm picturing something like what Wikipedia looks like on mobile. makeworld ??????? Original Message ??????? On Thursday, May 28, 2020 9:33 PM, InvisibleUp <invis at park-city.club> wrote: > I had an idea for a new line type for the text/gemini document type.I'm > not sure how attached I am to it, or how well it would be received,but I > figure it would at least be worth mentioning here. > > "Frames" are a way to create collapsible "sections" of a Gemini > document. In graphical browsers I imagine these would be arranged > horizontally, but they would be perfectly readable vertically as well. > > Proposed syntax: > ||| denotes the start or end of a frame > |?? (or any non-'|' characters after the first '|') denotes a new frame > section > --- denotes a vertical/same section division in a frame section > > A very good example of this would be a navigation bar. For example, > > Page Title > > =========== > > ||||||||||||||||| > > => ../ Back > => page1/ Page 1 > => page2/ Page 2 > => page3/ Page 3 > > | | | | | | | | | > > Article Title > > -------------- > > 2020-05-28 > > ----------- > > Article contents > ... > > ||||||||||||||||| > Footer text > > This is perfectly readable on a dumb terminal display, but on a TUI/GUI > browserit may look something like this: > > Page Title > > =========== > > ----------------------------- > ??? => Back?? | ## Article Title > => Page 1 | 2020-05-28 > => Page 2 |------------------ > => Page 3 | Article contents > | ... > ??? ----------------------------- > ??? Footer text > > With this example, it may be a better idea to place the links at the > endof the document, resulting in a right sidebar. This keeps the > navigation fromencroaching onto the document contents in a vertical > view. Left sidebars should > be short, sweet, and simple. > > The user should be able to collapse the navigation component, if they > choose.They may also choose to display it vertically. Perhaps frame > sections consistingsolely of links could also display the links in a > line, at the client'sdiscretion. > > This could also be used inline in a standard document, for figures w/ > captiontext, poetry next to ASCII art w/ alt-text, etc. > > Note that you cannot nest a frame within another frame. This vastly > simplifiesthe syntax and implementation, as well as discouraging future > extensions. > > Another idea for layout: > > ??? ||| > ??? # Article Title > ??? 2020-05-28 > ??? | > ??? => ../ All > => next/ Next > => prev/ Previous > ||| > Article contents > ... > > which could be displayed as > > Article Title | => All > > ======================= > > 2020-05-28 ? ?? | => Next > | => Previous > ------------------------------ > ??? Article contents > ??? ... > > I kinda like it, but I can definitely see the arguments against it. Let > me know what you think of this. > > -- InvisibleUp gemini://park-city.club/~invis > > -- Email domain proudly hosted athttps://migadu.com
Hey, Thanks for the suggestion and sorry for the slow response! Perhaps predictably, I'm not really enthusiastic about this. I acknowledge that you've tried to limit the complexity of this by explicitly forbidding the nesting of frames (and thank goodness!), but I still think this is a substantial increase in complexity compared to everything else. Adding this, as it is proposed, would break the principle that has held so far of text/gemini being parsable and renderable line-by-line in a single pass with almost no internal state in the parser. A frame-based solution would require a client to hold the entire document in memory at once and impose some kind of internal structure on it. I understand it's supposed to be optional, but I would like it if even a "full flavoured" renderer which supports all line types is still a pretty modest undertaking. This would also, for the first time, make it really possible to produce non-trivially invalid text/gemini. E.g. a "| " line encountered befeore a "|||" line makes no sense. People could also easily write, deliberately or by accident, a text/gemini document which did nest frames in the way that's not allowed, and clients would need to recognise this and then decide what to do with it. So the complications and potential problems this brings along are pretty substantial, more so than ever other line type so far. I also appreciate that you've given thought to how this would degrade in a dumb terminal display. Even if we grant that your suggested layouts don't look too bad, I worry that people will come up with other layouts which *do* look confusing. I guess I'm also not clear what problem this is intended to solve which couldn't be solved in a simpler way. If this is just suppose to give text/gemini authors a way to creatively express themselves a bit, then I guess this isn't really a concern (but I would suggest that there are probably simpler ways to jazz up a page a bit). But if it's supposed to make pages easier to navigate, maybe there are other ways to achieve this? In what I assume is the intended rendering of one of your examples, the document title remains visible at the top the entire time as you scroll through the actual content. text/gemini already *has* a clear and simple way to indicate the title of a document, by putting a first-level header on the first non-empty line. GUI/TUI clients could easily extract that title and display it permanently in part of their layout. Navigation links are less obvious, but I'm not sure what is wrong with just having them sit, by convention, at the end of a document. Any decent client should allow the user to hit the End key on their keyboard and immediately jump down to those links. Cheers, Solderpunk
---