> 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.
---
Previous in thread (5 of 26): 🗣️ Alexis (flexibeast (a) gmail.com)
Next in thread (7 of 26): 🗣️ Caolan McMahon (caolan (a) caolan.uk)