Alt text and media types for preformatted text

> 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)

View entire thread.