💾 Archived View for rawtext.club › ~sloum › geminilist › 000767.gmi captured on 2020-09-24 at 02:20:54. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Ivy Foster escondida at iff.ink
Sun May 17 18:17:03 BST 2020
- - - - - - - - - - - - - - - - - - - ``` 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 alttext is highly recommended for accessibility. Specifying the blocktype and the programming language or written language (as appropriate)would be strictly optional: those that wanted to make use of themcould, 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* betweenthe backticks and the optional content-type field, which field may notcontain spaces. There must be at least one space on the line beforethe (recommended) alt text. That way, the client doesn't need to tryand figure out where one ends and one begins: the instant the clientsees a space, we're into alt-text territory for the rest of the line.
So, e.g.,
What the client does with the alt text and the block type, ifanything, is up to the author. I think this way, it would be both nicely readable to a human readingthe source text/gemini, without sacrificing ease of parsing. Justthrowing an idea at the wall to see whether it sticks. Cheers,Ivy Foster-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 833 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/d7fa247d/attachment.sig>