💾 Archived View for rawtext.club › ~sloum › geminilist › 005782.gmi captured on 2023-11-14 at 09:51:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Caolan McMahon caolan at caolan.uk
Mon Mar 1 09:08:42 GMT 2021
- - - - - - - - - - - - - - - - - - -
Code highlighting is a good use case for this - but it would also
~sorta allow for putting other content inline if we aren't careful on
what's allowed.
To be honest, code highlighting is probably not that important but it's an easy to understand presentation choice that a client might make. It's probably more important that a client implementing accessibility features understands what type of content is in the block so it can read or navigate it appropriately. E.g. a table or a poem might be handled differently to ascii art.
As for other content inline - I agree. Preformatted text blocks have always been the biggest extensibility risk in my opinion. They were already the most likely place to put custom client features and this makes it very slightly easier. In the end, our best defence is culture and a plethora of popular clients. Keeping things easy to parse is important for that reason, and I believe an argument for either denying extra data for preformatted blocks, having only one type, or keeping them separate, instead of attempting to combine them with new syntax.
But I think using the opening/closing toggles like this may cause
confusion, if you look at the line in isolation, you can't tell what
the text following it is. You're supposed to be able to tell how a line
would be structured/it's meaning by only looking at the first three
lines.
That's not quite true - to know what a line containing ``` will do, you need to know whether your client is in preformatted mode, and this proposal makes no change to the state required.